Tech Truth: Agile Evolution & the Future of SW Engineering • Martin Fowler & Kent Beck • GOTO 2025
Martin Fowler and Kent Beck, two authors of the Agile Manifesto, reunite for an unscripted conversation about their 30-year friendship and the evolution of software engineering. They delve into their practical, daily use of AI (the "Genie"), reflect on the legacy of Extreme Programming and the Agile Manifesto, and offer timeless advice to the next generation of developers.
The Role of AI: “The Genie” in the Workflow
Kent Beck describes his recent, intensive work with AI, which he affectionately calls “the genie.” He sees it as a “slot machine” that provides variable reinforcement—sometimes delivering a wonderful outcome, and other times something completely useless. This dynamic has allowed him to tackle ambitious personal projects, such as reimplementing Smalltalk’s highly-optimized BitBlt function, a task he’d previously struggled with.
The key benefit for Beck is the ability to exercise higher-level programming skills—setting a vision, defining milestones, and optimizing feedback loops—with greater leverage. However, he cautions that this doesn’t eliminate the need for diligence. The developer is still responsible for the outcome and must be wary of the AI’s tendency to make “horrifically bad stuff.”
“It always gets me the way it confidently says yes, all the tests pass and I run the tests myself and several of them fail… It wouldn’t last a day before I’m calling HR saying this person’s lying to me.” - Martin Fowler
Martin Fowler, while more of a “spectator” at the moment, echoes this sentiment, drawing on the experiences of his colleagues. He emphasizes that you cannot blindly trust the AI’s output. He shares an anecdote where an LLM, given the same spec twice, generated two versions of an API with completely different and incompatible validation logic that wasn’t even requested.
Fowler advises treating the AI’s output as if it were written by an “overconfident, overenthusiastic, obsequious and actually kind of vindictively malicious junior programmer who’s determined to screw your life up in some really subtle way.” A practical tip he offers is to ask the LLM the same question multiple times with slight variations and compare the results to check for consistency and reveal underlying assumptions.
Both agree that the need to understand the generated code is not going away. The unreliability of the components requires developers to apply classic computer science principles: building reliable systems from unreliable parts through double-checking and verification.
Revisiting Agile at Scale and its Legacy
When asked about scaled agile frameworks, particularly SAFe, Fowler is unequivocal in his critique, stating it belongs in the “don’t touch this with a barge pole” category. He argues that successfully scaling agile principles is highly specific to an organization’s culture and context, making generalized frameworks problematic. Instead of adopting a rigid framework, he advises focusing on two fundamental things:
- Improve Communication: The most critical path to optimize is the one between development teams and their users or customers. Shorten this path and remove filters to ensure you are building what users truly need to succeed.
- Reduce Queues: Analyze the flow of work and identify bottlenecks where work gets stuck (e.g., infrequent integrations). Systematically work to halve the time for these queues, iteratively moving towards a more continuous flow.
Reflecting on the almost 25-year-old Agile Manifesto, both Fowler and Beck express a sense of resignation that many of the same battles are still being fought. However, they are not planning a “class reunion” or a new manifesto. They firmly believe that torch belongs to the next generation. Beck notes, “We’re not going to be the ones who come up with the brilliant new idea because we’re too steeped in the old stuff.” They made a conscious decision shortly after its creation to “let it go” and allow the community to carry it forward, for better or worse.
The Future of the Craft and Advice for Newcomers
On the future of software engineering, Kent Beck is “optimistic that we’re not going to learn our lesson,” meaning he’ll likely be employed teaching the same core principles for another 20 years. Martin Fowler is slightly more hopeful, seeing a “forest” of practitioners who have genuinely advanced the craft, even if progress has been slower than he’d like. The core of their philosophy, rooted in Extreme Programming, is that the future is unpredictable, and the goal is to adopt a posture that can thrive on that unpredictability.
Their closing advice for a junior developer was a highlight:
- Kent Beck’s Advice: The most crucial time for learning is in the “gaps between features.” Resist the pressure to immediately start the next ticket. Instead, use that time and the AI as an “endlessly patient tutor.” Ask it to show you another way to implement something, to explain a language feature, to suggest refactorings, or to find missing tests. This “habit of learning is what separates people who really master programming versus people who just do programming.”
- Martin Fowler’s Advice: While talking to the computer is a necessary skill, it’s often the easiest part of the job. The truly vital skill is talking to the people who will benefit from the software. Understanding the domain, the users, and their context is what separates good programmers from great ones. The most important part of software development is communication between people, a fact that AI does not change.