Why did Martin Fowler invite 60 engineers to a ski resort?

Ivett Ördög · article · 2026-07-05 source ↗ Reader 🖥️

Agentic Engineering AI Labor Disruption Citizen Developer Code Was Never the Bottleneck Code Quality Coding Agents Dark Factory (Fully Automated Software Pipeline)Legacy & Organizational Forgetting Near-Zero-Cost Code Non-Engineers Building Spec-Driven Development Test-Driven Development

The turn to AI-built software has reopened rather than resolved the foundational questions of the craft — should humans still read code, how do we know it works, does code quality still matter, and how do we manage newly-empowered citizen developers — and the author's connective throughline is an optimistic one: AI democratizes building while the disciplines that make code good for humans remain exactly the ones that make it good for AI.

mixed · mixed — A first-person reflection on a ThoughtWorks 'Future of Software Engineering' retreat, run under the Chatham House Rule; it reports the debates (narrative/expository) while arguing the author's own firm positions (argumentative), and its questions are practical questions of how to build software mixed with conceptual questions about what a 'developer' and 'good code' now are.

Structure

Part	Role
Retreat frame: a nod to a ski-resort gathering a quarter century ago	Sets the stakes by echoing a prior industry-defining retreat, but resets expectations — this time the group left with questions, not a manifesto — and invokes the Chatham House Rule to justify sharing ideas without names
Should we still look at code? (dark factories; compilers vs engineers)	Frames the largest divide at the retreat — whether systems can be written and maintained entirely by AI with no human reading the code — and reduces it to whether agents behave like compilers (regenerate from scratch) or engineers (maintain and mould a codebase over time)
Does this software work? (testing and specs)	Argues that AI has made bug-free software far harder while making review infeasible, so testing matters more than ever; stakes out the author's position that specifications should embed examples that double as automated tests
Does code quality still matter? (good for AI = good for humans)	Argues the author's core conviction: code good for AI agents and code good for humans are the same thing, backed by two reasons (training distribution and short attention span) and the Habit Hooks experience
How to manage the risk of Citizen Developers?	Reframes reduced engineer hiring as democratization rather than declining demand, celebrates non-experts being able to build tools, then names the countervailing risks (security and complacency) as a genuinely unresolved tension
Closing: exciting times, building becomes a commodity	Reframes the whole set of questions optimistically — freed from CRUD toil to focus on hard problems and to define what a future of commoditized system-building looks like

Key terms

dark factory Dark Factory (Fully Automated Software Pipeline)
A fully-automated software operation, by analogy to a lights-off factory: systems written and maintained entirely by AI with no human ever reading the code
Citizen Developers Citizen Developer
Non-professional people whom agentic tools now empower to build their own software, lowering the bar for who counts as a developer
agents as compilers vs agents as engineers
The framing that adjudicates the dark-factory debate: whether an agent regenerates code from scratch whenever needed (compiler) or maintains an existing codebase and moulds it over time (engineer)
complacency
Accepting incorrect AI results as truth — a risk of empowered non-experts that the author rates as potentially as damaging as security failures
specification with examples that double as tests
The author's prescribed practice: a spec should contain concrete examples that also serve directly as automated tests, so the spec and the test suite are one artifact

Propositions

explicitMost participants agreed that improving the agent's capabilities is higher leverage than directly improving the system it builds.conf: medium
explicitWhether software can viably be built 100% by AI depends heavily on context: it is genuinely viable for transactional backend systems and works particularly well for rewriting COBOL and similar old languages to modern systems.conf: high
explicitdevelopedThe dark-factory debate reduces to whether agents are more like compilers (regenerating code from scratch when needed) or more like engineers (maintaining and moulding an existing codebase over time).conf: high
extends ←Software Design in the Agentic Age: Placing Your Bets · p6 — Directly parallels the 'compiler vs. engineer' framing of the dark-factory debate with a more granular specs-vs-code breakdown (patch code from specs vs. discard-and-regenerate).
explicitThe last year of AI code generation has made producing bug-free software an order of magnitude harder.conf: medium
explicitcorroboratedBecause AI agents produce code at a rate impossible to review and human review is inadequate at catching bugs, testing is more important than ever.conf: high
supports ←Fragments: July 21 · p1 — The Thoughtworks report's 'verification is the bottleneck' headline finding formalizes what retreat participants had already converged on: AI generates code faster than humans can review it, so testing/verification capacity is now the binding constraint.
explicitA specification should include concrete examples that do double duty as automated tests.conf: high
explicitCode that is good for AI agents and code that is good for humans are the same thing.conf: high
explicitcorroboratedAIs understand human-readable code best because they are trained on it.conf: medium
supports ←Software Design in the Agentic Age: Placing Your Bets · p11 — Same claim independently reached at the same retreat — that LLMs understand and are best served by human-readable language — applied here to naming/Ubiquitous Language rather than code syntax.
explicitAIs have a short attention span, so any strategy that helps short-attention-span humans also benefits AI agents.conf: medium
explicitKeeping code maintainable lets the agent make more independent progress, reducing the need for direct human involvement — paradoxically pushing toward the dark-factory outcome.conf: high
explicitThe recent reduction in software-engineer hiring reflects agentic tools dramatically lowering the bar to be considered a developer, not a decline in demand for software.conf: medium
explicitBecoming a developer has become easier than ever yet also riskier than ever — security plus complacency (accepting incorrect results as truth) — and how to manage that tension is a genuinely open question.conf: high
explicitThe future of software is one in which building systems becomes a commodity, freeing engineers from CRUD toil to focus on hard problems.conf: medium

Arguments

Code that is good for AI agents and code that is good for humans are the same thing. strength: medium

Explicit premises:

