A candidate told me this during an interview after we flagged gaps in his engineering craft culture. His answer was blunt: with AI, what matters is speed.

Easy to dismiss. Except I hear the same thing in the teams I work with, just phrased differently.

What the data already shows

Faros measured the impact of AI adoption across 22,000 developers and 4,000 teams over two years.

Individual throughput is up 34%. Epics completed per developer, up 66%. AI accelerates code production. Nobody disputes that.

On the other side: bugs per developer are up 54%. The incident-to-PR ratio has tripled. Code churn is up 9x. Lead time, 5x. And 31% more PRs are being merged without any review at all.

Some of this can be explained by increased volume and more ambitious projects. You could also argue that higher churn reflects refactorings teams would never have tackled without AI. But that doesn't explain why teams are discovering their own implementations for the first time during production incidents.

The hardest finding in the report: organizations with strong pre-AI engineering practices are not protected. Teams with solid foundations, mature review processes and high DORA scores see the same degradation. Code generation has become so cheap that it overwhelms existing quality mechanisms.

Some CTOs I talk to are convinced their mature teams will absorb AI naturally. The data suggests otherwise.

That doesn't mean old practices should survive as-is.

Craft was never about the code

For years, we believed craft meant writing elegant code, applying patterns, maintaining clean architecture. AI is very good at producing all of that. Idiomatic code, well-named, stylistically consistent. If craft were just that, the candidate would be right: it's outdated.

Code was the observable surface of something else. A team's ability to build a shared mental model of its system and domain. Knowing which trade-offs were made and why. Knowing what deserves to be simplified and what needs to stay complex.

In a team I was in the process of structuring, I tried to introduce pairing. The response was immediate: "we have Claude Code." Same thing with cross-reviewing technical specs: "one review is enough."

No resistance. A rational shortcut. And not an absurd one. Pairing was expensive. Mob programming was slow. Nobody misses the days when a two-hour refactoring took a full day in a pair. You could even argue that Claude Code is a form of pairing, with a machine instead of a colleague.

Except a machine's challenge doesn't replace a human's. It improves an individual decision. It doesn't automatically build collective understanding. Pairing is about one developer understanding and challenging another's choices, not about writing code together. Spec review is about the team aligning on the problem before coding. TDD is about specifying expected behavior before writing a single line (Kent Beck goes as far as enforcing TDD in his agents' system prompts, because without it, the agent deletes the test rather than fixing the code). Mob programming is about anchoring conventions through collective imitation.

Each of these practices produces a deliverable. And each builds, in parallel, a shared understanding of the system. AI produces the deliverable. Not the rest.

The gain is real. We deliver faster, we have more tests. But I observe that teams don't use the time saved to think. They use it to pick up the next ticket. Sometimes to improve overall quality, strengthening tests or documentation for instance. Often, practices like pair programming, mob programming, spec reviewing don't even get the chance to take hold. AI provides the shortcut before the practice has proved its value.

This isn't a critique of AI. It's a critique of what AI amplifies. Dave Farley puts it bluntly: teams with good practices benefit massively from AI. The rest produce worse software, faster.

Craft is shifting

Some teams delegate to AI. The spec, the tests, the code. AI produces, the team validates and moves on. Others use it to think. They specify expected behavior in TDD, then let AI code. They write the first draft of the spec themselves, then use AI to tear it apart: what could break, what case was missed. They read the generated tests asking what they don't cover.

Martin Fowler talks about "letting go of the obsession with perfect code line by line to strengthen understanding of the domain and the overall architecture." Craft isn't disappearing. It's shifting. Execution matters less. Judgment and domain modeling matter more. This already separated good teams from the rest, but now the gap is visible.

The question for every team: are we using AI as a sparring partner that forces us to think, or as a competent colleague we delegate to?

Craft isn't dead. Not yet.

For twenty years, engineering practices served two purposes: producing software and building collective understanding. AI now produces much of the software.

We measure throughput, closed tickets, merged PRs. We almost never measure distributed understanding. Who knows what in the team. How long it takes to modify a system six months after building it. What it costs to explain an architectural decision to someone who just joined.

