Your team is faster than it has ever been.
PRs merged is up. Lines shipped is up. The Jira board moves like it has a tailwind. Six months ago the team of twenty was the bottleneck. Today the team of twenty produces at the rate of forty.
And more things are breaking.
Production incidents tick up. Senior engineers spend half their day reviewing AI-generated PRs from juniors. Bugs that used to get caught in code review now get caught in customer Slack channels. The team is faster — and worse.
The tempting explanation is growing pains: the team will adapt, throughput will normalize. I do not think that is what is happening. Volume just became free, and we are still running the playbook from when it was expensive.
Volume Is Now Free
For most of software’s history, volume was the binding constraint. The person who could write more code, ship more features, generate more drafts was the productive one. Companies hired against the constraint. Output equaled value.
AI broke that equation in two years.
A developer with Copilot produces code at three to ten times the previous rate. An analyst with Claude drafts analysis in minutes. The volume floor moved up by an order of magnitude, everywhere, at once. When a constraint relaxes for the entire market simultaneously, it stops being a source of advantage. It becomes table stakes.
CodeRabbit’s framing of the 2025-to-2026 transition is blunt: cycle time is being replaced by defect density, merge confidence, and maintainability as the metrics that matter. Speed stopped being scarce. Something else became scarce in its place.
The printing press did not make scribes more valuable. It made editors essential — the work that survived was the part that had to govern an avalanche of cheap output. The new scarce resource has a name that sounds almost boring: correctness.
The Almost-Right Problem
Not perfection. Not zero defects. Correctness in the practical sense — output that is architecturally sound, strategically coherent, and free of the compounding subtle errors that look fine for three weeks and surface in a customer ticket.
The code-quality studies show why review takes more work. CodeRabbit analyzed 470 open-source pull requests and found AI-generated code produced 1.7 times more issues than human-written code across every quality category. Logic and correctness errors rose 75 percent; performance inefficiencies appeared nearly eight times more often. A separate audit of 211 million lines from Google, Microsoft, and Meta — the GitClear dataset — confirmed the same eight-times excess-I/O pattern at scale. As Copilot adoption ramped from 2022, code volume surged and quality moved the other way. Defect density became a vital sign engineering dashboards never used to monitor.
The deeper problem is not that AI produces more errors. It is that AI errors are harder to catch.
A peer-reviewed Purdue study tested ChatGPT against 517 Stack Overflow programming questions. 52 percent of the answers were incorrect. The user study then examined whether people caught the errors: in a user study, participants overlooked the misinformation 39 percent of the time, and preferred the ChatGPT answers 35 percent of the time despite their being wrong — because the answers were comprehensive, polite, and confident [2].
Confidently incorrect output reads like correct output. A human who is wrong sounds uncertain; an LLM that is wrong sounds poised. The hedges, the qualifications, the “let me check that” — the pattern recognition we evolved for trustworthiness is exactly what AI strips out.
Stack Overflow’s 2025 Developer Survey, with 65,000 respondents, put numbers on the resulting frustration. Forty-five percent named “AI solutions that are almost right, but not quite” their number-one frustration. Sixty-six percent reported spending more time fixing AI-generated code than they save generating it. Clear wrong gets caught. Almost-right ships.
Then there is verification debt. LeadDev put it in one line: you write less code because generation is fast, and review more because understanding it takes time. Comprehension is free when you write code; it must be rebuilt during review when something else writes it. Ninety-six percent of developers do not fully trust AI-generated code; fewer than half review it before committing [9]. Generation outpaced verification, organization-wide.
The $14,200 Tax
Verification is the most expensive hour of work in your company right now, even when it has no separate budget line.
Microsoft’s 2025 data shows knowledge workers spend 4.3 hours per week fact-checking AI outputs. Forrester’s translation of that into dollars — aggregated in 2026 hallucination-cost reporting — comes to roughly $14,200 per enterprise employee per year in verification overhead that produces zero deliverables. A team of twenty pays that tax twenty times. A team of five pays it five — and pays for expertise that is concentrated, not diffused.
That number does not include the failures, the times the check did not happen or did not work. Global financial losses tied to AI hallucinations reached $67.4 billion in 2024; enterprise incidents in finance ran from $50,000 to $2.1 million each. You can pay for verification, or you can pay for the consequences of skipping it. Shipping faster does not remove the cost of checking or repairing the work.
But Speed Still Wins, Right?
History rewards shipping, not perfecting. Amazon, Meta, and Google did not win by being correctness purists. They won by moving faster than their competitors at acceptable quality. Every previous “quality over quantity” wave produced reasonable wins for a few firms and conference talks for everyone else.
I take that objection seriously because I have made it myself. Speed compounds. Optionality from shipping early is structurally underrated.
What changes with AI is not whether speed matters. It is where speed comes from. When generation was the bottleneck, speed came from generating faster. When generation is free, speed comes from eliminating the rework cycle. That 66 percent figure describes a team that is not actually shipping faster — it is shipping a draft, then re-shipping the corrected version. The org chart shows velocity; the customer experiences cycle time that has barely moved.
The correctness economy is not the new craft movement. It is the recognition that correctness is the speed bottleneck now. Teams of five focused on correctness are not slower than teams of twenty focused on volume. They are faster, because they ship once.
The Sniff Check
If correctness is what makes shipping fast, then the skill that creates correctness creates speed. Generators give you drafts. Verifiers give you releases.
I borrowed the phrase “sniff check” from a senior engineer in a code review. She was looking at a Claude-generated diff that compiled, passed all tests, and looked clean. She said: “Something is off. I cannot tell you what yet, but I am going to find out.” Twenty minutes later she had the race condition. The tests had not been written to exercise it — the AI had generated the tests too.
That is the sniff check: triaging AI output into “I trust this, ship it” and “something is wrong, dig in.” Stack Overflow’s 2025 numbers capture the inversion: only 2.6 percent of experienced developers report high trust in AI output; 20 percent report high distrust. The people whose names go on the production incident report trust the output least. That is calibration, not pessimism.
You cannot hire for “vibes-based quality detection,” the objection goes. Half right. The experienced developers who have the sniff check can articulate, when pressed, what they look for. The competency decomposes into four trainable parts:
Pattern memory for known AI failure modes. LLMs fail predictably on date arithmetic, recursive data structures, concurrent state, anything requiring multi-step logical bookkeeping. Stanford’s AI Index notes that LLMs structurally cannot reliably solve problems requiring provably correct solutions, and the limit worsens on instances larger than training data [7]. Knowing it lets you flag entire categories of output for deeper review before you touch the diff.
Verbosity-as-confidence calibration. Purdue’s study found a tight correlation between verbosity and incorrectness — and between verbosity and user preference [2]. Confident wrong answers are longer. Polish becomes a yellow flag, not a green one.
Suspicion of suspicious cleanness. Real code has loose ends. Real analysis has caveats. AI output is often suspiciously tidy — the architectural equivalent of a stock photo: technically perfect, oddly inert. Tidy in a domain where the right answer should be messy is a tell.
Updated mental models per model generation. GPT-4-era failure modes are not Claude-era failure modes. A sniff check calibrated three years ago is partly obsolete. The competency requires monthly recalibration, the same way infosec people refresh threat models.
None of this is magic. All of it is teachable. And the predictable rebuttal — “GPT-5 or Claude 5 will fix this in 12 to 18 months” — misses what is being claimed. Better models may reduce error rates. They will not eliminate the human job of deciding what counts as “right enough” for a specific business context. That decision lives in the gap between probabilistic generation and deterministic requirements, and the gap is permanent.
Teams of 5 Beat Teams of 20
Brooks’s Law, first articulated in 1975, observes that adding people to a software project adds communication overhead scaling as n(n-1)/2. A team of five has ten paths. A team of twenty has one hundred and ninety. A study of 117 Finnish software projects confirmed empirically that team size correlates negatively with per-person productivity [10].
AI does not soften Brooks’s Law. It amplifies it. Each new team member generates more output, faster, that the rest of the team has to verify. Coordination overhead scales worse than the volume it coordinates.
The Correctness-First Org Design is five steps:
1. Audit the rework cycle. For two sprints, track three numbers per developer: time spent generating, time spent reviewing AI output, time spent fixing post-merge issues. If correction time exceeds 40 percent, the team has a volume problem dressed up as a productivity gain.
2. Identify your correctness carriers. Three signals triangulate them: who catches the most issues before merge, whose AI-generated code produces the fewest post-merge incidents, and who other developers seek out when they are unsure. Typically 20-30 percent of the team generates 70 percent or more of the correctness value.
3. Restructure into squads of four to five around the carriers. Each squad gets a verification lead with merge veto authority, two to three generators, and explicit domain ownership. Cap squad size at five — paths jump from ten to fifteen with a sixth person.
4. Build the verification playbook. Document the carriers’ heuristics: known AI failure modes per domain, output characteristics that correlate with incorrectness, test patterns that catch AI-typical errors. Update monthly. The playbook turns individual sniff-check into organizational capability — and answers the bus-factor objection. Knowledge written down is more durable than knowledge spread thin across twenty informal channels.
5. Measure correctness economics. Replace cycle-time KPIs with defect escape rate, time-to-detect, and verification coverage. Build a monthly dashboard comparing cost of verification (engineer hours) to cost of escaped defects. Target a 3:1 ratio — every dollar on verification prevents three in remediation.
This is not theoretical. Multiple correctness-focused squads, each owning a domain, give you scale without the coordination tax, and the playbook solves bus-factor risk without adding headcount.
The framework has limits. Where the cost of incorrectness is near zero — disposable prototypes, internal one-off tools, exploratory spikes — volume is fine and none of this applies. But where architecture matters, where strategy compounds, where being wrong carries a downstream cost — most paid software work — five people who verify will outperform twenty who generate.
What to Do Monday
Start with the rework audit. Two sprints. Three numbers per developer: generation time, review time, post-merge fix time. It costs almost nothing and will tell you whether your team is doing work or doing rework.
Under 25 percent correction time: you are probably fine. The team is using AI well; the structure does not need to change.
Between 25 and 40 percent: early signs of a verification problem. Start identifying your correctness carriers. Document one verification heuristic per week.
Over 40 percent: you have a volume team in a correctness economy. The longer you wait to restructure, the more rework you will pay for. Begin the squad reorganization next quarter, not next year.
The transition is not about layoffs. It is about reassignment as AI absorbs the generation capacity that used to require headcount. The roles that compound are verification roles. The hiring filter that compounds is the sniff check. The metric that compounds is correctness density, not volume.
AI made volume free. It also means volume no longer tells you how much useful work survived review.
You can pay for verification on purpose, or you can pay for errors in incidents.
References
- [1, 8] CodeRabbit, “State of AI vs Human Code Generation Report” (2025) and “2025 Was the Year of AI Speed. 2026 Will Be the Year of AI Quality.” (2026). coderabbit.ai/blog.
- [2] Samia Kabir et al., “Is Stack Overflow Obsolete? An Empirical Study of the Characteristics of ChatGPT Answers to Stack Overflow Questions,” Purdue / ACM CHI 2023. arxiv.org/abs/2308.02312.
- [3, 4] Stack Overflow, “2025 Developer Survey: AI Trust and Accuracy” (65,000+ respondents). survey.stackoverflow.co/2025/ai.
- [5, 6] Suprmind, “AI Hallucination Statistics: Research Report 2026,” aggregating Forrester, Microsoft, and Deloitte data. suprmind.ai.
- [7] Stanford HAI, “The 2025 AI Index Report,” Technical Performance chapter. hai.stanford.edu/ai-index/2025-ai-index-report.
- [9] LeadDev, “You Can’t Verify All the AI-Generated Code” (2025); Harness State of Software Delivery 2025. leaddev.com/ai.
- [10] “Empirical Findings on Team Size and Productivity in Software Development” (117 Finnish projects, ResearchGate); Brooks’s Law summary at effectiviology.com/brooks-law.