Warden: The AI On-Call Engineer

The autonomous on-call engineer for founders who ship AI-built apps they can't debug. Warden catches a production bug, fixes it, proves the fix, and ships it, with one tap.

Comment

Inspiration

As a solo founder myself, I noticed that no matter how many revisions or how much testing I do, there's always some bug I'll miss. And in 2026, that's not just my problem. v0, Cursor, Lovable, and Claude Code turned "I have an idea" into "it's in production" with no engineer in the loop. Building got easy. Keeping the thing alive did not. The same wave is putting a lot of production code in the hands of people who cannot read or fix it.

So when the app breaks at 3am, the founder is stuck. Monitoring tells them something is on fire but never fixes it. They can point a coding agent at it (Sentry has an MCP now, so Claude Code or Cursor can pull the issue and write a patch), but that is a single model guessing, with no one to check whether the fix is actually correct or just a quick patch that breaks something else next week. For someone who cannot read the diff, an outage means a lost week of momentum chasing a bug they don't understand, and usually a lost customer too.

The funded tools here (Cleric, Resolve, Sentry's own Seer) sell investigation or a drafted pull request to developers who can read code, and they price for the enterprise teams that employ them. Cleric's entry tier is $2,000 a month. A solo founder with one paying customer can't justify that, and wouldn't know what to do with the pull request anyway. Nobody is building for the founder who can't. That founder is who Warden is for.

The whole product rests on one bet. If the buyer cannot review the patch, trust cannot come from review, so it has to come from somewhere else. A single model writing a fix is a guess, so Warden has a panel of models from different labs cross-check it, catching the edge cases one model would miss. Then it proves the fix actually works before it ships, makes every change reversible in one tap, and never deploys without a human saying yes.

What it does

A production error fires, and Warden runs the whole incident on its own. You can watch it move through each stage live:

detected → triaging → investigating → fix_proposed → under_review → verifying → awaiting_approval → approved → deploying → verifying_prod → resolved

  1. It investigates with a read-only database role and writes a plain-English root cause. It can look at the code, but it cannot touch it.
  2. An AI fixer writes a patch on a fresh branch. No merge, no deploy, just a proposed change with a summary. The fixer is fenced off from the dangerous files. It will never auto-edit a migration, a schema, an auth module, or anything holding secrets, and a fix that lands on one of those stops and escalates to a human instead.
  3. Up to three reviewer agents from different model families cross-check the patch against the file's history. They come from different labs on purpose, so their blind spots don't line up. If they disagree, it goes to a human, and their agreement can never override a failed check.
  4. The verification gate is the part that actually makes this safe. It spins up a preview, replays the exact request that crashed to confirm the error is gone, and re-runs the app's own tests to make sure nothing that was working broke. If the app has no tests, it says so out loud and leans on the reviewers instead. The reviewers give their opinion on whether the fix is right. The gate is what actually confirms the crash stopped and nothing else broke.
  5. You get a phone notification in plain English, with the check results and two buttons: ship it, or don't. It also tells you straight whether the change is safe to undo. A code-only fix is fully reversible in one tap, and if a fix ever touches the database, it says so before you ship.
  6. One tap ships it. Warden opens a pull request on your repo, or merges it directly, and your existing CI/CD takes it the rest of the way. It gets checked again in production, and if the error rate spikes afterward, Warden rolls the change back on its own.

Every step, each transition, fix, reviewer verdict, check result, and decision, lands in an append-only audit log. Hit the same kind of bug twice and pgvector memory recognizes it from last time. Through all of this, the founder never reads a line of code.

How I built it

Amazon Aurora PostgreSQL Serverless v2 is the center of the whole system. I lean on it for four jobs at once:

  • State machine. An incident status column plus a table of legal transitions. There is no legal path to "deploying" that skips both the verification gate and a human approval row. The safety rules live in the database, where a model can't talk its way around them.
  • Audit log. Every transition writes one immutable row to an events table, the single record of what happened, who did it, and why.
  • Memory. An embedding column with pgvector and an HNSW index answers "has this incident happened before?"
  • Learning. A scorecard table tracks how accurate each agent has been over time.

All four needed to live in one place, which is exactly why I chose Aurora over the other AWS options. DynamoDB is NoSQL, wrong for this joined relational data, and DSQL is built for multi-region writes I don't need. Aurora PostgreSQL Serverless v2 gives me the relational state machine, the pgvector search, and the append-only log in one database that scales down between incidents.

The orchestrator keeps no state of its own. It reads the current state from Aurora on every tick, runs exactly one step, and writes back, so a crash in the middle of an incident just resumes where it left off. A small jobs table with FOR UPDATE SKIP LOCKED, lease heartbeats, and backoff acts as the queue. It ships as a hardened container that runs as a non-root user with a liveness healthcheck, ready for an always-on host.

The agents sit behind one interface, so the fixer and the reviewers can run on cheap models or frontier ones without the orchestration caring which. The verification gate is real even in the default offline mode: it runs the target app's actual tests and a real reproduction. I only fake the parts that genuinely need accounts and keys, like the Sentry webhook, the deploys, and the model calls. The safety-critical checks stay real either way.

The front end is Next.js on Vercel: a dark ops-console dashboard and a mobile approval screen with web push for the one-tap ship or revert. The pipeline engine runs on an AWS EC2 worker, and everything talks through Aurora. The whole thing runs end to end against a real Postgres. The headline test walks a bug from detection all the way to resolved, proves nothing ships without approval, checks that disagreement escalates, confirms a bad deploy rolls itself back, and shows a repeat bug getting recognized from memory.

Challenges I ran into

  • Trust without review is genuinely hard to design. The whole pitch depends on the buyer not reading the code, so I pushed the safety rules down into the database. No agent has standing permission to deploy, and nothing reaches production without both a passing gate and a human consent row. I don't try to manage the risk of a rogue agent. The schema makes that deploy path impossible in the first place.
  • Agreement between agents is a trap. I almost treated "both reviewers approved" as a green light. But reviewers trained on similar data share the same blind spots, so their agreement is a weak signal. I demoted it to a filter and made the verification gate the only thing that can actually clear a fix.
  • Drawing the line between simulation and live, honestly. I had to decide what to fake without faking the part that matters. The rule I settled on was to fake what needs accounts and keys, and keep the safety checks real. So the gate runs real tests and a real reproduction even offline, and the demo shows the real thing running.
  • Cheap inference from day one. To serve a customer who isn't worth much per incident, the model can't be the cost floor. I built the provider layer so a three-agent review costs pennies, and designed around where the money actually goes.

Accomplishments I'm proud of

  • The full verify-instead-of-review loop runs end to end against a real Postgres, including the one-tap revert the whole pitch hinges on.
  • The verification gate is real even offline. It runs the target app's actual tests and a real reproduction, so the safety claim is not a mock.
  • A working reviewer panel across different model families, with the deliberate stance that disagreement escalates instead of consensus shipping.
  • Aurora doing four jobs at once: state machine, audit log, pgvector memory, and scorecard. I made the database the thing that enforces the safety rules and remembers past incidents.
  • A second trigger that catches the breach class that throws no error at all, a database table left readable by anyone. Warden scans for row-level security gaps, explains each one in plain English, generates the fix, applies it on one tap, and confirms the anonymous key can no longer read the table. No developer involved.
  • A fix-and-retry loop with a budget. When a reviewer flags an over-scoped patch, or the gate catches a regression, Warden hands the failure back to the fixer for a tighter attempt and re-checks, instead of giving up at the first objection. It only escalates when it cannot get there, so you can watch the agent correct itself.

What I learned

  • The database really is the product. Writing the incident lifecycle as an explicit state machine with an append-only log turned "trust me, the AI is careful" into something you can audit and replay. The safety guarantees I was most worried about got easier once they lived in the schema.
  • Being able to undo a change beats promising it's correct. For a buyer who can't check the patch, "you can take this back in one tap" is worth more than any claim that the fix is right.
  • Proving a fix is harder than writing one. Anyone can generate a patch now. The real work is showing it actually fixed the bug and broke nothing else, and that's the part worth defending.
  • Cheap models changed what I could build. A three-agent review that would have been too expensive at frontier prices is trivial on cheaper models, which is the only reason serving the long tail of vibe-coded apps makes economic sense.

What's next for Warden

  • Generalizing the verification gate to any incident automatically. The gate is real today, running the target app's tests and replaying the failing request to prove the crash is gone. Right now it works on the incident types I have built reproductions for. The work ahead is to synthesize that reproduction straight from any Sentry event on its own, generate a smoke test for repos that have none, and read the live post-deploy error rate, so the gate fires on a brand-new production bug with no setup at all.
  • Closing the learning loop. Route the fixer and reviewers by their scorecard win rate per error type, and feed the fixer the last accepted fix when memory finds a match.
  • Hardening for production. Sandboxed, network-restricted containers for running untrusted customer code, a GitHub App that ships the exact verified commit, and per-tenant isolation with Postgres row-level security.
  • The business. The incumbents charge enterprise teams thousands a month. Warden is priced for a solo founder instead. You pay pennies per incident, and you can see exactly what each one costs. You also pick the model yourself, from a cheap default to your own API key. A free watch tier that just diagnoses brings people in, and they convert when they grow into a team. The moment that sells it: connect your Sentry, then watch Warden catch and fix a real bug while you sleep.

Anyone can build an app now. Warden is the engineer that keeps it running, so no founder has to face a 3am crash alone.

Built With

Share this project:

Updates