For a long time, production speed was a reasonable signal of a team's health. When writing code becomes nearly free, that signal gradually stops being reliable. If AI now produces the software, there's a question nobody is asking enough: how do we measure the quality of collective understanding that allows us to evolve it?

That candidate thought craft was dead. Execution craft is receding, yes. But craft was never really about the code. Craft is now about producing the understanding that allows the code to evolve.

AI makes code abundant. Understanding remains scarce.

Sources and related articles

Data

• Faros AI Engineering Report 2026, "The Acceleration Whiplash" — 22,000 developers, 4,000 teams, two years of telemetry

Craft voices on AI

• Kent Beck — TDD, AI agents and coding (The Pragmatic Engineer)
• Kent Beck — Augmented Coding: Beyond the Vibes
• Dave Farley — The AI Shift is Bigger Than Internet and Agile (Aviator podcast)
• Martin Fowler & Kent Beck — Tech Truth: Agile Evolution & the Future of SW Engineering (GOTO 2025)

Related articles (AI and Quality series)

• Cheap to build, costly to keep (comprehension debt)
• "It's historical" (organizational knowledge)
• Tokenmaxxing (AI metrics and ROI)
• AI doesn't replace juniors (training and knowledge transfer)

Except velocity didn't drop by half. It dropped by maybe 20%, possibly less. Standups got shorter. PRs moved faster. The people who stayed knew exactly what to do, and they finally had room to do it.

To be fair, what made the difference is partly that the right people had stayed. The ones actually driving projects forward hadn't left. Critical domains were still covered. Scope had shrunk. The headcount reduction didn't improve anything on its own. What mattered was who remained.

And that raises a broader question: why do some people weigh so much more than others in an organization's ability to ship?

Barrels

In any team, there are two or three people without whom nothing ships. The ones who take a vague topic, break it down, get others on board, and push it to production.

Keith Rabois put a name on this while observing PayPal: out of 254 people, 12 to 17 carried projects end to end. He calls them barrels. Everyone else is ammunition: the people who execute.

The ratio is striking. It's also a heuristic drawn from one specific company at one specific time. A 2000s fintech, a B2B SaaS platform, and an e-commerce scale-up don't have the same dynamics. But the intuition holds: in most organizations, a small number of people carry the bulk of the ability to ship.

And "carrying" doesn't look the same everywhere. The Staff Engineer who secures platform architecture carries. The EM who unblocks their team every week carries. The PM who makes priority calls and protects product focus carries, without writing a line of code. The SRE whose reliability lets everyone else build with confidence carries too. Very different profiles, same function: turning an initiative into a result.

An organization's real capacity is the number of these people. Not total headcount.

More people, less speed

When things slow down, the reflex is almost always the same: hire. Look at the roadmap, count the features, divide by estimated capacity per developer, conclude you need fifteen more people. Brooks showed the problem back in 1975: coordination cost grows at n(n-1)/2. Teams of 5-7 consistently outperform teams of 15-20 in per-capita productivity (QSM, across thousands of projects).

Sometimes headcount really is the bottleneck. An undersized platform team, 24/7 coverage to maintain, a multiplication of business domains requiring new expertise. In those cases, hiring is the right call.

But when the problem is "we're not moving fast enough on existing work," it's rarely a staffing problem. Ten more developers with nobody to frame the project, break it down, unblock it when things get stuck: ten people waiting or heading in different directions. The bottleneck is the number of people able to carry a topic end to end.

You can't hire into a broken system

On another engagement, I faced strong pressure to hire into a struggling team. My stakeholder couldn't understand why I was pushing back. The team was struggling, so it needed more people. To him, it was obvious.

I saw the outcome of that logic in a different context: external hires added to a dysfunctional team. They didn't push back, didn't bring the fresh perspective everyone hoped for. Within weeks, they'd adopted the same workarounds as the rest of the team, the same shortcuts in review, the same topics everyone avoids in standup. The resources were there, the goodwill too. But when the system has structural flaws, new hires don't fix them. They absorb them.

Will Larson calls this organizational debt. You don't hire into a broken system expecting the newcomers to fix it despite themselves.

Find the bottleneck, not the headcount gap

