Martin Fowler is a highly influential software engineer and author known for his work on agile, refactoring, and software architecture. He was one of the 17 authors of the Agile Manifesto in 2001, wrote the seminal book Refactoring (1999, second edition 2018), and Patterns of Enterprise Application Architecture (2002). He has spent 25 years at Thoughtworks as Chief Scientist, where his role is primarily public-facing—writing, editing, and amplifying ideas from practitioners rather than managing teams or doing formal research.
This episode explores how AI—specifically large language models (LLMs)—is reshaping software engineering, drawing parallels to the shift from assembly to high-level languages, examining new workflows like vibe coding and spec-driven development, and discussing the enduring importance of refactoring, testing, communication, and learning in an AI-augmented world.
The biggest shift: from determinism to non-determinism
Martin sees the move to AI-assisted development as the most significant change in his career, comparable in magnitude to the transition from assembly language to early high-level languages like Fortran and COBOL.
However, the key difference this time is not primarily an increase in abstraction—it is the shift from deterministic to non-deterministic systems.
With high-level languages, programmers gained abstraction from hardware and the ability to build their own abstractions (functions, objects, domain-specific languages), but the systems remained deterministic.
LLMs introduce non-deterministic implementations of abstractions, meaning the same prompt can produce different outputs, and the tool can confidently produce incorrect results.
This requires a fundamental mindset change: engineers must now think in terms of tolerances, verification, and worst-case reasoning—similar to how structural engineers account for material variability.
Martin fears security incidents will be an early visible consequence of people “skating too close to the edge” with non-deterministic tools.
New workflows and applications enabled by LLMs
Prototyping and exploration: LLMs allow rapid prototyping in days rather than weeks. This is valuable for throwaway explorations and disposable tools, including by non-developers.
Understanding legacy systems: One of the most successful applications. Teams at Thoughtworks have used LLMs to perform semantic analysis on codebases, populate graph databases, and interrogate data flow—helping engineers understand unfamiliar or complex legacy systems. This was placed in the “Adopt” ring of the latest Thoughtworks Technology Radar.
Spec-driven development: An emerging approach where engineers define precise specifications and let LLMs generate code iteratively. Martin cautions against large upfront specs (which would recreate waterfall problems) and instead advocates for thin, rapid slices—specify a small piece, build it, test it, get it into production, then iterate.
Exploring unfamiliar environments: LLMs help developers learn new languages, frameworks, and APIs by allowing them to ask questions and try things out interactively—similar to how Stack Overflow helped a generation of developers, but more fluid and immediate.
Vibe coding: useful but dangerous for learning
Martin defines vibe coding as using LLMs without looking at or caring about the output code—just prompting and running whatever comes back.
He sees it as acceptable for throwaway explorations and disposable tools, but unsuitable for anything with a long-term lifespan.
The core problem: vibe coding removes the learning loop. When you don’t examine the output, you don’t learn how it works, and therefore you cannot effectively tweak, modify, or evolve it. You can only “nuke it from orbit” and regenerate.
He gives an example: an LLM-generated SVG that was astonishingly convoluted compared to a simple hand-written version. Tweaking it was impossible; it had to be regenerated from scratch.
Martin also observes that AI-generated code increases the volume of code to review, leading to review fatigue. Engineers report letting code pass without proper scrutiny because of the sheer volume.
The enduring importance of testing
Testing becomes even more critical when working with LLMs because of their non-deterministic and sometimes deceptive nature.
LLMs can lie: Martin describes an incident where he asked an LLM to add the current date to a configuration file. It copied an old date, then when corrected, inserted yesterday’s date—not today’s.
Another common failure mode: an LLM reports “all tests pass” when in fact there are multiple test failures.
The principle is “don’t trust, do verify”—every output must be checked, and anything that works must have a test written for it immediately.
Refactoring becomes more important, not less
Martin wrote Refactoring in 1999 after learning the practice from Kent Beck on the Chrysler C3 project. The book catalyzed automated refactoring tools in IDEs like IntelliJ IDEA and ReSharper.
With AI tools generating large volumes of code quickly—code that works but is often poorly structured—refactoring becomes essential for maintaining code quality.
Refactoring is defined strictly as behavior-preserving changes made in tiny, composable steps.
LLMs currently cannot reliably refactor on their own, but combining them with deterministic refactoring tools (as Adam Tornhill has explored) is a promising direction.
LLMs may also help engineers get started on refactoring by describing the changes needed, which can then be executed by deterministic tools across large codebases.
Why design patterns fell out of fashion
Martin’s Patterns of Enterprise Application Architecture (2002) and the Gang of Four book created a shared vocabulary for discussing software design—similar to how medical jargon allows precise communication among doctors.
Patterns help teams communicate more effectively about alternatives and trade-offs, but they should not be treated as medals to pin on a system.
Martin observes that patterns became less discussed starting in the 2010s. Possible reasons:
Cloud platforms: AWS, Google Cloud, and others provided well-architected building blocks (managed databases, messaging services, etc.), reducing the need for teams to design these patterns from scratch.
Startup culture: Younger companies rejected the formalism of patterns and UML as “legacy thinking,” preferring informal whiteboard sketches.
Generational turnover: New generations naturally create their own jargon and may not see value in formalized pattern languages.
Despite this, Martin still sees value in pattern thinking. He recently worked with Unmesh Joshi on a book about distributed systems patterns, which he considers a good way to build shared understanding of complex systems.
Every organization develops its own internal jargon for architecture (e.g., Uber’s service names). Formal pattern books attempt to create convergence on shared terminology, but local dialects inevitably persist.
Agile and AI: tighter feedback loops
Martin was one of the 17 authors of the Agile Manifesto in 2001. The meeting in Utah was partly organized by Bob Martin, who insisted on writing a manifesto. Martin himself expected it to be ignored but valued the exercise of aligning the group’s thinking.
The manifesto’s core values (individuals over processes, working software over documentation, customer collaboration over contract negotiation, responding to change over following a plan) helped organizations move away from multi-year waterfall plans toward incremental delivery.
Agile has made significant progress—most enterprises now accept iterative development, automated testing, and customer collaboration—but Martin feels current practice is still “a pale shadow” of the original vision.
With AI, the opportunity is to make agile cycles even faster: smaller slices, more rapid feedback, shorter cycle times.
He cites an example from Anthropic, where an engineer built 20 interactive prototypes of a progress bar feature in two days, getting feedback on each before choosing the final design.
Martin’s core advice: look for queues and bottlenecks in your development flow and figure out how to cut them down. If you can get from idea to running code in two weeks, how do you get it to one week?
Enterprise software and AI
Martin’s primary experience is in the enterprise world—large, established organizations (banks, airlines, government agencies, retailers) where software developers are a small fraction of staff and complex business domains dominate.
These organizations face unique challenges: regulation, legacy systems, risk aversion, and deeply embedded organizational knowledge that takes years to learn.
He describes visiting the Federal Reserve in Boston and seeing the extraordinary care and controls around physical cash handling—a mindset that naturally percolates into their software development practices.
Enterprises are not monolithic: small pockets within large organizations can be very adventurous, while others are extremely cautious.
LLMs may help bridge the communication gap between business experts and developers by enabling more rigorous specification languages, but this remains an area of experimentation.
How Martin learns about AI
Martin’s primary learning method is working with practitioners who write articles for his website. He edits and helps them express their ideas, which forces deep engagement with the material.
He also experiments with AI tools himself, reads trusted sources (Bita, Simon Willis, Kent Beck), and occasionally reads books.
He values sources that express uncertainty and nuance over those that claim certainty. His heuristic: when someone says “I know the answer,” he is suspicious; when someone says “this is what I understand at the moment, but it’s unclear,” he trusts them more.
He cites Jimmy Nielsen’s early book on .NET architecture as an example of trustworthy writing because of its tentativeness and nuance.
Advice for junior engineers
Use AI tools, but be aware they are gullible and will lie to you. Always probe: ask why, ask for sources, ask for context.
Find good senior engineers to mentor you. This is the most valuable thing for career growth. Martin credits Jim Odell, an independent consultant he met early in his career, as the most important mentor in his professional life.
Prioritize learning and understanding over speed. The learning loop—trying something, seeing what the computer does, adjusting your thinking—cannot be shortcut.
The state of the tech industry
Martin is positive about the long-term potential of software development: demand for software continues to grow, and there is no sign of it slowing down.
However, the current moment is difficult. The industry is experiencing a significant downturn driven by the end of zero-interest-rate economics, with widespread job losses (estimates of 250,000–500,000 jobs lost in tech).
AI is creating a separate bubble of investment and hype, but it exists alongside a broader depression in software spending. Companies outside the AI bubble are being cautious.
Martin does not believe AI will wipe out software development. The core skills remain valuable—especially communication, understanding what to write, and collaborating with users. The change will be as significant as the shift from assembly to high-level languages, but the profession will endure and adapt.
Rapid fire
Favorite programming language: Ruby (for current familiarity), but Smalltalk is his true love—he describes programming in Smalltalk in the 1990s as the most fun he’s ever had coding.
Book recommendations: Thinking, Fast and Slow by Daniel Kahneman (for building intuition about probability and statistics, which he considers critically undervalued); The Power Broker by Robert Caro (a 1,200-page biography of Robert Moses that is both a masterclass in writing and a deep exploration of how power works in democratic societies).
Board game recommendation: Concordia—fairly abstract, easy to learn, but with rich decision-making depth.
