How AI will change software engineering – with Martin Fowler

The Pragmatic Engineer · video · 2025-11-19 source ↗ Reader 🖥️

mixed · mixed — A long-form interview (Gergely Orosz with Martin Fowler) that is theoretical when characterizing what AI changes about software (determinism vs. non-determinism) and practical when giving concrete guidance (how to vibe code responsibly, how to refactor, how to spec, how to run agile with AI). Narrative digressions (Fowler's career, the Agile Manifesto meeting, book-writing history) carry implicit arguments about craft and mentorship.

Structure

Key terms

• vibe coding Vibe Coding
  Strictly: not looking at the generated code at all (at most a curious glance), appropriate only for disposable, throwaway work with no long-term capability requirement.
• the learning loop
  Attributed to colleague Unmesh Joshi: the constant back-and-forth between trying something on the computer and adjusting one's own thinking based on what happens. Vibe coding skips this loop, so the resulting software can't later be tweaked, modified, or evolved — only regenerated from scratch ('nuke it from orbit and start again').
• determinism / non-determinism shift
  The change from software whose behavior is fixed by code to software whose behavior is elicited probabilistically via natural language — Fowler ranks this as a bigger shift than any abstraction-level increase (bigger than assembly -> high-level languages).
• the genie The Genie (Beck)
  Kent Beck's anthropomorphic term for the LLM collaborator (parallel to Bita Gorji's 'Dusty the donkey'): something very productive but untrustworthy, whose every output must be reviewed like a PR from a dodgy collaborator.
• expert generalist Expert Generalist
  Attributed to Unmesh Joshi: a developer whose value comes from curiosity, breadth, and depth rather than narrow specialization — traits Fowler says have 'nothing to do with AI' and remain the standout qualities of good engineers.

Propositions

• explicitThe biggest change AI brings to software engineering is the shift from deterministic to non-deterministic systems, which Fowler ranks as a bigger shift than the historical move from assembly to high-level languages, and bigger than the abstraction-level jump itself.conf: high
• explicitVibe coding (strictly defined as not looking at the generated code) is appropriate for prototyping, exploration, and disposable work — including by non-programmers — but not for anything requiring long-term capability.conf: high
  supportsBliki: Vibe Coding · p5 — Both sources state, independently, that vibe-coded software is only appropriate for disposable/throwaway use — this video restates Fowler's own bliki position in his own words.
