DEV Community: Muhammad Awais

The Part of Shipping a PR Nobody Automated Until We Had To

Muhammad Awais — Mon, 10 Aug 2026 12:57:08 +0000

The Part of Shipping a PR Nobody Automated Until We Had To

You know this loop. You open a PR. CodeRabbit picks it up. You wait. It comes back with three comments one real, two nitpicks. You fix them, push, and wait again. Now it's rate limited because you pushed too soon, and the wait window is longer than it was five minutes ago. Twenty minutes later it finally reviews, approves, CI goes green, you click merge and by then you've context-switched away twice and lost the thread on what you were actually building.

None of that is CodeRabbit's fault. For what it's worth it's a genuinely good reviewer. The problem is the waiting. Every step in that loop is a human being asked to babysit a queue: is CI done yet, did the bot reply yet, is the rate limit over yet, did the reviewer request changes or just leave a nit. That's not engineering. That's polling with extra steps. We hit this exact loop enough times on our own Rails app that we stopped doing it by hand. Here's what replaced it.

The one command that ends the babysitting

claudetm merge-pr 172

That's it. Point it at a PR number and walk away. It polls CI, and when a check fails, it doesn't just tell you. It reads the failure, fixes it, pushes, and keeps polling. When CodeRabbit leaves review comments, it reads them, decides which ones are real, fixes those, and responds. When the base branch moves underneath the PR and creates a conflict, it resolves the conflict instead of stopping to ask you. It loops through all of that up to 30 iterations until the PR is actually, genuinely mergeable, and then it merges it.

We've watched it do the exact rate-limit dance we used to do by hand: CodeRabbit comes back "Review rate limited," and instead of panic-pushing another commit (which, if you've been burned by this, you know makes the wait window longer, not shorter), it recognizes that specific response and waits it out rather than treating it as a real failure. That's not a generic "retry on error". That's the tool having actually been built by people who got burned by CodeRabbit's rate limiter and fixed it at the source.

What "give it a goal" actually looks like end to end

merge-pr is the finishing move, but the tool runs the whole thing from scratch too:

cd your-project
claudetm start "Add rate limiting to the public API"

Output example:

▸ planning...
  → 3 tasks: add limiter middleware, wire config, add tests

▸ task 1/3: add limiter middleware
  → editing app/middleware/rate_limiter.py
  → running tests... 2 failed
  → fixing... re-running tests... passed
  → committed, pushed, PR #142 opened

▸ waiting for CI...
  → CI failed: lint error (unused import)
  → fixed, pushed, CI green

▸ waiting for review...
  → CodeRabbit: "Review rate limited. Next review available in: 12 minutes"
  → waiting (not nudging — pushing now only makes the window longer)
  → review landed: 1 real comment ("use a sliding window, not fixed bucket")
  → addressed, re-requested review
  → CodeRabbit: approved

▸ merged. verifying deploy...
  → health check passed. done.

Read that log again and count how many times a human would normally have had to context-switch back in to check on something. In the loop above: zero.

The full lifecycle, as a diagram

PLANNING
│
├─ Read codebase
├─ Create task list
└─ Define success criteria
│
↓
WORKING (per task)
│
├─ Make changes
├─ Run tests
├─ Commit
├─ Push
└─ Create PR
│
↓
PR LIFECYCLE
│
├─ Wait for CI
├─ Fix failures
├─ Address reviews
├─ Resolve conflicts
└─ Merge
│
↓
VERIFICATION
│
├─ Run tests
├─ Check lint
├─ Verify criteria
└─ Done

Most agent frameworks stop after the second box. You get code, you review it, you merge it yourself. The two boxes underneath that are where the actual tedium lives, and they're the ones we cared about closing.

A PR that goes stale doesn't rot

