Agents run your SDLC

Let me start with a number. Our repo at Herita has seen over 1,000 pull requests — 860 merged, and 627 of those in the last four weeks. The engineering team is currently one full-time engineer.

Every one of those PRs went through design review, code review, and a required bug-hunt — and every one that touched the product faced an agent that opened a browser and used it before merge. The volume isn't the point. The point is that the process producing it is the same one my 50-person org ran seven years ago — with different workers.

The SDLC you already know

At my last startup I was CTO of an engineering org of 50+. When a project landed:

design → review → tickets → build → review + QA → deploy + smoke test

a) an engineer writes a tech design → b) a second engineer reviews it → c) we synthesise and map out tickets → d) engineers build them → e) PRs get reviewed and merged while QA does browser tests → f) deploy, smoke test.

It worked! It was slow, and a couple of sick days could throw it off — but it worked, because every step buys a guarantee. Design review catches the expensive mistakes early; code review catches the cheap ones late; QA catches what both missed.

My challenge to you: every execution step in that flow can now be agent-run. Not "fire your workforce" — the accountability for intent, judgment and risk stays exactly where it was, with people. But you should be deliberately rebuilding each step as automation, one at a time. The steps were never the point. The guarantees were, and agents now supply most of them faster, in parallel, and without waiting on anyone's calendar.

Six steps, five layers of machinery — design review folds into the design step, and tickets fall out of it. Layer by layer.

1 · Tech design — one author → N adversaries → synthesis

We don't ask one agent for a design. We spin up several and make them fight.

Stakes set the dial: more complexity = better models + more agents + more rounds. When we built a blockchain-style integrity ledger for our document system at Herita — hash chains, checkpoints, external anchoring, the kind of thing you can't walk back — I ran four rounds of adversarial review and synthesis before any code.

Why adversarial? Agents are like us: bad at reviewing their own work. An author-agent pattern-matches its design to "what I intended" and nods along. A separate agent, briefed to attack and with no authorship pride, finds the missed edge case and asks "what happens when the anchor service is down for a week?" We've watched a model tear apart a design it would have approved had it written it.

The human role: brief the agents, judge the counterarguments, call the final round.

2 · Build — main agent → sub-agents → stacked PRs → CI bug-hunt

Our main agent plans, then delegates to sub-agents that each code away in their own isolated worktree. Bigger features become stacked PRs — a chain of small layers, not one 3,000-line monster. Small PRs = faster, more accurate reviews — which are cheap now, so every layer gets one.

The net under it: Cursor's Bugbot runs as a mandatory CI check. (Names like Bugbot and Sonnet are this quarter's stack, not the architecture — swap them freely; the gate is the point.) Anything above a medium-severity finding fails the build. There are false positives — the agent doesn't have to fix everything, but it has to answer every accusation with reasoning a human can audit. Nothing merges over an unanswered accusation.

For a big batch, one more agent reviews the whole stack adversarially — the cross-cutting mistakes no per-PR review can see.

3 · QA — ephemeral env → agent clicks through → verdict gates the merge

The part I'm most proud of. Every PR that needs it gets a live staging environment, and Sonnet agents open a real browser and use the product: upload the invoice, walk the financing flow, sign the document, check the money maths. They're told to always drive to a terminal state — no "clicked it, seemed fine" — covering the happy path and the common paths. More complexity = more testing = it's allowed to take longer.

The verdict is a required CI check. Red means no merge. We can also run it from the eng shell mid-session to debug a finding live.

Scripted E2E tests verify the paths you thought of. An agent notices the button that silently does nothing — and files the repro.

4 · Feedback — ticket → triage → agent implements → human spot-checks

Team feedback arrives as Linear tickets (sometimes Slack). Triage is one label: qa-agent (an agent can verify and drive this to done) or qa-human-required. The agent pulls the ticket, and either independently decides the implementation or takes instruction. The person who filed it never needs to know which kind of worker fixed it.

5 · Deploy — tag → pipeline → prod + demo → smoke test

The big moment. Agents cannot deploy to production — a line we drew, not a limitation. But everything up to the line is automated: a human pushes a GitHub tag, the pipeline deploys production and demo, we watch, then smoke test on demo.

One human action on top of a thousand automated ones. That ratio is the goal.

What makes it actually run

The unglamorous infrastructure below is why this works. Skip it and your agents stay toys.

Linear as ground truth. Agents read human tickets, write their own, and create their own projects. Statuses are defined so state is never ambiguous: merged to main = On Staging; awaiting release = Ready for Release; Done = live in every environment the ticket names. States track deployment reality, never merge events.

Skills, not memories. Every AI vendor wants to save "memories". Refuse — it's vendor lock-in, and worse, it hides knowledge where only one tool sees it. Anything worth remembering becomes a versioned skill file in the repo, readable by every agent from every vendor, and every human. We carry ~30 of them: the ledger, deployments, QA flows, the compliance register.

Guardrails as code, not prose. Written process wasn't enough. Agents skipped teardown steps until my MacBook's RAM filled with zombie worktrees (note to my beloved CEO Christoph, if he's reading: I need a new computer). One waited four hours for a CI check that was never going to exist rather than asking why. The fix is never bolder text in the instructions — it's making the bad path impossible:

// .claude/settings.json — the raw merge command is denied at the tool layer
"hooks": { "PreToolUse": [{ "matcher": "Bash(gh pr merge*)", "command": "bin/guard-gh-merge.sh" }] }

$ mise run merge            # the only door: squash-merges, verifies the merge
✗ refusing: 2 bugbot findings untriaged        # actually happened, closes the
                                               # worktree, sweeps the others

$ mise run watch-checks -- --pr 1041 --await qa-agent
✗ refusing: "qa-agent" can no longer arrive — deploy job skipped on this run.
  Fix the branch or re-dispatch; do not wait.   # vs. four silent hours

Cost, honestly. The harness — the Max plan, Bugbot, the QA agent's API key — runs under a thousand dollars a month, about $1.40 per merged PR (the itemised bill is in Part 0). Less than a fraction of one engineer, and the wrong number to optimise. The real cost is my attention: briefing, judging designs, and reading the gates' output. That is the budget line that binds.

Worktrees, worktrees, worktrees. Parallel agents need isolated workspaces, spun up and destroyed per task — or they trample each other and you'll blame the agents.

Test on staging, not laptops. Local QA environments kept eating my RAM. Now any branch needing QA gets a staging environment created automatically and torn down the moment the PR merges.

Permissions (this deserves its own article — it gets one in Part 4): agents do whatever they want on staging; production is explicit. Deploys go through tags, so merging is safe by construction. Reads and writes are different questions — an agent reading prod logs stops guessing; an agent writing to prod is another animal. For live emergencies there's break-glass: the agent requests access, a human approves from a phone.

How do you know it's working?

Trust, measured over time. Early on you check everything. Then the QA gate catches a real bug before you do. Then a clean week goes by. The system earns autonomy like a new hire does — except it documents every decision and never has a bad Monday.

The endgame is concrete: agents run the SDLC, gates hold the line, and you approve the moments that matter from your phone — lately I kick off work and tap approve from a park bench, coffee in hand, while a small army of agents does the rest.

That's the bar for 2026. A CTO still hand-relaying error messages between a chat window and CI isn't leading engineering — they're its slowest component.

Part 2: Your agentic org self-improves — the maintenance loops that let the org find and fix its own bottlenecks. Part 3: Your agents react — incidents, alerts and the reaction ladder. Part 4: Securing the agentic org — blast radius, break-glass and prompt injection. Part 5: Make everyone a developer — the payoff: when the gates hold, who gets to build becomes a choice.