Martin Fowler and Kent Beck — two of the 17 signatories of the Agile Manifesto 25 years ago — reflect on how their ideas (Agile, TDD, refactoring, XP) have shaped software engineering, and how the current AI wave compares to past technological disruptions.
Both are now focused on understanding how AI is actually changing day-to-day software work, rather than writing prescriptive books.
They see AI as fundamentally different in magnitude and speed from anything before — bigger than the internet, object-oriented programming, or the microprocessor — but they draw on those past shifts to make sense of it.
What stuck from Agile, TDD, and refactoring
TDD has been the most divisive: some engineers credit it as essential preparation for verifying AI-generated code; others blame it for making their lives miserable.
Kent Beck notes that after 25 years of pushing TDD, its value is suddenly obvious: when you have a “big powerful genie,” you absolutely need tests to verify it’s doing the right thing.
Refactoring and modular design are resurfacing as critical: well-structured code turns out to be exactly what AI agents need to work effectively.
Agile/XP practices like pair programming and small teams produced great results but were socially uncomfortable for organizations — and AI is now tempting companies to revert to isolated, individual work patterns.
Kent Beck compares AI’s impact to the introduction of the microprocessor: a sudden expansion of what’s imaginable, enabling projects that were previously absurdly ambitious.
Martin Fowler notes that every major shift — OO, the internet, Agile — attracted both hype and legitimate skepticism, and the key skill is balancing curiosity with critical evaluation.
He was initially unimpressed with early AI coding tools (Copilot-style autocomplete in Emacs) and nearly dismissed AI entirely, the way he dismissed blockchain.
What changed was finding trusted voices (like Simon Willison) who gave balanced, honest assessments — acknowledging both real problems and real capabilities.
The critical skill right now: running the smallest possible experiment to validate whether a claim about AI is true for your own context — and recognizing that the answer can change week to week as models improve.
Why good practices still fail (and why AI will face the same problem)
Kent Beck argues that organizations don’t actually want “faster, cheaper, better” — internal incentives are misaligned, so even proven improvements get punished.
The Agile industrial complex (certification mills, snake oil) grew around solid core ideas, and the same is already happening with AI.
AI is an amplifier: it amplifies whatever you’re already doing.
Junior engineers who are learning quickly will learn even faster — Beck calls this “the golden age of the junior programmer.”
Experienced engineers who work effectively will become more productive.
The vulnerable group is the middle: people who entered programming primarily for financial stability and may lack deep craft commitment — a group that’s much larger now than during the dot-com era.
This middle has already been partially thinned by post-ZIRP layoffs, which is a new confluence of factors not present in the 1990s.
How the AI shift is different
The recurring fantasy of “getting rid of all programmers” (from COBOL-era business analysts to today’s “no one will write code in 6 months”) is resurfacing, amplified by AI hype.
Martin Fowler pushes back: prompting and interacting with a genie is still a form of coding — the nature of code is changing, but the need to produce and interact with it isn’t going away.
Security risks are being ignored in the rush to adopt: Fowler has encountered large companies considering giving LLMs full control over email, which he calls “mind-boggling” from a security standpoint.
The sheer speed and magnitude of AI adoption is unprecedented — there’s no argument about its importance, unlike the internet or Agile, which had to be sold to skeptics.
Engineers as managers of multiple agents
A trend toward “re-soloing” programming: engineers working individually with multiple AI agents, rather than collaborating in pairs or teams.
Kent Beck pushes back: managing six tools is not the same as managing a team of people with different perspectives and energy levels.
He worries companies will use AI as an excuse to return to isolated, controllable work patterns — abandoning the messy, social, chaotic processes that actually produced great results.
Pair programming with genies: Beck’s experience pairing with another human plus one or more AI agents has been very positive.
The slowness of current models is actually a feature: it creates space for the pair to discuss design decisions, naming, conditionals, and next steps while waiting for output.
Faster models could eliminate that valuable thinking time.
Team size question: will two-pizza teams shrink to one-pizza teams because agents don’t eat pizza? Fowler bets on two-pizza teams becoming more effective, not smaller.
Developer experience and agent experience
A key insight from the Future of Software Engineering conference: the Venn diagram of developer experience and agent experience is essentially a circle.
What’s good for agents is good for humans: well-modularized code, good tests, clear domain language.
This reinforces the value of craft practices like refactoring, TDD, and domain-driven design — they’re not obsolete, they’re more important.
Domain language as interface: one engineer (Animesh Joshi) found that developing a precise language to communicate about the domain with an agent dramatically improved efficiency — essentially applying domain-driven design principles to human-agent collaboration.
Kent Beck’s personal shift: he’s had to let go of the deep craft satisfaction of perfecting individual functions — getting “in the zone” with a messy file and refactoring it into clarity.
That level of micro-craft no longer has the leverage it once did.
He’s shifting his focus to enjoying understanding the domain and its connection to the program — a higher-level form of craft that AI can’t replace and that becomes the primary source of leverage.