If you've run a busy repo you know this failure mode: your PR sits waiting on CI, someone else merges first, and now your branch is behind. Normally that's a "come back to this later" moment. Here, a PR that merely trails the base gets re-synced and re-tested before it's allowed to merge (sync-before-merge), and a PR that's outright conflicting gets handed to an agent session to resolve rather than blocking the run. Either way, the run doesn't stop. It notices for you.

Parallel work inside a single task, without git worktrees

When a task turns out to have independent, non-overlapping pieces, the session running it becomes a lead and hands pieces to hive-worker subagents. All sharing the same checkout, no worktrees, no clones. Only the lead touches git. Workers read, edit, and run narrow checks against a file set nobody else owns, and if a worker needs a file it doesn't own, it stops and reports instead of reaching across. The lead decides how many workers a task actually needs. Including zero, which is the right answer most of the time, since spawning four agents for four one-line edits costs more in cold-start overhead than it saves.

claudetm start "Port 20 view models to the new API" # parallel by default
claudetm start "Tweak the retry backoff" no-parallel # strictly one agent

Running more than one subscription without them colliding

Profiles isolate credentials, so you can run multiple Claude subscriptions or point at a custom Anthropic-compatible endpoint entirely in parallel without one clobbering the other's session:

claudetm profile add work
claudetm profile login work

CLAUDETM_PROFILE=accountA claudetm start "..."   # in repo-a/
CLAUDETM_PROFILE=accountB claudetm start "..."   # in repo-b/

Each profile gets its own credentials directory under ~/.claudetm/profiles/, so two subscriptions running at once don't invalidate each other's OAuth session. (Two copies of the same subscription running in parallel still can. That's an account-level limit, not something claudetm can route around. So give each concurrent run a distinct profile.)

The escape hatches say exactly what they bypass

admin merges past branch-protection rules that would otherwise block a finished, green PR. The situation you hit on a solo-authored PR against a main that requires an approving review nobody's around to give. It's a real override, not a workaround wearing a disguise. It does not skip CI, does not ignore a failing check, and does not merge over a reviewer who explicitly requested changes. If a human left CHANGES_REQUESTED, the run stops there even with admin on. That's a person pushing back, and the tool treats that differently from an unclicked "approve" button. If your branch protection exists because the review itself is the point, you leave admin off and merge by hand.

claudetm start "Your goal here" admin
claudetm merge-pr 42 admin # same override, single PR

Under the hood

Python 3.10+, built on the Claude Agent SDK. The same functionality is exposed three ways behind one password: a REST API (FastAPI), an MCP server (FastMCP) for native IDE integration, and webhooks with HMAC signature verification for event notifications. Ships as a PyPI package or a multi-arch Docker image on GHCR. MIT licensed, so the whole thing including the CodeRabbit rate-limit handling described above is just Python you can go read.

What's not done yet

This is a young, fast-moving project (first commit January 2026), and being straight about the rough edges matters more to us than sounding finished:

No web UI. Everything is CLI, REST API, or MCP. A dashboard is something you'd build against the API yourself right now.
Costs real money by default. The smart tier defaults to Opus, the priciest model. budget caps spend per session, but it's opt-in, not a default guardrail. Set it if you're running this unattended.
You supply the trust boundary. admin and auto-merge exist because unattended operation is the point, but that means deciding which repos are safe to hand that much autonomy to is on you, not the tool.
It trusts "resolved," and that trust has one known blind spot. CodeRabbit auto-marks a review thread resolved once you push a new commit. Even if that commit didn't actually address the comment. We've seen a high-severity finding get auto-resolved that way once. It's worth a human glance at security/correctness comments specifically before a merge-pr run finishes, not blind trust of the "resolved" flag alone.

Try it

pip install claude-task-master
claudetm doctor # verifies Claude CLI creds, GitHub CLI auth, git config

cd your-project
claudetm start "Your goal here"
# ...or, on a PR that's already open and stuck in review purgatory:
claudetm merge-pr <PR#>

Repo: https://github.com/developerz-ai/claude-task-master. MIT, issues and PRs genuinely welcome. If the CodeRabbit wait-loop at the top of this post is a loop you run by hand every week, I'd like to know if this actually closes it for you or just moves the tedium somewhere else.

We Gave Claude Code Access to Our Production Database. Here's How It Doesn't Go Wrong.

Muhammad Awais — Sat, 08 Aug 2026 09:27:33 +0000

We Gave Claude Code Access to Our Production Database. Here's How It Doesn't Go Wrong.

Every team building with AI agents eventually hits the same wall: the agent needs to query a real database to be useful, and every way of doing that looks bad. A DATABASE_URL in the agent's config is a credential sitting on a laptop. A shared read replica with a shared login means "who ran that query" is unanswerable. And a hand-rolled MCP wrapper around your DB driver is a security review waiting to happen. We built db-mcp-gateway to make that a solved problem instead of a judgment call. It's a self-hosted, MIT-licensed gateway, written in Rust,that sits between your AI agents and your databases. The agent never holds a credential not once, not cached, not in a log line.

The one-minute model

Deploy the gateway once. Developers add one URL to their MCP config:

claude mcp add --transport http db-gateway --scope project https://db.internal.acme.com

That's the entire client-side setup. First call to any gateway tool returns
401, the agent surfaces an SSO login link, you authenticate through your
org's actual identity provider (Okta, Google Workspace, Entra, Authentik,
Keycloak), and the token lands in your system keychain — never in a config
file, never in the agent's context.

