# The Trap of Unlimited Output: Why AI Coding Tools Are Making Us Less Certain, Not More Productive
## A New Kind of Idle Hands
There is an odd sensation that has become familiar in offices and home workspaces around the globe. You sit in front of multiple AI coding sessions, each one churning through work — restructuring code, generating test suites, half-finished migrations — and yet you find yourself doing almost nothing. You aren’t writing. You’re watching. Your attention splits between several panels, vibrating with a quiet anxiety that you can’t quite name.
That unnamed feeling might be the most important signal you receive all day.
AI coding assistants delivered something toolchains never could before: the illusion of spare capacity. And humans, predictably, filled every opening with more activity. But more motion is not the same as more progress, and the distinction matters enormously.
## The Speed Trap
Not long ago, developers discovered that AI-assisted workflows could dramatically compress timelines. Tasks that once consumed entire days — boilerplate generation, repetitive refactors, exploratory setup — shrank to minutes. Managerial praise followed quickly. Peer recognition arrived with the next standup. The signal was clear: go faster.
And so people did. Every new ticket was met with enthusiasm. Backlog items that had languished for months suddenly demanded immediate attention. The pull request count ballooned to numbers that looked reckless, and nobody felt compelled to slow down.
But speed creates its own tax. When you produce ten times the output you used to, you also acquire ten times the ambiguity, ten times the half-understood architecture hooks, ten times the decisions hidden inside machine-generated commits that you approved without fully reading.
## Where the Bottleneck Actually Lives
A common misconception held that AI would eliminate engineering bottlenecks. It didn’t. It relocated them.
The expensive part of software development used to be converting thoughts into syntactically correct code. Every process around it — estimation, code review staffing, sprint planning — assumed that constraint. When generation became nearly free, the scarce resource shifted to two things: articulating exactly what you need, and proving that what you received is correct.
Studies of development teams with high AI adoption show this shift in stark numbers. Code review turnaround times have roughly doubled across large teams, not because engineers grew more careful, but because the volume of output arriving for review overwhelmed the human capacity to assess it. Another body of research found that experienced developers working on large, familiar codebases ran about 19% slower when using AI, despite believing they were moving 20% faster. The gap between perceived velocity and actual understanding widened quietly.
This split — fast on new and small problems, brittle on large and legacy ones — is where most online debates fundamentally misunderstand the technology. These are different situations producing different results, not ideological positions to be defended.
## The Trust Gap
Here is what makes the situation almost paradoxical. A growing share of production code is now co-authored by AI, while most developers openly report encountering hallucinations frequently and express skepticism about the outputs they receive. We are entrusting our systems to something we largely distrust, and we have not built the guardrails to make that trust relationship safe.
The cost of this mismatch deserves its own term: verification debt. It is time saved during generation that returns later as an auditing burden nobody planned for. Unlike traditional technical debt, it rarely appears on a project board. It surfaces at 2 a.m. when something in production breaks, and the person on call cannot explain why the code behaves that way.
## Why More Sessions Feel Like Progress
Three psychological forces make it remarkably difficult to resist opening one more tab, spinning up one more agent.
First, the applause. Delivering work rapidly invites recognition, and recognition is deeply addictive. The dopamine loop reinforces itself — ship quickly, receive praise, chase more of the same. This pattern is rational right up until it produces a mess you cannot navigate.
Second, the visible queue. A backlog count is a number on a screen. Your comprehension of the system is not. When one is measurable and the other is intangible, optimization gravitates naturally toward the former, and the latter quietly atrophies.
Third, and perhaps most importantly, the fear. Across large surveys of engineers, a significant share report genuine anxiety about their professional standing in an era where AI tools change the nature of the work. Running additional agents feels like evidence that you are staying relevant. It is not evidence of anything — but the feeling is powerful.
This last force is often dismissed as sentimentality, but it shapes behavior more than any productivity metric ever will. The transition from someone who shapes software with their hands to someone who inspects machine-generated output strikes at an identity rooted in craftsmanship. That discomfort is a normal human reaction to a genuine transformation, not a weakness.
## What Replaces the Extra Terminal
The people who emerged from this phase with clearer thinking didn’t simply restrict themselves to fewer agents. They replaced empty busyness with something structurally different.
### Read the Docs, Not Just the Output
Before AI, reading documentation felt wasteful because writing code took so long that there was no room for deep dives. AI lifted that constraint, and most workflows never updated the habit. The people who use these tools well now read the full reference material for whatever they are building while a session runs. Not the quickstart page — the sections with edge cases, limitations, and gotchas.
That reading changes everything about the prompts that follow. Instead of steering by instinct, you steer with a map, because you already hold the shape of the problem in your head.
### Write the Specification Before Writing Anything Else
Not a project ticket. A meaningful document that describes what the system should do, what it absolutely must not do, and what “complete” looks like. Crucially, it identifies which parts require human judgment regardless of test results.
Fifteen minutes spent naming constraints explicitly can prevent weeks of drift. When you describe nothing, the AI invents something — and the most convenient option is rarely the safest one.
### Collaborate with Another Human
This sounds counterintuitive in an era of tools designed to replace the need for colleagues. But some of the strongest engineering decisions in recent memory came from someone pausing a session and saying, “I have ten minutes — can you look at this with me?” A second human mind is the cheapest, most available auditing instrument we possess.
### Document Your Thinking
Working notes, posted publicly — decisions made, reasons for them, questions left open. What starts as a personal habit quickly becomes a team asset. Disagreements over those notes have led to architectural changes that no additional session ever could have produced.
The core principle is this: your artificial spare capacity is worth more when spent on what machines cannot do than on running more machines.
## A Few Ground Rules for the New Normal
If you lead a team, consider building these practices into the way your group operates.
1. **Make the specification the first deliverable.** If you cannot state what you want in unambiguous plain language, you are not ready to delegate the task. The AI will fill ambiguity with something, and it will not ask permission before doing it.
2. **Never approve code you cannot explain out loud.** If you have to pause to remember why a change exists, that change does not belong in the codebase yet.
3. **Put human review on anything involving access control, financial logic, or sensitive data.** No automated approval, no exceptions, regardless of test coverage.
4. **Work in small, legible increments.** One agent, one clear objective, one pull request you can hold entirely in your mind. Anything more is a casino, not a workflow.
5. **Build validation time into your estimates from the start.** If you are pricing a task based on generation speed alone, you have priced only the easy half.
6. **Ask the tool why, not just what.** When learning something new, focus on understanding the reasoning behind decisions rather than accepting generated suggestions at face value. Passive consumption erodes skill; active investigation builds it.
7. **Designate one day per week with no agent assistance.** Not as punishment. As maintenance. The same judgment that lets you evaluate AI output is a muscle that weakens when you never exercise it.
## What This Means for People Early in Their Careers
The traditional path into engineering involved writing imperfect code, having it dissected in review, writing slightly less imperfect code, and repeating that cycle until sound instincts became automatic. It was aggravating and slow, but it worked.
AI now produces competent-looking output on a first attempt, which means someone with a year of experience can appear to contribute at a level that matches someone with three. The gap does not show up in the pull request — it appears months later in production, when the system breaks and nobody in the room truly understands why.
For anyone managing a team, this is the quieter risk underneath the flashy productivity gains. We have not yet replaced the failed attempts and awkward reviews that built genuine understanding with an equivalent training mechanism.
## Each Wave Raises the Bar
Compilers were supposed to end the need for programmers. Fourth-generation languages were supposed to let non-engineers build full applications. DevOps was supposedly going to phase out a whole category of specialist role. None of those predictions came true. Instead, each wave raised the floor of what was expected while opening entirely new categories of work. The database administrator did not vanish — they became someone who operates at a higher level of abstraction.
AI is the next wave, not the final one. And the pattern it follows is consistent: the people who thrived through every prior transition were not those who had mastered the previous craft most thoroughly. They were the ones willing to start fresh, to treat the new landscape as something to learn from zero, to invest less in typing speed and more in knowing what to build, stating it with precision, and proving the result matches the intent.
## A Plain Conclusion
The AI fourth session is always available. It will always feel productive in the moment. The discipline is not refusing to use the tools — it is noticing the exact instant you reach for more capacity when you actually need more understanding, and choosing the harder path.
You will not ship ten times as much as before. What you will ship is work you can fully account for, work that reflects decisions rather than defaults, work whose entire existence you can explain to the person asking why.
That is not a small thing. It may be the only competitive advantage left that no model can copy.
## Frequently Asked Questions
**Q: Is using multiple AI agents in parallel always a bad idea?**
No. The problem is not the number of agents. The problem is the reflex behind adding another one — filling capacity with more activity instead of using time to deepen understanding. Parallel sessions can be appropriate when each has a clearly separated scope and a human owns the acceptance criteria for all of them.
**Q: What exactly is verification debt?**
Verification debt is the future auditing burden created when you accept AI-generated output without fully understanding or testing it. It never shows up in project plans because it looks like saved time. It shows up later as production failures and unexplainable code paths.
**Q: How do I know if I’m in the “applause trap”?**
You are likely in the trap if your internal motivation for shipping has shifted from building something valuable to accumulating open pull requests and receiving praise for speed rather than quality. Ask yourself whether you could explain every change currently in your backlog.
**Q: What should managers actually measure instead of output volume?**
Good alternatives include the clarity of specifications before code is written, the depth of code review discussions, the percentage of production incidents where an engineer can trace the root cause, and whether new team members are developing real understanding or just learning to approve AI changes.
**Q: Is AI really slower for experienced developers on legacy code?**
Some studies suggest experienced developers working on unfamiliar or large legacy systems can be measurably slower with AI than without, while falsely believing they are faster. The effect is strongest when the human already understands the domain well and AI introduces friction by adding noise or unnecessary complexity.
**Q: What is the single most important habit for a developer using AI tools daily?**
Write the specification before you run your first query. Fifteen minutes of articulating what you want, what you do not want, and what success looks like prevents hours of misaligned output and produces code you can actually explain.
**Q: How does this affect junior developers differently?**
Juniors traditionally learned by making mistakes that were caught in review. AI can generate plausible-looking output on day one, allowing juniors to appear productive before they actually understand the system. Without deliberate countermeasures — heavy pairing, manual code review, explicit expectations that “it works” is the bare minimum — this can create large competency gaps that surface only under pressure.
## Final Thoughts
Thank you for reading. The ideas in this piece are meant to spark reflection and honest conversation about how we integrate powerful tools into our daily craft without losing the things that make engineering meaningful. The goal is not to reject AI — it is to use it with intention rather than reflex. If something here challenged your assumptions, I would welcome your perspective on how you are navigating this shift.