Goldratt laid it out in The Goal: a system's throughput is limited by a single bottleneck at a time. Optimizing anything else is waste. In The Phoenix Project, Brent is the one everything flows through, the one without whom nothing moves. Redistributing his load is the only lever. Hiring next to him does nothing.

In the team I watched shrink by half, that's what happened naturally. Fewer people, so fewer projects in parallel. Those who remained finally had the bandwidth to run their topics end to end, without being interrupted every hour to coordinate.

Skelton and Pais frame the same idea differently in Team Topologies: the real constraint is cognitive load, not headcount. When a team is overloaded, you need to reduce the surface area, the scope per person, the number of domains to keep in mind. Not add more heads.

And often, the bottleneck isn't even in engineering. It's in product decisions. Fuzzy priorities, calls that don't get made, business dependencies that nobody resolves. You can have all the technical barrels you want: if nobody on the product side holds the vision and protects focus, the team builds fast in directions that don't converge.

Growing barrels

Barrels don't stand out by their technical level. They stand out by how they react to ambiguity.

On a recent engagement, I needed barrels in a team that didn't have enough. Rather than hiring directly, I gave a leadership role to about ten people, in rotation. Same conditions, same scope, same expectations.

Within weeks, the difference was clear. Some grabbed the role: they broke down problems on their own, asked questions about the why not just the how. They felt accountable for outcomes beyond their own scope. Others still needed guidance, and that's fine. Not a judgment call, just a snapshot of readiness at a given point.

Where some waited for instructions or escalated, those few started moving.

It takes time. It's less dramatic than a senior hire showing up with an impressive resume. But people you grow internally know the context, the product, the debt. They don't need three months of onboarding. And above all, they have the team's trust. You can't mandate that.

AI doesn't make barrels

All of this was observed and theorized before every team had access to AI. AI doesn't change the equation. It makes it worse.

Todd Gagne offers an analogy that clarifies things. When electricity arrived in factories in the 19th century, the first industrialists simply replaced the steam engine with an electric motor while keeping the same production layout. The gains were marginal. It took a complete rethinking of factory organization for electricity to deliver on its promise.

AI is the same story. Deploying Copilot or Cursor on a team that lacks barrels is putting an electric motor in a steam-age factory. AI generates code, tests, documentation. But it doesn't know what to build, it doesn't know how to prioritize, and it doesn't push anything to production.

Using Rabois's heuristic: if 12 barrels drove 254 people at PayPal, AI lets those 254 produce ten times more code. But if the barrels are still 12, the bottleneck hasn't moved. It's gotten worse: there's now ten times more output to sort, validate, and carry to production.

A team without barrels armed with AI produces more code that nobody ships. The result is noise, not throughput.

Barrels don't stand out by their technical level. They stand out by their ability to turn uncertainty into execution.

When an organization slows down, the first question isn't "How many people are we missing?" The first question is "Who actually turns vague topics into concrete results?"

As long as those people remain the bottleneck, hiring more doesn't change the trajectory.

Sources

1. Keith Rabois, How to Operate — Stanford/YC, 2014. The barrels vs ammunition concept.
2. Fred Brooks, The Mythical Man-Month, 1975. Coordination cost at n(n-1)/2.
3. Will Larson, Sizing Engineering Teams — and An Elegant Puzzle, 2019. Organizational debt and team sizing.
4. Eliyahu Goldratt, The Goal, 1984. Theory of Constraints.
5. Gene Kim et al., The Phoenix Project, 2013. Brent as the human bottleneck.
6. Matthew Skelton & Manuel Pais, Team Topologies, 2019. Cognitive load as the real constraint.
7. Todd Gagne, The Barrels Paradox, 2025. The electricity/AI analogy and why human judgment becomes the real bottleneck.

Further reading

• Barrels and Ammunition — Ravi Parikh. How to identify barrels in an org.
• Brooks' Law Revisited — QSM Associates, 2017. Empirical data on productivity by team size.
• Identifying and Removing Bottlenecks — Will Larson. Applying the Theory of Constraints to engineering teams.
• Charity Majors, charity.wtf — On when hiring makes sense (and when it doesn't).
• Kent Beck, Tidy First? — Efficiency vs throughput, and why fixing architecture comes before headcount.