┌─────────┐    MCP/HTTPS    ┌──────────────┐    pg wire    ┌──────────┐
│ agent   │ ──────────────▶ │   gateway    │ ────────────▶ │ target   │
│ (Claude │   bearer: jwt   │              │  ro role per  │  DBs     │
│  Code)  │ ◀────────────── │  authz+audit │ ◀──────────── │          │
└─────────┘   tool result   └──────┬───────┘   result rows └──────────┘
                                   │
                                   ▼
                            ┌──────────────┐
                            │ state DB     │
                            │ (sessions +  │
                            │  audit log)  │
                            └──────────────┘

Permissions are YAML, reviewed by PR not a UI

There's deliberately no admin UI. Access lives in a config file your team
reviews the same way you review any other production change:

permissions:
  - group: data-analysts        # matches an SSO group from the IdP claim
    grants:
      - server: prod
        database: "*"
        action: query_read      # SELECT + schema reads, never writes
        constraints:
          require_reason: true  # agent must justify the query → audit log
          row_limit: 1000       # gateway truncates beyond this
          statement_timeout_ms: 5000

Actions are hierarchical (query_write ⊇ query_read ⊇ schema_read), and
when multiple grants match, the most restrictive constraint wins. Writes are
opt-in per grant and, even then, capped hard: a query_write grant permits
a single INSERT/UPDATE/DELETE per call, through the same timeout and
row-cap path as a read. CREATE, ALTER, DROP, TRUNCATE, GRANT,
REVOKE, and multi-statement bodies are rejected with forbidden_sql —
always, regardless of grant. The gateway never issues DDL, full stop.

What the agent actually sees

You:    What databases can I see through db-gateway?

Claude: [calls list_servers → list_databases]

        You have access to:
        • staging (postgres) — staging/app, staging/billing
        • prod (postgres)    — prod/billing (read-only, reason required)

You:    How many users signed up in staging/app over the last 7 days?

Claude: [calls run_query staging/app]
          select count(*) from users where created_at > now() - interval '7 days';

        → 412 (returned in 38ms)

Cross a boundary and the failure is explicit, not silent: forbidden if
your group's grant doesn't cover it, timeout if the query exceeds
statement_timeout_ms, row_limit_exceeded/truncated: true if the result
is bigger than the grant allows, or a reason_required prompt if the grant
demands one — typically anything touching prod. The agent asks you for the
reason and it lands verbatim in the audit row. "checking stuff" versus
"verifying SUPPORT-4421 root cause" is the difference between an audit log
that's useless in six months and one that isn't.

