Opinion: AI coding agents may speed work but also raise review time and errors

There is a moment happening in offices and bedrooms all over the world right now, and it looks like this.

Three AI agent sessions are running. One is refactoring something. One is writing tests. One is halfway through a migration nobody wanted to do by hand. The person in front of them is not typing. They are watching. Their eyes move between panes like someone who put chips on three tables and cannot decide which one to be nervous about.

Then the thought arrives.

I could start a fourth one.

I call it the fourth terminal, and I think it is the defining mistake of the AI coding era. Not because running agents in parallel is bad. Because of what the reflex reveals. AI handed us spare capacity, and our first instinct was to fill it with more AI, instead of asking what the spare capacity was actually for.

I made that mistake for about four months. Nearly everyone I know made it too. This is what it cost, what the research now says about why it happens, and what the people who came out the other side are doing instead.

The AI honeymoon is real, and you should enjoy it

Let me be fair to the tools first, because the backlash has gotten lazy.

When agentic coding properly landed in my workflow, it felt like someone lifted a weight off my chest I had not known I was carrying. All that configuration written by hand. All that run, squint, fix the typo, run again. Suddenly optional.

Work that used to take a day was done before lunch. A migration I had avoided for a quarter got drafted in an afternoon. My manager noticed. My team noticed.

This is not vibes. In a controlled study of developers building a simple HTTP server, the ones with an AI assistant finished noticeably faster. In a field experiment across thousands of developers, merged pull requests rose by roughly a quarter. If your work involves a lot of greenfield code or a lot of boilerplate, the AI speedup is real and it is not small.

So we did the obvious thing. We got faster, so we took on more.

Bug report that smells like infrastructure? I am on it. Someone needs a dashboard by Friday? Sure. Ticket from March rotting in the backlog? Why not.

My open pull request count started to look like a typo.

The bill AI quietly runs up

Here is what nobody tells you about being five times faster. You can also get lost five times faster.

The first sign was easy to ignore. A colleague asked about one of my open PRs, and I had to read my own description to remember what it was for. The description had been written by AI. I was reading a machine's summary of a decision I had apparently made, in order to find out what I thought.

That is not productivity. That is a queue with your name on it.

The second sign was not small.

An agent produced a change adding a new permission set for a service. Clean diff. Sensible naming. Tests green. I reviewed it the way I had started reviewing everything by then, which is to say I scrolled, nodded, approved. It had been open six days and I wanted it gone.

Two things saved me. A teammate who actually reads policy documents left one comment: "is this wildcard on purpose?" And luck, in that the comment landed before the merge did.

The AI had done exactly what I asked. I had asked for the wrong thing, vaguely, and it filled the gap with the most permissive option available. The tests passed because the tests checked that the permission existed, not that it was safe.

That is the sentence that now governs my working day:

"All tests pass" is not the same as "this does what I meant."

Everything else in this article comes out of that gap.

AI did not remove the bottleneck. It moved it.

The most useful way I have found to think about this: the bottleneck did not disappear, it relocated.

The expensive part of engineering used to be turning an idea into syntax. Everything we built was shaped around that assumption. How we estimate, how we review, how we staff, what a good day feels like. AI made generating a first draft nearly free. So the expensive part became two other things: saying precisely what you want, and proving you got it.

The evidence for that relocation is uncomfortable. On teams with high AI adoption, pull request review time has been measured growing by around 90%, in data drawn from over ten thousand developers. Review time nearly doubling is not a sign people became more careful. It is a sign the volume arriving at review outgrew the humans standing there.

There is a stranger finding too. One study of experienced open source developers working on their own large codebases found they were about 19% slower with AI, while believing they were 20% faster. That study was later revised over a sample selection problem, so treat it as one signal rather than a verdict. But the shape matches what a lot of senior engineers quietly report. On a big messy system you already know well, AI often is not saving your time. It is moving your time from writing to checking, and checking feels like less work even when it is not.

Notice the condition, because this is where most online arguments go wrong. AI is fast on small and new. It is unreliable on large and old. Those are different situations producing different results, not two camps shouting past each other.

Then there is the AI trust paradox, which is almost funny. A large share of production code is now co-authored by AI, while roughly three-quarters of developers report frequently seeing hallucinations and say they do not fully trust the output. We are delegating more to something we trust less.

The space between how much we delegate and how much we trust deserves a name: verification debt. Time saved on writing that comes back later as an audit of code nobody understands. Unlike ordinary technical debt, it never appears on a board. It appears at 2 a.m.

Why the fourth terminal is so hard to resist

If this were only about tooling, we would have fixed it already. It is about what AI does to your sense of yourself.

Three forces push you toward that fourth terminal.

The applause. You shipped in a day what used to take a week, and someone senior said so in public. That is a drug. Chasing it is rational right up until it isn't.

The visible backlog. Your queue is a number on a screen. Your understanding is not. When one of those is measurable and the other is not, guess which one you optimise.

The fear. Research across more than three thousand developers found that somewhere between 43 and 45% of engineers carry real stress about their professional identity in the face of these tools. Running more agents feels like proof you are keeping up. It is not, but it feels like it.

That last force matters more than the productivity math, and most takes skip it. Moving from someone who shapes code with their hands to someone who reviews a machine's output strikes at an identity built on craft. Anxiety about that is a normal reaction to a real change, not a character flaw. The same research suggests teams with a genuine learning culture carry far less of it than teams running on pressure and competition.

So what do you actually do while the AI writes the code?

This is the question, and "start another agent" is the wrong answer. Here is what replaced the fourth terminal for me.

Read the thing properly

I used to skim documentation. Find the snippet, copy it, debug from there. That was not laziness — it was necessity. Writing code took so long you could not afford to digest anyone's full explanation.

