How not to suck as a CTO in 2026

Let me start with a number. Our repo 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, a required bug-hunt, and an agent that opened a browser and used the product 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 role in that flow is now replaceable by an agent. Not "fire your workforce" — 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 provide most of them faster, in parallel, and without sick days.

Step by step.

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, and reviews are cheap now, so every layer gets one.

The net under it: Cursor's Bugbot runs as a mandatory CI check. 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

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's Part 3's warm-up): 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 take the approval 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 find and fix their own bottlenecks. Part 3: Your agents react — incidents, outages, and production access.