Every run_query call writes that audit row user, SQL, reason, row
count, duration, outcome — before the result comes back to the agent, not
after. Hot retention lives in Postgres; there's an optional archive sink to
S3/GCS/Azure and streaming export via OTLP/syslog/stdout for teams who
already have a SIEM.

The stack, if you're curious

Rust, tokio for async, axum for HTTP, sqlx for the DB layer, config in
YAML validated at boot with line:column error pointers on typos. The
gateway also speaks the MCP Authorization spec (OAuth 2.1 + PKCE) itself —
it is the authorization server, brokering your IdP login internally, so
Claude Code and other MCP clients authenticate with zero manual credential
wiring on the client side.

What's not done yet

In the interest of not doing the thing every "launch" post does: this is a
young project (first commit May 2026) and a few pieces referenced in the
docs aren't real yet. There's no Helm chart docker-compose or hand-rolled
k8s manifests today. vault:/aws-sm:/gcp-sm: secret backends are
recognized in config but rejected at boot until they land; use ${ENV:...}
or ${FILE:...} refs for now. Session revocation is a manual psql insert
into a denylist table until the planned gateway admin CLI ships. None of
that blocks running it in production we do but it's not the finished
enterprise product yet, and I'd rather say that here than have someone find
out from the roadmap doc after trying it.

Why this exists

db-mcp-gateway is built and maintained largely by AI agents at
developerz.ai, under human review, with every change going through CI
before merge. It's also, not coincidentally, a small working demo of the
same idea developerz.ai sells as a product: agents should never hold raw
credentials, and every action they take should be attributable and
auditable. The gateway is the free, self-hosted version of that philosophy.

docker pull ghcr.io/developerz-ai/db-mcp-gateway:1.1.1

MIT-licensed. Repo, docs, and the full permissions reference are at
github.com/developerz-ai/db-mcp-gateway.

You Don't Need Sidekiq Pro for Batch Jobs, Rate Limiting, or Cron Here's a Free Drop-In

Muhammad Awais — Fri, 07 Aug 2026 15:37:19 +0000

If you've built anything non-trivial with Sidekiq, you've probably hit the wall where the feature you actually need batch job callbacks, rate limiting,scheduled jobs lives behind Sidekiq Pro or Enterprise. That's a reasonable business model, and it's funded years of full-time development on Sidekiq. If your company can afford the license, it's worth paying for. But a lot of teams can't justify the line item for a side project or an early startup. So I want to show what those features actually look like, and then show
a free, MIT-licensed, wire-compatible way to get them: wurk.

developerz-ai / wurk

Drop-in replacement for Sidekiq + Pro + Enterprise. 100% API-compatible, free forever, meaningfully faster. Mountable Rails engine.

Wurk ⚡

Wurk, wurk. 🪓 Ready to work. Zug zug.

A 100% drop-in replacement for Sidekiq + Sidekiq Pro + Sidekiq Enterprise. Free forever.

Wurk is wire-compatible with Sidekiq — same Redis keys, same job JSON, same Ruby DSL. Swap one line in your Gemfile and your existing jobs, batches, limiters, cron entries, and live Redis data keep working untouched. The Pro and Enterprise feature sets ship in the same free gem, with no license check and no tiers.

On speed: Wurk is not currently faster than stock Sidekiq — it runs at roughly 0.87×–1.02× depending on workload shape, with parity on CPU and I/O but still behind on framework overhead (noop) and boot time. Numbers, method, and the reproduction command are in docs/benchmarks.md; run them yourself with rake bench:vs_sidekiq.

Install

# Gemfile
gem "wurk"

# ...or drop in over an existing Sidekiq stack — delete these, add

…

View on GitHub

The migration is one line