• explicitVibe coding removes the learning loop — the iterative back-and-forth between what the computer produces and what the developer is thinking — and without that loop the developer cannot later tweak, modify, or evolve the resulting software; the only option is to regenerate it from scratch.conf: high
  extendsBliki: Vibe Coding · p11 — The bliki post says reading code produces accountability; this video supplies the mechanism (Unmesh Joshi's 'learning loop') for why skipping that reading specifically forecloses future tweakability, not just accountability.
• explicitUsing LLMs to understand existing legacy systems (via semantic analysis into a graph database you can interrogate) is a mature, high-confidence practice — ThoughtWorks' Radar put it in the 'Adopt' ring, one of only four items there.conf: high
• explicitWhether LLMs can safely modify legacy/brownfield code (as opposed to merely understanding it) remains an open question, illustrated by James Lewis burning 10% of his monthly token allocation on an LLM-driven class rename — a task that IDE refactoring tools (e.g. ReSharper) solved deterministically 20 years ago.conf: high
  extendsIs AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p10 — Bernhard's claim that legacy modernization is a real bottleneck is nuanced here: understanding legacy code with LLMs is a mature success (ThoughtWorks Radar 'Adopt' ring), but safely modifying it remains unresolved — splitting the bottleneck into a solved and an unsolved half.
• explicitSoftware will continue to be built by teams rather than individuals even if AI makes developers an order of magnitude more productive, because demand for software is far from saturated; what remains genuinely unresolved is how teams, not individuals, should operate with AI.conf: high
• explicitEvery AI-generated code slice should be treated as a pull request from a highly productive but untrustworthy collaborator, reviewed carefully before being trusted.conf: high
• explicitAs AI-generated code volume rises, the amount of reviewing required rises correspondingly, and experienced engineers (not just juniors) report struggling to stay vigorous and attentive through larger review loads — a problem neither speaker resolves beyond urging more careful review.conf: high
  supportsFrom Async Code Reviews to Co-Creation Patterns · p1 — Orosz's observation that AI inflates code volume faster than reviewers can stay vigilant corroborates, from a different angle, the claim that PR-based review's throughput/quality trade-off breaks down under volume; this video does not offer the co-creation alternative that doc proposes.
• explicitdevelopedBuilding a rigorous, shared, DSL-like vocabulary to communicate with the LLM — ideally co-built with the LLM itself — is a more promising line of attack than either unchecked vibe coding or large upfront specifications, echoing domain-driven design's 'ubiquitous language.'conf: high
  extends ←No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p9 — Fowler's video (same batch) argues spec-driven development risks the waterfall mistake unless kept thin and tight-looped; this talk goes further, arguing the term itself is now semantically diffused past usefulness, independent of how carefully any given team practices it.
• explicitSpec-driven development repeats the waterfall mistake when it tries to front-load a large, comprehensive specification disconnected from code; the valuable version keeps specs thin, with tight build-test-deploy loops on small slices.conf: high
• explicitRefactoring discipline (tiny, composable, behavior-preserving steps) will become more, not less, valuable as AI produces more code of variable quality, because refactoring is the mechanism for getting that code into a better state while keeping it working — though current LLMs cannot reliably refactor on their own.conf: high
• explicitA promising pattern is using the LLM as a starting point to drive a deterministic tool (e.g., LLM-assisted SQL generation reviewed by a human, or a mostly-deterministic migration tool with a small LLM component) rather than letting the LLM act unsupervised on the codebase directly.conf: medium
• explicitDesign-pattern and architecture vocabulary declined in mainstream discourse starting around the 2010s partly because cloud providers' well-architected managed services (e.g., DynamoDB, managed Postgres) absorbed much of the hard architectural decision-making, and partly for generational/cultural reasons (startups rejecting legacy-company conventions).conf: medium
• explicitcontestedAgile's core lever of leverage — shortening cycle time and increasing the frequency of small increments, rather than cramming more into each increment — remains the best bet in the AI era, and AI's main contribution should be making those small slices faster, not larger.conf: high
  contradictsThe 8 software engineering metrics AI broke · p1 — Fowler frames shortening cycle time as the best available lever of leverage in the AI era; the other source argues cycle time is inflated by AI without corresponding quality gains and can mask reduced human review. The tension is real but partial: Fowler's framing assumes review discipline is retained (see p7/p8 above), which is exactly what the other source finds is often not the case in practice.
• explicitA good human mentor is the best way for junior engineers to develop judgment about whether AI output is good, because juniors lack the calibration to evaluate output quality themselves; AI should be probed ('why do you give me this advice? what are your sources?') rather than trusted outright.conf: high
• explicitThe standout qualities of great engineers — curiosity, breadth and depth, and above all communication and collaboration with non-engineer stakeholders — are unchanged by AI.conf: high
• explicitThe primary cause of the current software-industry downturn and job losses is the end of zero-interest-rate financing, not AI; AI is 'almost like a separate thing going on' that is itself in a bubble whose eventual size and aftermath are unpredictable.conf: high
  supportsThe loudest warning about AI and jobs yet · p7 — Both sources resist a single-cause ('AI did it') story for current job losses, pointing instead to overlapping macroeconomic causes and the incentive to misattribute layoffs to AI.
• explicitVariation in AI risk tolerance and adoption within a single large enterprise is often greater than variation between enterprises, because enterprises are not monolithic — small adventurous pockets coexist with highly cautious ones.conf: medium

Arguments

Narratives

• Fowler's colleague Unmesh Joshi asks an LLM to produce a small SVG chart; the result 'worked' but was so convoluted that a trivial label-position tweak Fowler could have made by hand in a dozen lines became impossible without regenerating the whole thing.
  → Shows, rather than argues, why vibe coding forfeits the learning loop and caps out at throwaway use — the structure is alien to the person who would need to maintain it.
• James Lewis spends an hour and a half and 10% of his monthly token budget asking an LLM-driven coding tool (Cursor) to rename a class in a modest-sized Go/Godot program — a task IDE refactoring tools (ReSharper, IntelliJ) have solved deterministically for 20 years.
  → Demonstrates concretely that LLMs are not yet reliable for safe brownfield modification, and that some 'solved' problems (automated rename-refactor) are, ironically, worse when handed to an LLM instead of the existing deterministic tool.
• A senior architect at American Express spends three years purely on the planning phase of a system re-architecture, mostly socializing ideas with business stakeholders in a company with deep legacy and regulatory history.
  → Grounds the claim that large, old enterprises carry organizational complexity (regulation, history, business-unit jargon) that AI's current capabilities do not address — context Fowler repeatedly returns to when warning against one-size-fits-all AI advice.
• The origin of the Agile Manifesto: a contentious debate over location (Utah vs. Anguilla), Fowler's own hazy memory of the drafting, and his initial belief the manifesto itself would be 'completely useless and ignored.'
  → Implicitly argues that durable change (agile's actual adoption) came not from the document itself but from the ongoing practice and community it crystallized — a precedent Fowler draws on when speculating about whether 'AI fluency' vocabulary will similarly stick or fade.

Questions addressed

• ✅ What is the single biggest change AI brings to software engineering?
  The shift from deterministic to non-deterministic systems, bigger than any abstraction-level jump.
• ⭕ Can LLMs safely modify (not just understand) legacy/brownfield code?
  Explicitly left open; current evidence (the class-rename anecdote) is discouraging.
• ⭕ How should teams (as opposed to individual developers) operate with AI?
  Explicitly flagged as unresolved and still being figured out.
• ✅ Is spec-driven development just waterfall under a new name?
  Only if it tries to front-load a comprehensive spec; done as thin, tight-looped specs it is compatible with agile practice.
• ⭕ How does a reviewer stay vigilant as AI increases the sheer volume of code to review?
  Raised explicitly by Orosz but not answered beyond 'review everything very carefully' — Fowler offers no concrete mechanism for scaling review attention.

Gaps

• incompleteFowler explicitly names 'how do we best operate with AI in the team environment' as an open question his own organization is 'still trying to figure out' — but the entire conversation's concrete advice (vibe-coding boundaries, PR-style review of AI output, building a shared vocabulary, thin specs) is framed at the level of one developer and one LLM. No team-level operating model (shared context across team members, division of review labor, how a team maintains a common mental model of a codebase that multiple AI-assisted people are editing) is even sketched.
  Read next: Look for emerging practitioner accounts of team-scale (not individual-scale) AI coding workflows: shared harness/context conventions across a team, how code review scales when every team member is AI-accelerated, and how a team keeps a common mental model of a codebase multiple people are editing with AI assistance.
• incompleteOrosz raises, and Fowler does not resolve, the problem of reviewer fatigue and vigilance as AI multiplies the volume of code to review — the conversation's only answer ('treat it like a PR from a dodgy collaborator, review everything carefully') does not address the structural throughput problem of more code arriving faster than humans can review it carefully.
  Read next: This is a near-direct match to the corpus's own treatment of PR-review throughput breakdowns and co-creation alternatives — see the review-fatigue proposition recorded above and its relation to extract-async-code-reviews-choking-throughput.
• incompleteThe claim that design-pattern/architecture vocabulary declined in the 2010s because cloud-managed building blocks absorbed architectural decisions is offered tentatively (relayed from Grady Booch, with Fowler admitting 'I haven't had the opportunity to focus on that') and is not reconciled with the fact that distributed-systems pattern books (Unmesh Joshi's, which Fowler himself worked on) exist and are, by Fowler's own account, valuable — leaving unclear whether patterns declined in substance or just in public discourse/branding.
  Read next: Look for a more rigorous account of whether architectural decision-making genuinely migrated into managed cloud services, versus patterns persisting informally as company-specific jargon (the Uber service-naming example Fowler and Orosz discuss in the same segment).
• uninformedFowler attributes the current software-industry downturn and job losses primarily to the end of zero-interest-rate financing rather than AI, but does not engage with the counter-evidence elsewhere in the discourse that some of the layoff wave is genuine AI-driven restructuring (not merely macroeconomic or a cover story) — he states his view confidently without weighing the split causation other commentators report.
  Read next: Compare against corpus accounts that split the layoff wave into AI-washing/cover-story and genuinely AI-driven restructuring components.

Related documents

• The loudest warning about AI and jobs yet
• The 8 software engineering metrics AI broke
• From Async Code Reviews to Co-Creation Patterns
• Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard
• Trust Factory
  Agile & XP The Genie (Beck) Learning Culture & Slack Vibe Coding
• Forskning på digitalisering 2026 uke 19
  Agile & XP Learning Culture & Slack Legacy & Organizational Forgetting
• 11) AI-spesial med Vilde Opsal og Anders Sveen
  Learning Culture & Slack Software Design Fundamentals Vibe Coding
• SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more.
  Learning Culture & Slack Software Design Fundamentals Vibe Coding
• AI Is Changing Software Engineering. The Fundamentals Still Matter.
  Software Design Fundamentals Vibe Coding
• AI coding creates two kinds of debt. You're only measuring one
  Learning Culture & Slack Pull Requests & Async Code Review