Martin Fowler

The Pragmatic Engineer

How AI will change software engineering – with Martin Fowler

0:00

-1:48:53

How AI will change software engineering – with Martin Fowler

Martin Fowler breaks down how AI is transforming software architecture and development, from refactoring and deterministic techniques to the timeless principles that still anchor great engineering.

Gergely Orosz

Nov 19, 2025

Stream the latest episode

Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.

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 it out.

•⁠ Linear ⁠ — ⁠ The system for modern product development. I had a jaw-dropping experience when I dropped in for the weekly “Quality Wednesdays” meeting at Linear. Every week, every dev fixes at least one quality isse, large or small. Even if it’s one pixel misalignment, like this one. I’ve yet to see a team obsess this much about quality. Read more about how Linear does Quality Wednesdays – it’s fascinating!

—

In this episode

Martin Fowler is one of the most influential people within software architecture, and the broader tech industry. He is the Chief Scientist at Thoughtworks and the author of Refactoring and Patterns of Enterprise Application Architecture, and several other books. He has spent decades shaping how engineers think about design, architecture, and process, and regularly publishes on his blog, MartinFowler.com.

In this episode, we discuss how AI is changing software development: the shift from deterministic to non-deterministic coding; where generative models help with legacy code; and the narrow but useful cases for vibe coding. Martin explains why LLM output must be tested rigorously, why refactoring is more important than ever, and how combining AI tools with deterministic techniques may be what engineering teams need.

We also revisit the origins of the Agile Manifesto and talk about why, despite rapid changes in tooling and workflows, the skills that make a great engineer remain largely unchanged.

Interesting quotes from the episode

On what non-determinism introduced by LLMs will mean for software engineering:

Gergely: “Is this the first time we’re seeing a tool that is so wide to certain software engineering that is non-deterministic?”
Martin: “It’s a whole new way of thinking. It’s got some interesting parallels to other forms of engineering.
In other forms of engineering, you think in terms of tolerances. My wife’s a structural engineer. She always thinks in terms of what are the tolerances, how much extra stuff do I have to do beyond what the math tells me because I need it for tolerances. Because I mostly know what the properties of wood or concrete or steel are, but I’ve got to go for the worst case.
We need probably some of that kind of thinking ourselves.
What are the tolerances of the non-determinism that we have to deal with? We need to realize that we can’t skate too close to the edge because otherwise we’re going to have some bridges collapsing. And I suspect we’re going to do that, particularly on the security side.
We’re going to have some noticeable crashes. I fear because people have got skated way too close to the edge in terms of the non-determinism of the tools they’re using.

On how many big companies are “complicated messes,” because of humans.

Martin: “I remember chatting with somebody who had joined an established bank. They joined from a startup and one of their jobs was to modernize the bank.
Their comment was: ‘now that I’ve been here three years, I think I can understand the problem. I’ve got some idea of what I can do, what can be done. But it just takes you that long to just really understand where you are in this new landscape because it’s big and it’s been around a long time.’
Companies are complicated — and often not logical because they are built by humans, not by computers. And there’s all sorts of history in there because all sorts of things happened because so-and-so met so-and-so and had it around with so-and-so, and all of these things kind of percolate over time. And this vendor came in here, and that was popular over here, and then the person who liked this vendor got moved to a different part of the organization. Somebody else came in who wanted a different vendor.
And all of this stuff builds up over time to a complicated mess. And any big company is going to have that kind of complicated mess. It’s very hard to not get that situation.”