I spent some of the last 6 months building a retirement planner. I neither wrote nor read any code myself - coding agents did. While writing code manually is quickly being replaced by agentic work, many people and organizations still insist on reading it. Can we also stop reviewing it ourselves? If every change still needs a manual review, review becomes the bottleneck.

If someone asked you the same question about a human - how can I trust that John is writing high quality code - what would you say? When I led human teams, I didn’t review every code change either. I relied on a process: design reviews, code reviews and tests.

I’ve been following that process with my agents: specs, code reviews, tests. I pay most attention to specs, just like I did in my previous jobs with humans, and I trust that the process down the line will implement the spec within some margin of error. To put this in context, the first 6 months of Retirement Lab development saw 42 PRs/week, with 410 out of 478 specs finishing without any further intervention.

In my experience, the most helpful addition to an agentic coding workflow is an independent code reviewer. The critical step is to give the code reviewer its own instructions and its own context - just like a human code reviewer would. They’re not there to agree with the original implementer, but rather to think independently and see if anything can be improved. When the reviewer rejects an implementation, the implementing agent addresses the findings and submits it for review again. I’ve seen this step prevent all kinds of issues. In my workflow, the automated reviewer requested changes at least once in 61% of implementation runs.

For instance, one reviewer noticed that clients waiting for simulation results kept a database connection open while they slept and polled. Each request could hold it for 30 seconds; enough waiting clients could exhaust the available connections. The agent changed the connection lifetime and added a regression test. That’s the kind of issue I’d expect only a sharp-eyed senior reviewer to catch.

Specs help most when I already know what I want to build. They give both the implementer and reviewer a clear target. When I’m prototyping, I prefer iterating directly with a coding agent, exploring ideas I haven’t pinned down yet.

Specs also make unattended work easier. If I want to expand tax treatment to 10 new countries, I can author and review all the specs at once, then leave my orchestrator, Spec Butler, chewing through them while I sleep. I’m trading some latency for throughput: it takes longer to get started, but more work can happen in parallel. When most specs finish without intervention, running more agents doesn’t have to mean fielding more interruptions.

Tests have become both more useful as guardrails and easier to write, since agents can do the work for you. I have two tips here. Insist on principled tests, and when bugs happen, ask whether a test could have caught it and add it if so. For instance, when I found overlapping fields in a form, I asked for more than a test of just those two fields. I asked for a general check that neighboring fields don’t overlap and that inputs fit inside their containers throughout the form. That asserts a general rule the interface should obey, rather than prescribing where each element must sit. Once your codebase has great tests, agents will imitate the existing style and keep adding tests unprompted.

Following such a process doesn’t guarantee bug-free software. About one in five product PRs in the timeframe I analysed addressed correctness bugs, roughly in line with the bug-fix share reported in a large study of traditional development. And some failures were consequential. For example, one calculation path treated local-currency amounts as US dollars, leading me to publish an incorrect comparison. I withdrew the article, then republished the corrected comparison after the agents merged the fix a few hours later.

The trade-off between speed and quality still exists with agents, so it’s important to tweak your process to your requirements. I found a good balance for my product using near full automation after the spec authoring phase, including automatic deployment to production. But if your risk tolerance is lower you may want to add more steps - a computer-using QA agent is a natural addition.

I still decide what the product should do and check how it behaves. Specs, independent reviews and tests let me delegate implementation without accepting every change on faith. The code still gets reviewed. Just not by me.

Try reviewing a few changes in parallel with an independent agent, then compare notes. You may be surprised by what it catches. But the more important question is what you caught that it missed. Is that enough to keep reading every diff?

About the Evidence

I asked an agent to analyze Retirement Lab’s repository, pull requests and execution logs. The agent-authored report, methodology and selected specs, reviews and fixes are available in the accompanying appendix. Note that I wrote this article but not the report, so please excuse Codex for any agent-speak.