Writing code got cheap. Reviewing it didn’t, and the bottleneck quietly moved somewhere the tools aren’t looking.
Somewhere in the last year, the job changed. If you write software for a living in 2026, you probably spend more time reading code than writing it. The surveys now put review ahead of authoring, and it matches everyone I talk to. The agents write; you review. And reviewing, it turns out, doesn’t scale the way writing did.
Once an agent can write the code, you’re left with two options, and there’s nothing between them. You babysit: you stay in the loop, approve each step, correct every drift. You keep control, and yes, the code comes out faster. But you’re still the one making every call, all day, and it’s draining in a way writing never was. Or you let go. You fire off the agents, walk away, and drown in more output than any human could actually read. So you don’t read it. You skim, you approve, you merge, you tell yourself you’ll look later. When there’s more to review than time to review it, “review” stops being a thing you do and becomes a word you say.
Babysit or drown. “Stop babysitting your agents” is standard advice now (it was a session title at Code with Claude 2026), which tells you how universal the first half is. But the second half is worse, and the whole industry is pouring itself into making only that half faster: more agents, more parallelism, more throughput. A faster agent doesn’t relieve the bottleneck, though. It tightens it. More capable models produce more good-enough output, from more parallel streams, all funneling into the same single human who still has to decide what’s real. The cheap thing keeps getting cheaper; the expensive thing, human attention, stays exactly as scarce as it ever was. So the better the agents get, the worse this gets. You can’t buy your way out with a better model. A better model is what’s causing it.
What’s actually happening, I think, is a shift we’ve seen before. Before computer-aided design (CAD), engineers drew by hand: every line, in 2D, on paper. Then software let them work a level up. You stop drawing lines and start designing at a higher level of abstraction, and the machine carries the rest. It didn’t make engineers obsolete; it moved them up a rung. Software engineering is making that same jump right now, with agents, and the reason it feels so bad is that we’re mid-jump and nobody has built the bridge. We have the machine that executes at the lower level. We don’t yet have the way for a person to move up a rung without either hand-holding every step or losing the thread completely.
The industrial world solved a version of this decades ago, in aerospace, in hardware, anywhere you can’t just ship and see. They specify rigorously, in layers, because the cost of not doing so is bent metal. And agents are dramatically better when you work that way too: more structure up front, fewer painful iterations below. But the catch is brutal. Almost nobody can sit down and write their process out in advance. I’ve watched people try, and I’ve tried myself: what you write down beforehand never survives contact with the actual work. Every tool that asks you to define your workflow up front is asking for the one skill most people don’t have. That’s why “just write better specs” quietly fails as advice.
So the path up probably isn’t “specify first.” It might be the opposite. You do the work once, the messy way, babysitting the agent like everyone does today. The shape of how you did it gets captured from the work itself: the steps, and the two or three moments where you actually stopped and made a call. Next time, that shape runs, and it only pulls you in at those moments. You’re not reviewing everything anymore. You decided, once, where your attention goes, and after that review is something you designed instead of something that floods you.
That’s the part almost nothing is built for. The tooling is optimized for the agent’s compute; almost none of it is built for the human’s attention, for where it’s spent and where it doesn’t need to be. The models will keep getting better, and that race belongs to the labs. The neglected problems are the ones around them: what the agents are doing to a codebase, whether a team’s way of working survives automation, and where a person’s judgment still has to stay in the loop.
I don’t have this solved. But I’m increasingly sure the framing is right: the constraint moved from writing to deciding, and the tools that matter next will be the ones that manage human attention, not the ones that squeeze another ten percent out of the model.
If you write software in 2026 and this is your week (the babysitting, the review pileups, the debt you can’t keep up with), I’d genuinely like to know how you handle it. Where do you draw the line between what you look at and what you wave through? Have you found anything that feels like a real middle? Because I think a lot of us are quietly just choosing which exhaustion we prefer, and I don’t think we have to.
I’ve started at the narrow end of this: a bot you mention in a pull request. It makes the change, runs your repo’s own tests, and hands back a comment that’s faster to read than the diff: what it did, what it verified, and the calls that are actually yours. Open source, on your own key: repertoire-bot.com.
If this is your week too, I’d still like to hear how you handle it — in the comments or at [email protected].
답글 남기기