AIs are trained on human-readable code, so human-readable code is what they understand best.
AIs have a short attention span, so any strategy that helps short-attention-span humans also helps AI agents.
In the author's Habit Hooks experience, keeping code human-maintainable let the agent make more independent progress.

Implicit premises:

'Good for humans' is best operationalized as readability and maintainability.
What a model handles best is determined by the distribution of code it was trained on.
The relevant respects in which AI and human cognition differ (attention span, comprehension) point the same direction for code design.

Inferences:

Therefore optimizing code for human maintainability simultaneously optimizes it for AI agents, so quality practices do not need to bifurcate.

The reduction in software-engineer hiring should be read optimistically as democratization, not pessimistically as declining demand. strength: low

Explicit premises:

In the mid-2010s Robert C. Martin estimated the number of developers was doubling roughly every 5 years, which extrapolated absurdly (everyone a developer by 2050).
Agentic tools have dramatically lowered the bar for someone to be considered a software developer.
People can now build simple useful tools themselves instead of waiting for professional engineers.

Implicit premises:

Overall demand for software is not shrinking, only the mix of who builds it.
'Developer' is being redefined to include far more people.

Inferences:

Therefore fewer professional-engineer hires reflects a redistribution of who builds software rather than the profession becoming less needed.

Testing is more important than ever in the agentic era. strength: high

Explicit premises:

AI agents produce code at a rate that is impossible to review.
Human review is woefully inadequate at catching bugs.
The industry was never good at producing bug-free software, and the last year made it an order of magnitude worse.

Implicit premises:

Automated tests can catch classes of defects that human review cannot keep up with or reliably detect.

Inferences:

Since the traditional safeguard (human review) cannot scale to AI output volume or reliably catch bugs, the burden must shift to automated testing.

Narratives

The retreat is staged as a nod to a ski-resort gathering a quarter of a century ago that produced a famous manifesto; this time, though, the group deliberately left with interesting questions rather than another manifesto, and proceedings ran under the Chatham House Rule so ideas could be shared without names.
→ Frames the piece's significance and resets expectations — the point is unsettled questions, not a declaration — and licenses the author to report positions anonymously.
Habit Hooks, a tool the author built to keep code human-maintainable, ironically nudged them toward the dark-factory camp: because the agent keeps the code maintainable, it makes more progress independently and needs far less of the author's direct involvement.
→ Personal evidence that good-for-humans practices are precisely what let agents operate more autonomously — bridging the code-quality argument and the dark-factory question.
The author ended up writing their own video-editing tool and their own teleprompter software because the commercial options kept crashing to the point of being unusable, and notes GitHub currently struggles to claim even one nine of availability.
→ Illustrates the deteriorating reliability of shipped software that motivates the 'does this software work?' section.
Several participants told stories of colleagues in finance and customer service who accidentally exposed sensitive data or made poor decisions on the back of AI results they trusted too readily.
→ Concrete, non-theoretical evidence for the citizen-developer risks (security and complacency) that ground the section's open question.

Questions addressed

⭕ Should software be built in 'dark factories' — written and maintained entirely by AI with no human ever reading the code?
No consensus; this was the largest divide. The author's synthesis is that viability depends heavily on context — genuinely viable for transactional backends and COBOL rewrites — and the crux is whether agents behave like compilers or like engineers.
✅ What kinds of tests should we write, and can a detailed enough specification substitute for tests entirely?
The author's firm position: the specification should include examples that do double duty as automated tests, so a spec does not replace tests but carries them.
✅ Does code quality still matter, and is 'code that is easy to change' the same for humans and AIs?
Yes and yes — the author argues code good for AI agents and code good for humans are the same thing, so quality still matters.
⭕ How do we manage the risk of newly-empowered citizen developers?
The author welcomes the democratization but names security and complacency as serious risks and explicitly calls how to manage the tension a genuinely open question.

Gaps

incompleteThe claim that AI-built systems are 'genuinely viable' for transactional backends and COBOL rewrites is asserted from others' reported experience without stating the criteria that mark a domain as suitable for full automation versus one that needs a human-maintained, legible codebase.
Read next: Look for case studies and taxonomies of where 100%-AI-maintained systems succeed or fail by domain, coupling, and change-rate.
illogicalThe argument that reduced engineer hiring reflects democratization (optimistic read) rather than declining demand (pessimistic read) rests on Robert C. Martin's developer-doubling extrapolation, which is rhetorical and does not actually adjudicate between the two readings — the same hiring data is consistent with both.
Read next: Read labor-market analyses that separate 'demand for software' from 'demand for professional engineers' with evidence rather than extrapolation.
incompleteThe citizen-developer risks (security exposure and complacency) are vividly named but left entirely without proposed mitigation — the author declares the tension 'a genuinely open question' and offers no governance, guardrail, or review mechanism.
Read next: Look for governance patterns for non-expert AI builders: access controls, human-in-the-loop checks, and complacency countermeasures.
uninformedThe 'AIs have a short attention span' premise carries much of the weight of the good-for-AI-equals-good-for-humans argument but is asserted as intuition rather than substantiated, and no case is examined where AI-usable code might diverge from human-readable code.
Read next: Seek empirical work on how context length, code structure, and readability affect agent task success, and on whether agent-optimal code ever differs from human-optimal code.
closed bySoftware Design in the Agentic Age: Placing Your Bets — Explicitly examines and rejects the case where AI-usable and human-usable code/language might diverge: the retreat considered building non-human-readable agent-only languages but rejected the idea because LLMs are trained overwhelmingly on human language and there is insufficient training data for hypothetical machine-only languages, so human-legible naming/Ubiquitous Language remains functionally necessary rather than merely a human-comfort nicety.

Why did Martin Fowler invite 60 engineers to a ski resort?

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents