The Pragmatic Engineer
The Pragmatic Engineer

How AI will change software engineering – with Martin Fowler

Brought to You By: •⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. AI-accelerated development isn’t just about shipping faster: it’s about measuring whether, what you ship, actually delivers value. This is where modern experimentation with Statsig comes in. Check i

Featured Speakers

Martin Fowler Guest

Topics Discussed

Episode Summary

Executive Summary: Martin Fowler argues AI is software’s biggest shift of his career, comparable to the move from assembly to high-level languages, but the deeper change is from deterministic to non-deterministic systems. He says AI is already useful for prototyping, exploration, legacy-code understanding, and domain learning, but warns against vibe coding, blind trust, and skipping the learning loop. He sees small-slice, human-in-the-loop, test-heavy workflows as the safest path forward.

Main Topics: AI as the biggest software shift in decades: Fowler compares AI’s impact to the historical jump from assembly to high-level languages, emphasizing that the real disruption is non-determinism rather than just a higher abstraction layer. The limits of vibe coding: He defines vibe coding as producing code without really inspecting it and argues it is fine for throwaways and exploration but harmful for long-term, maintainable software because it removes the learning loop. New AI-enabled workflows: Fowler highlights productive uses of LLMs for rapid prototyping, understanding unfamiliar APIs and domains, and analyzing legacy systems via semantic graphs and RAG-style retrieval. Refactoring becomes more important, not less: Because AI can generate lots of code quickly, Fowler expects refactoring to matter even more as teams clean up questionable but working code in small, behavior-preserving steps. Spec-driven development and domain language: He sees promise in tighter, more rigorous specifications and custom vocabularies that help humans and LLMs communicate, linking this to domain-driven design and DSLs. Testing, trust, and human review: Fowler stresses that LLMs can lie or be sloppy, so tests, careful review, and short feedback loops remain essential. AI should assist deterministic workflows rather than replace them. Agile, enterprise complexity, and organizational change: He reflects on Agile’s origins and says its core values still matter, but enterprises remain shaped by legacy systems, regulation, and risk tolerance, which also affects AI adoption.

Key Arguments: AI is the largest technology change Fowler has seen in his career, bigger than prior shifts in tooling and language. The main difference between traditional software and AI-assisted development is not just abstraction; it is deterministic versus non-deterministic behavior. Vibe coding is acceptable for prototypes and disposable tools, but not for software that needs to evolve or be maintained. Skipping inspection of AI-generated code destroys the learning loop, which is how developers build intuition and long-term skill. LLMs are especially useful for understanding legacy systems by mapping code semantics into graph structures and querying them. Refactoring will become more important because AI will produce more code, and teams will need to reshape it safely over time. The best AI workflows are thin slices with human review, strong tests, and feedback loops rather than large upfront specs. LLMs can help people explore unfamiliar domains or APIs, but they must be treated as unreliable collaborators. Enterprise adoption of AI varies widely inside the same organization; big companies are not monolithic in risk appetite. Good engineering still depends on communication, collaboration, and domain understanding, not just coding speed.

Data Points: Years since Fowler started in software: 40-ish years - He says he began in the late 1970s / early 1980s. Years at ThoughtWorks: 25 years - He says he joined ThoughtWorks around 25 years ago. ThoughtWorks size: 10,000 - He says ThoughtWorks has grown to around 10,000 people. Radar cadence: every 6 months - The ThoughtWorks Technology Radar is produced on a semiannual cycle. Radar advisory meetings: 2 or 3 times a year - The original technology advisory board met a few times yearly. Project team size mentioned: about 100 people - He describes a ThoughtWorks client project that was large and likely to fail. Refactoring book original publication: 1999 - He explains why he wrote the first edition of Refactoring in 1999. Refactoring second edition: 2019 - He refreshed the book with JavaScript examples and updated content. Agile Manifesto signatories: 17 people - He notes he was one of the 17 people involved in creating the manifesto. Enterprise job losses mentioned: quarter million to half a million - He cites industry layoffs as part of the broader downturn. Banking organization planning horizon: 3 years - He recounts a large bank doing three years of planning before implementation. Cursor token usage example: 10% of monthly allocation - James Lewis used this amount just to rename a class in a small program. Linear quality meeting output: 17 improvements in 30 minutes - Used as an example of engineering craftsmanship and frequent quality rituals. Prototype count: 20 prototypes - He cites an Anthropic example of rapidly prototyping a feature in two days. Book length example: 1,200 pages - He mentions The Power Broker as a massive but brilliant read.

Pivotal Quotes: "The biggest part of it is the shift from determinism to non-determinism." — Martin Fowler: He explains why AI is fundamentally different from prior software-development shifts. "When you're using Vibe coding, you're actually removing a very important part of something, which is the learning loop." — Martin Fowler: He warns that passively accepting AI output prevents real understanding and skill growth. "Treat every slice as a PR from a rather dodgy collaborator who's very productive in the lines of code sense of productivity." — Martin Fowler: He describes how developers should review AI-generated code.

Implications: Teams should adopt AI cautiously: use it for exploration, legacy understanding, and faster iterations, but keep tests, refactoring, and human review central. The winners will be engineers who combine craft, domain language, and disciplined feedback loops.

🔓 Sign Up for Unlimited Episode Search

About The Pragmatic Engineer

View all episodes from The Pragmatic Engineer