Agentic coding moved my bottleneck. It used to be typing. Now it is reading.
For ten years the slow part of building software was writing it. You knew what you wanted. Getting it into the editor, wiring the imports, fixing the typo on line 40, that was the grind. Agentic coding flipped it. I run a fleet of coding agents overnight. They open pull requests while I sleep. The writing is basically free now. The reading is not.
What actually changed for a solo dev?
The agent does not get tired at 11pm. It does not skip the boring file. It will happily produce 600 lines across nine files for a task that needed 40 lines in one. The output is fast and it is plausible. Plausible is the trap. Plausible code compiles, passes the happy-path test, and reads fine on a first skim. It can still be wrong in a way that costs you a week.
So the work shifted. My job is no longer "make the change." It is "decide if this change is correct, minimal, and safe to merge." That is a reading job. It is a judgment job. And it does not parallelize the way writing does. Five agents can write five PRs at once. I can only really review one at a time.
The number that surprised me
I tracked it for two weeks. An agent took about 8 minutes of wall-clock to produce a typical PR. Reviewing that PR properly took me 15 to 25 minutes. So the machine that was supposed to make me faster produced a queue I could not clear. I had 12 open PRs and a growing sense that I was the slow part now. The agents were not the constraint. I was.
That is the real shape of agentic coding for one person. You do not get a 10x engineer. You get a very fast junior who never stops, and you become the senior who has to review everything before it ships.
How I cut the review load
Three things worked. None of them are clever.
First, smaller blast radius per task. I tell every agent to pick one task and ship the smallest credible version. A 40-line diff I can review in 5 minutes. A 600-line diff I will defer, and deferred PRs rot. Small is not a style preference here. It is the only way the review queue stays clearable.
Second, make the agent prove it works before I look. Not "the API call returned 200." Actual behavior. Did the email send. Did the function finish its async write instead of firing and forgetting. If the agent has to show me a real result, half the broken PRs never reach my queue. They fail at their own gate.
Third, a guardrail that catches the failure class instead of the instance. When an agent burned money in a retry loop, I did not just fix that PR. I gave every agent a budget limit that kills the run when it crosses a token ceiling. That is what AgentGuard does. Now that whole category of bug cannot reach review, because the run dies before it generates the diff.
The honest tradeoff
Agentic coding is a real gain. I ship more than I did a year ago, and a lot of it happens while I am asleep. But it is not free time. It moved the work from my hands to my eyes. If you adopt it and you do not build a review discipline, you will end up with a pile of plausible PRs you are afraid to merge and afraid to close. That is worse than writing it yourself.
The fix is not more agents. It is fewer, smaller, self-proving changes, and a hard gate that stops the dumb failures before they ever land on your desk. Treat your own attention as the scarce resource, because it is.
If you are running agents that write code or call paid APIs, put a budget and rate limit in front of them before you scale up the count. That is the thing that keeps the fast junior from running up a bill while you sleep. AgentGuard does exactly that, one pip install: https://bmdpat.com/tools/agentguard