AI removed that constraint, and most of us never updated the habit. Now, while an agent drafts, I read the actual reference docs for whatever it is building. Not the quickstart. The part with the edge cases.

The payoff is not trivia. It changes the next prompt. You stop steering the AI on vibes and start steering it with a map, because you already know the shape of what you are asking for. Every hour of real reading makes every later hour of delegation better.

Write the spec before the code exists

Not a ticket. A page. What the thing must do, what it must not do, what done looks like, and which parts get human review no matter how green the tests are.

For my near miss, one line would have prevented everything: no wildcard permissions, list every action explicitly. I did not write that line because I wrote nothing. Fifteen minutes of specification would have saved a week of drift and a genuinely bad afternoon.

The model to hold in your head: you stopped being the bricklayer and became the architect signing off the build. You produce the blueprint, the agents do the construction, you own the acceptance. Code is one possible realisation of your intent, not the intent itself.

Talk to an actual human

This felt like slacking the first few times. It is the highest-leverage item on this list.

Some of the best calls my team made this year came from someone messaging someone else with "got ten minutes to look at this with me" while a session ran in the background. Pairing on the review beats a fourth terminal every time, because the failure mode of AI-assisted work is not bad code. It is unexamined code, and a second human is the cheapest examination available.

Write things down where people can see them

Working notes. Decisions and the reasons behind them. Short, unpolished, posted where colleagues can read them.

I started doing this with the time I would have spent on a fourth session. People read them. People argued with them. Two of those arguments turned into real changes in how we structure environments, which is more value than that session would have produced.

The underlying principle: your AI-created spare capacity is worth more spent on what the machine cannot do than on running more machines.

Seven rules for working with AI without losing the thread

Steal these, adapt them, argue with them in the comments.

1. Spec first, always. If you cannot write down what you want in plain language, you are not ready to ask an AI for it. It will fill your ambiguity with something, and it will not ask permission.
2. Never merge a diff you cannot explain. Not "did not write." Cannot explain. Say it out loud to an empty room if you have to. If you stumble, it does not merge.
3. Security, permissions, data, and money get human eyes. No auto-accept, no exceptions, no matter how green the tests are.
4. Small batches. One agent, one clear task, one PR you can hold in your head. The three-pane casino is a trap.
5. Build verification time into the estimate. If you quote a day because generation takes an hour, you have not estimated the job. You estimated the easy part.
6. Ask the AI why, not just what. A pilot study had people learn an unfamiliar library either by using AI to investigate why things worked, or by generating and accepting. The investigators understood the library afterwards. The accepters did not. Active use builds skill, passive delegation erodes it, and the difference stays invisible until the day you need the skill.
7. One day a week without agents. Not penance. Maintenance. The judgment that lets you evaluate AI output is the same muscle that rusts when you stop using it.

If you lead a team, add two more. Measure the quality of specifications rather than the volume of output. And never issue an AI mandate without the learning culture to survive it, because an instruction to use the tools with no room to be bad at them first produces exactly the fearful, performative overuse this article is about.

The part about juniors that we keep avoiding

Plainly, because most takes tiptoe around this.

The traditional way into this profession was: write bad code, get it torn apart in review, write slightly less bad code, repeat until the instinct sticks. That loop built judgment. It was slow, occasionally humiliating, and it worked.

AI now produces the mid-level version of that output on day one. Which means a junior can look productive far past the edge of what they actually understand, and the gap does not show up in the pull request. It shows up in production, months later, when something breaks and nobody in the room can explain the system.

That is what I would worry about if I ran a company right now, more than any productivity metric. Not that AI writes bad code. That we quietly removed the mechanism by which people learned to tell good from bad, and put nothing in its place.

Part of the fix is the list above, applied harder to people early in their careers rather than more loosely. Part of it is pairing, which suddenly matters far more than it did. And part of it is telling people honestly that "it works" is now the lowest possible bar, and the job starts after that.

Every abstraction arrived with the same prophecy

Compilers were going to make programmers unnecessary, because business people would write their own programs. Fourth-generation languages were going to generate whole applications from specifications. DevOps was going to eliminate the database administrator.

Each time, the same thing actually happened. The barrier dropped, far more software got built, and demand for people who could handle the harder layer went up. The DBA did not vanish; they became a platform engineer. Nobody writes assembly by hand and nobody mourns it.

AI is the next layer, not the last one. But notice what that pattern actually promises. It does not promise your job is safe. It promises the bar rises. The people who came through each transition well were not the ones who had mastered the previous craft most completely. They were the ones who treated the new role as something to learn from scratch.

Typing speed is worth less every month. Knowing what to build, saying it precisely, and proving you got it are worth more. That trade is not a demotion, even on the days it feels like one.

So, that afternoon. I closed two of the three panes. I read the documentation for the third. Then I wrote a specification for the thing I actually wanted, which turned out to be meaningfully different from the thing the AI had been confidently building for forty minutes.

It took an hour longer than approving the diff would have. It was the first thing I had shipped in weeks that I could fully explain.

I am not shipping ten times more than I used to. I am shipping things worth ten times more, and I know why each one works.

The fourth terminal is always there. It will always be available and it will always feel like the productive choice. The discipline is not refusing to use AI. It is noticing the moment you reach for more capacity instead of more understanding, and choosing the harder one.

If you have hit your own version of this, I want to hear it. What did you do instead of opening the fourth terminal?

I hope you’ve enjoyed this and learned something new. I’m always open to suggestions and discussions on LinkedIn. Hit me up with direct messages.

If you’ve enjoyed my writing and want to keep me motivated, consider leaving stars on GitHub and endorsing me for relevant skills on LinkedIn.

Till the next one, happy exploring!