The Review Tax: Why AI Coding Agents Made Me Slower Before They Made Me Faster

The pitch is everywhere by now: a coding agent is a junior developer who never sleeps, and a solo founder with one becomes a team of five. I believed it. I bought in early, wired an agent into my editor and my terminal, and pointed it at my backlog.

For about three weeks, I got slower.

Not because the tools are bad. They're genuinely good — better than I expected, and I expected a lot. I got slower because I had misunderstood where my time went in the first place. I thought the constraint on a one-person SaaS was typing code. It was never typing code. The constraint was always understanding the system well enough to change it safely, and an agent that generates code faster than I can read doesn't relieve that constraint. It loads it up.

This is the part nobody puts in the demo, and it's the single most important thing for a lean founder to internalize before they restructure their whole day around an agent: the agent doesn't remove your bottleneck. It moves it. Where you used to spend your hours writing, you now spend them on two harder things — saying precisely what you want, and verifying that what came back is actually right.

The bottleneck moved from writing to reviewing

Here's what my workweek looked like before. I'd pick a task, hold the relevant slice of the codebase in my head, and write the change. Writing it was the act of understanding it. By the time the code existed, I knew it cold, because I'd just reasoned my way through every line. Review was cheap — it was mostly already done.

Here's what it looked like after, for those bad three weeks. I'd describe a task in a sentence, the agent would return forty lines across four files in thirty seconds, and then I'd sit there. The code looked plausible. It usually ran. But I hadn't built the mental model that writing it used to give me for free — and now I had to build that model anyway, from the outside, reverse-engineering the agent's choices to decide whether to trust them. I was doing the hard half of the work after the code already existed, which is the worst possible order.

I am not the only one who hit this wall. The phrase that kept coming up across the industry in 2026 was that we're now generating code faster than a human can read, comprehend, validate, and review it. On a big team that shows up as senior engineers drowning in oversized pull requests. On a team of one, you are the senior engineer and the entire review process, and there's no one to absorb the overflow. The agent can open three pull requests an hour. You can meaningfully review maybe one.

So the productivity number that matters for a solo founder isn't lines generated or tickets closed. It's how much real understanding you're carrying per hour, because that's the thing that lets you ship without quietly accumulating code you can't explain. An agent that closes tickets faster while your ability to explain the system erodes isn't a win. It's debt with a fast settlement clock.

What actually made it faster

The turnaround wasn't a better tool. It was changing how I work with the one I had. Three things did most of it.

I started spending real time on the prompt, not the patch. The single highest-leverage shift was treating the specification as the work. The clearer the boundary I draw around a task — what it should touch, what it must not touch, what "done" looks like, the constraint I care about — the less reviewing I have to do, because the agent makes fewer of the off-target choices that force me to reverse-engineer its reasoning. The industry started calling this "context engineering," and the unglamorous truth underneath the term is just: if you can't state the task precisely, the agent can't do it, and you'll pay the difference at review time. I now spend more minutes describing a change than I used to spend writing it. That's not waste. That's the work relocating to its new home.

I gave it small, boundaried tasks instead of big vague ones. A forty-line diff across four files is roughly the upper limit of what I can review with rigor in a sitting. So I stopped asking for the four-file change. I ask for the one-file change, review it while I still have the context hot, commit it, and only then ask for the next. Smaller task boundaries mean smaller diffs mean reviews I can actually do instead of reviews I rubber-stamp. The agent is happy to go faster than this. I am the one who can't, and pretending otherwise is how the debt accumulates.

The tool you use nudges you toward or away from this discipline, and it's worth picking with that in mind. I drifted between a few. The in-editor agents — Cursor, or Copilot's agent mode, or the agent baked into Zed — keep you inside the diff, which makes the small-change-then-review loop feel natural; you're staring at exactly what changed. The terminal-driven ones I tried, Claude Code and Aider, lean the other way: they make it trivially easy to say "go fix the whole thing," and that frictionlessness is precisely the trap, because the diff you get back is bigger than the one you can honestly review. None of them is wrong. The point is that the tool's default size of change is a real variable, and on a one-person team you want the one whose defaults match the size you can actually review — or you impose the boundary yourself regardless of what the tool wants.

I review like I don't trust it — because the failures are specific. The best operators I know in 2026 aren't the fastest typists. They're the ones who've learned exactly which categories of mistake an agent makes consistently — the silently-wrong edge case, the plausible-looking function that handles the happy path and nothing else, the "fix" that addresses the symptom and moves the real bug somewhere quieter — and they review for those rather than skimming for vibes. Trusting the output by default is the expensive mistake. The agent is a tireless generator of confident, plausible, occasionally-wrong code, and confident-plausible-wrong is the most expensive kind to catch late.

The small mechanical thing that helped me hold the line here was committing each reviewed change on its own with a real message — I lean on the Conventional Commits format, not because the format is magic but because writing "fix:" or "refactor:" and a one-line reason forces me to articulate what the change actually does before it lands. If I can't write that sentence, I haven't understood the diff yet, and that's the tell that I'm about to rubber-stamp. The commit message is a tiny, cheap comprehension check, and it's saved me from shipping confident-plausible-wrong more than once.

The honest tradeoff

I want to be clear that this is still a net win, or I wouldn't run an agent at all. On the work that is mostly typing — the boilerplate, the test scaffolding, the third CRUD endpoint that's identical to the first two, the migration I've written a hundred times — the speedup is real and large, and I'd never go back. For a solo founder, getting that category of work off your plate is genuinely a force multiplier.

But the multiplier only applies to the part that was ever about typing. For the part that was always about understanding — the architecture call, the gnarly state bug, the change that touches money or auth — the agent doesn't multiply you. It shifts your effort from writing to specifying-and-reviewing, and if you're not deliberate about that shift, it quietly makes you slower while feeling faster. Feeling faster while being slower is a dangerous place for a one-person company to live.

So here's the rule I'd give my three-weeks-ago self. Budget for the review tax explicitly. When you estimate a task, don't estimate the generation time — that's nearly free now and it's not your constraint. Estimate the specify-and-verify time, because that's the bill, and it comes due whether you've planned for it or not. Treat the prompt as the real work, keep the diffs small enough to actually review, and review like the code is guilty until proven innocent.

Do that, and the team-of-five promise is half true — which, for a founder running lean, is still a very good deal. Just know which half you bought.