"Craft is outdated."
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)
Written by
Stay in the loop
Get new articles delivered directly to your inbox. No spam, unsubscribe anytime.
No comments yet. Be the first to comment!