Wurk speaks the same Redis protocol as Sidekiq same keys, same job JSON, same
Ruby DSL. If you're already on Sidekiq:

- gem "sidekiq"
- gem "sidekiq-pro", source: "https://gems.contribsys.com/"
- gem "sidekiq-ent", source: "https://enterprise.contribsys.com/"
+ gem "wurk"

bundle install, restart, done. Sidekiq::Worker, Sidekiq.configure_server,
your existing job classes — none of it changes. Your in-flight Redis data keeps
working untouched.

Batches, without the license check

Sidekiq::Batch lets you fire off a group of jobs and run a callback when the
whole group finishes — the classic use case is "process these 500 records, then
send one summary email."

batch = Sidekiq::Batch.new
batch.description = "Import customer CSV"
batch.on(:success, MyCallback, "to" => "ops@example.com")

batch.jobs do
  rows.each { |row| ImportRowJob.perform_async(row.id) }
end

Batches nest, too — a parent batch's callback only fires once every child batch
has finished, which is what you want for multi-stage pipelines. In stock
Sidekiq this whole API is Pro-only. In wurk it's just... there.

Rate limiting five different ways

Sidekiq::Limiter — an Enterprise feature — ships five limiter types, because
"rate limit" means different things depending on what you're protecting:

# concurrent: at most N jobs of this type running at once
limiter = Sidekiq::Limiter.concurrent("api-calls", 10)

# window: at most N calls per rolling time window
limiter = Sidekiq::Limiter.window("api-calls", 100, 1.hour)

# leaky bucket, bucket, and points limiters cover the rest —
# see docs/rate-limiting.md for when to reach for which
limiter.within_limit do
  ThirdPartyApi.call
end

If you've ever hand-rolled a Redis INCR + EXPIRE rate limiter and hit an
edge case at 2am, this is the version that's already handled the edge cases.

Cron jobs that actually run once

Periodic jobs are the other Enterprise feature, and the part that's easy to get
wrong yourself: if you run multiple worker processes, a naive cron
implementation fires the job once per process, not once total.

Sidekiq::Periodic.register("0 9 * * *", DailyReportJob)

Wurk's periodic scheduler is leader-elected across the cluster, so this fires
exactly once regardless of how many worker processes you're running.

Encrypted job arguments

If a job argument is a customer's SSN, an API secret, or anything else you'd
rather not sit in plaintext in Redis or your logs, Enterprise's answer is
transparent AES-256-GCM encryption with key rotation:

class ChargeCardJob
  include Sidekiq::Job
  sidekiq_options encrypt: true
end

The argument is encrypted before it hits Redis and decrypted only inside the
worker process. Wurk implements the same interface.

The dashboard, without a Node build

Wurk's Web UI mounts as a Rails engine, and the frontend ships precompiled
inside the gem — installing it doesn't pull Node into your build pipeline:

# config/routes.rb
authenticate :user, ->(u) { u.admin? } do
  mount Wurk::Engine => "/wurk"
end

There's a live, read-only demo if you want to poke at it before installing
anything: wurk.demo.developerz.ai

How this is built

The honest context, because it's relevant if you're deciding whether to trust
this in your stack: wurk is built and maintained largely by AI agents, working
under human review, against a documented parity spec of Sidekiq's public API
(what we call a clean-room implementation — the interface, not the source).
There's a ≥90% line coverage gate enforced in CI, and the parity specs
themselves are written against Sidekiq's own documented OSS/Pro/Enterprise
surface, so behavior drift shows up as a failing test regardless of who wrote
the code.

It's new one production app running on it internally so far, plus the public
demo. I'm not going to oversell that. If you run Sidekiq at real scale and want
to try wurk against a staging environment, I'd genuinely like to know what breaks.

Repo: https://github.com/developerz-ai/wurk
Docs: https://developerz-ai.github.io/wurk/

What would stop you from trying this — licensing worry, missing feature,
something else? Curious to hear in the comments.