I recently had a conversation with a colleague about something that was bothering both of us: developers have never produced so much code. And yet, many teams aren't delivering any more value than before. It took me a while to put my finger on what was really nagging me about this situation. AI isn't the problem. The problem is what we gave up to make room for it.
For more than twenty years, part of our industry has been investing in bringing the humans who build software closer together. As early as 2001, the Agile Manifesto stated that face-to-face conversation is the most effective method of conveying information — the same year the term shift left first appeared. Pair programming, mob programming, continuous code review: not every team adopted these practices. They required real effort, and remote work had already weakened them.
But the teams that had made that investment were reaping the rewards: fewer silos, knowledge that circulates, problems caught early. Then AI arrived and, within a few months, those same teams watched each person retreat to their corner with their personal assistant. The silos they had spent years dismantling came back. Nobody forced this on us. We did it ourselves.
Let me be clear from the outset: this is not an article against AI. I use it every day, and I wouldn't go back. This is an article about a human reflex that fascinates me as much as it worries me: the impulse to throw out proven practices the moment a new tool arrives, without asking what problem those practices were solving.
Let's take a moment to remember why these practices existed in the first place.
Pair and mob programming were never about "writing code with two people." Writing the code was the visible part — almost incidental. The real value was elsewhere:
We've written about this before on this blog in Pair and Mob Programming: For Psychological Safety!, and shift left rests on the same idea we cultivate in our Learning Hours, among other places: the earlier a problem is detected, the less it costs to fix.
The data pointed in the same direction. Dragan Stepanović analyzed tens of thousands of pull requests across some forty repositories to measure the effect of asynchronous review on team throughput. His finding: small PRs multiply interruptions and context switches, while large ones get surface-level reviews — the infamous "Looks Good To Me 👍" after thirty seconds of reading. He draws a deliberately provocative conclusion: the optimal PR size would be one line of code, reviewed immediately. In other words, pairing.
Let's stay nuanced: this isn't peer-reviewed research, and asynchronous review works perfectly well for open source, where nobody shares the same schedule. The signal applies to a team that works together every day: every code review sitting in a queue costs throughput and context. It's no coincidence that the DORA metrics, now the standard for measuring software delivery performance, revolve around these same notions: cycle time, throughput, stability. These practices were never about writing code faster. They were about getting work all the way to production.
Keep that image of the queue in mind. Because if it was already expensive before AI, imagine what happens when you multiply the volume of code entering it.
There's a lens I find particularly useful here: Eliyahu Goldratt's Theory of Constraints. Every production system has a bottleneck, and the throughput of the entire system is the throughput of its bottleneck. The implication is counterintuitive: speeding up a step that isn't the bottleneck improves nothing. Work just piles up faster in front of the bottleneck.
"An hour saved at a non-bottleneck is a mirage." — Eliyahu Goldratt, The Goal
Writing code stopped being the bottleneck of software development a long time ago. Cycle time data shows it: when you measure a team's workflow, active work typically represents only 5 to 15% of cycle time. Everything else is waiting between steps. Understanding the problem, aligning on a solution, validating what comes out: that was the bottleneck. AI just lifted the "writing code" constraint... which was no longer the constraint.
People will point out, rightly, that AI doesn't only speed up writing: it also does first-pass code review, summarizes PRs, explains legacy code. That's true, and genuinely useful. On our teams, many people use it to surface code smells and get an overview before diving into a review — a foot in the door rather than starting from zero. But the bottleneck was never reading the code. It's the shared understanding between the humans on the team. An AI that reviews a PR shortens the queue; it doesn't deposit knowledge into anyone's head.
At Nexapp, an internal survey this summer surfaced concerns that kept coming up: cognitive overload, change anxiety, fear of skill atrophy. We launched a series of Learning Hours to discuss them across teams, and the observations from the session on cognitive load all pointed the same way. Development teams are seeing more open PRs in a single day than they had ever seen. Developers are spending more than half their day on reviews. One colleague, left nearly alone during the vacation period, opened about fifty PRs in ten days; the two who remained had to absorb all of it, with entire days where no review got done because they were pushing their own tasks forward.
And while your PR waits, you don't sit idle: you do something else with your agent. As one colleague summed it up: while my prompt is running, I review someone else's PR; my brain jumps from A to Y, then comes back to B. More work in progress, more context switching, more cognitive load.
That feeling of moving faster is, in fact, documented as deceptive. In a randomized trial by METR conducted with experienced open source developers on real tasks, the result is striking:
Participants were 19% slower with AI... while estimating they had been 20% faster.
The tools have evolved since then, and METR says so themselves. The lasting lesson lies elsewhere: feeling faster is not the same as delivering faster.
At the industry level, the DORA reports measure the same tension. In 2024, AI adoption was associated with a decline in delivery throughput and stability. In 2025, throughput recovered, but the instability persists. Their reading: teams have adapted to the speed, but their systems and processes haven't kept up. AI amplifies what the team already does — for better or for worse.
This is the paradox that opened this article: we've never written so much code, and yet many teams can't manage to deliver more value. AI didn't eliminate the bottleneck. It made the queue in front of it much longer — and brought back, along the way, the silos we had spent years dismantling.
Other teams solved the bottleneck differently: they went around it. Rarely openly; few people proudly announce that they've abolished code review. The version you actually encounter is more subtle: AI does the first-pass review, and the human keeps the critical points. On paper, that's reasonable. The drift begins when the first pass becomes the only pass, when approval boils down to a glance at the generated summary, and when code goes from agent to production without a human brain ever really passing through it.
Let me ask you the question that's been rattling around in my head: which is better — a developer who codes without writing tests, or an AI that codes and writes its own tests without a human validating them? And if a second AI reviewed the first one's work, would we be any further ahead?
You can push this logic all the way to the autonomy scales where the agent picks its own tasks and chains them together without a human initiating anything. Tellingly, even the people who define those scales warn that supervision must intensify as autonomy increases — not decrease.
Let's be honest: with good standards and a robust test suite, that code can work just fine. The defect rate doesn't necessarily explode. What accumulates is more insidious than classic technical debt: a comprehension debt. Every delegated step removes a pair of human eyes from the process. AI codes, AI tests, AI reviews, and the system works... until the day it doesn't. And then, no spectacular explosion. Just a team unable to reason about its own system. Before AI, a silo meant knowledge stuck inside one person. The AI-era silo is worse: the knowledge never made it into a human head at all.
Some will say we've survived every rise in abstraction, that nobody reads the assembly generated by the compiler anymore. But the code AI generates isn't a stable abstraction layer proven by millions of users: it's your domain code, and nobody else is coming to understand it for you. And an explanation on demand has never replaced a team that understands its system at the moment production is on fire.
Aviation has lived with this paradox for forty years. The autopilot flies the plane during cruise, but it's still humans who take off, who land, and who answer for the flight. And it's precisely when cockpits became automated, in the early 80s, that the industry established its crew coordination practices and documented the "ironies of automation" (Bainbridge, 1983): the more autonomous the system, the more critical human vigilance becomes — and the more manual skills atrophy if they aren't maintained. That fear of atrophy is exactly what our developers named in our internal survey. There's nothing irrational about it: it's a documented phenomenon among pilots.
Tip: The human keeps responsibility for what they ship. Standards and tests reduce the risk of defects, but they transfer neither responsibility nor understanding to the machine. If nobody on the team can explain a piece of code in production, that piece of code is a risk — no matter how well it passes the tests.
It would be easy to blame laziness or hype. I think the real reason is more interesting: we had confused these practices with their visible output.
If you think pair programming is about writing code with two people, then AI does indeed make it obsolete. It writes code faster than any pair. But if you know that pairing is about creating shared understanding, reviewing continuously, and circulating knowledge through the team, then AI doesn't replace it at all — because it does none of those things. The code was only the by-product. The shared understanding was the product.
In other words, we didn't abandon practices that had become useless. We abandoned practices we had never fully understood. And I include myself in that: it took watching the silos come back for me to realize how much those ceremonies carried something bigger than the code they produced.
The good news is that this diagnosis points directly to the solution. If the function of these practices is still needed, all we have to do is change their form.
At Nexapp, some teams had a practice we called the Architecture Plan, well before AI. Before coding a task, developers would gather at the whiteboard to sketch out what needed to be added, removed, or modified — sometimes as a UML diagram, sometimes directly in the code as interfaces and empty functions. An agile backlog refinement, but at the code level. We refined the technical plan to flush out the unknowns and the blockers, and to decide whether a refactor was needed before starting. The plan was made as a team; the implementation, solo. The most visible effect was on code reviews: they became much faster, because reviewers already knew the intent.
With AI, this practice hasn't lost its reason for being. It has gained a new one. A real example: for a large data migration from Firebase to a SQL database, one of our developers built a complete multi-step plan with AI, then presented it to the colleagues who would be reviewing the work — before writing a single line of code. They looked at the breakdown together: what was coming in each step, what they would have split differently. The implementation then produced seven or eight PRs.
The observed result: reviews far faster than on a previous large project that hadn't received this treatment. The reviewers already knew what each PR was there to do; all that remained was to check the how. The thinking had already been done — and it had been done together.
This is the full loop of this article: the code review bottleneck, solved not by removing the review, but by moving it earlier — onto the plan rather than the code. Shift left, applied to the age of agents. As a bonus, a plan expressed in clear steps, or even as interfaces and empty functions, is exactly the kind of structural constraint that keeps an agent from drifting during implementation.
The same reasoning applies elsewhere, and our teams are experimenting with several forms right now:
One colleague summed up the principle better than I could have:
"If you're asking for human attention, you have to show human effort."
Because let's be frank about the costs: these practices are paid for in synchronous team time — the most expensive resource we have. An Architecture Plan is a meeting before the task. A mob review is an hour with several people. But it's not time added to the schedule: it's the time we were already burning on back-and-forth comments, restarted reviews, and architecture decisions challenged too late. We're just spending it earlier, and together. A simple rule helps keep the balance: if the reviewer spends more time on a PR than its author did, something is wrong upstream.
I'm not claiming these exact forms are right for every team. The point is the approach: identify the function the practice was serving, then find the form that serves that function on a team where AI writes most of the code.
G.K. Chesterton told the story of a fence that seems useless: before removing it, you must first understand why someone built it. Our development practices are those fences. They look like mere rituals — until you remove them and the problem they were containing moves back in.
AI won't be the last tool to upend how we work. The next time a tool makes you want to drop a practice, ask yourself the question before throwing it out: what problem was this practice solving? If the problem is gone, discard it without regret. But if the problem is still there, keep the function and change the form. Otherwise, all you're doing is removing the fence.
AI didn't kill our best practices. It handed us a convenient excuse to fall back into our old reflexes — and we took it. The way out of this isn't less AI, nor a nostalgic return to the ceremonies of before. It's practices rethought so that shared understanding survives automation. Our teams took ten years to learn that software development is human. It would be a shame to unlearn that in ten months.