Software Design in the Agentic Age: Place Your Bets

Mathias Verraes · article · 2026-07-07 source ↗ Reader 🖥️

Agent Harness Changeability & Optionality Code Quality Dark Factory (Fully Automated Software Pipeline)Disposable vs. Durable Code Human-in-the-Loop Ironies of Automation Malleable Software Modularity & Coupling Software Design Fundamentals Spec-Driven Development Test-Driven Development

In the agentic age, code-level quality becomes automatable but high-level software design and rigorous (ideally executable) specifications remain decisive human-led work, so under deep uncertainty about AI's payoffs and externalities teams should bet on design rigour, executable specifications, and the ability to revert from agent generation back to human engineering.

mixed · mixed — A practitioner's reflective essay from Thoughtworks' Future of Software Engineering retreat: it surveys the debates observed there (expository) while advancing the author's own thesis and hedging recommendations (argumentative), and it is action-guiding ('place your bets', 'cover your fundamentals') yet also speculates about what is true of agentic development.

Structure

Part	Role
Framing: the retreat and the spectrum of agentic practice	Grounds the essay in observations from ~60 industry leaders and lays out the spectrum of agentic styles, from humans delegating small changes to fully automated 'dark factory' pipelines, with harness engineering broadly valued
Does code-level design still matter?	Presents the two camps (design is only for human readability vs. agents benefit from good design), catalogues camp 2's arguments, adds the ironies-of-automation side argument, and resolves it with an asymmetric-payoff decision matrix plus a concrete multi-pipeline quality setup
Does high-level design still matter?	Works backwards through the DDD essentials (evolvability/model drift, bounded contexts, ubiquitous language, domain models) and notes the rise of formal modelling, arguing each remains valuable in agentic development
Is code still ground truth?	Frames the divisive split between code-as-source-of-truth and specifications-as-source-of-truth (specification engineering), and the further debate over whether code becomes disposable and regenerable from specs
Placing your bets	Delivers the author's positions: bet on spec-driven development with executable specs, scepticism about throwaway regeneration, 'cover your fundamentals first', the dark-factory risk, and hedging against AI's externalities by building revertible systems

Key terms

harness engineering Agent Harness
Building and improving the scaffolding around agents to guarantee outcomes; broadly endorsed at the retreat regardless of agentic style
dark factory Dark Factory (Fully Automated Software Pipeline)
Borrowed from manufacturing (a lights-out facility where humans are not allowed): a fully automated software pipeline where human oversight is limited almost exclusively to improving the quality of the pipelines
model drift
The growing distance between the (mental and documented) domain models and how the code actually works, which raises cognitive load and the cost of change
Ubiquitous Language Software Design Fundamentals
An unambiguous, agreed-upon language inspired by the domain that captures all concepts, jargon, and metaphors, and is shared across code, tests, docs, UIs, APIs, and stakeholder conversations
Bounded Context
A boundary drawn around a language and model that pragmatically serves system designers; in agentic development it also bounds the context window and token cost, and lets agents warn when a request violates scope
specification engineering
The radical-shift mode in which specifications, not code, are the single source of truth; engineers iterate over specs and verify whether the application satisfies them
disposable code Disposable vs. Durable Code
Code treated as throwaway: regenerated from the latest specifications whenever an agent has trouble patching it, rather than maintained
placing your bets
The essay's organizing stance: because there is little long-term data, design choices in agentic development are decisions under deep uncertainty and should be made as hedged bets with asymmetric payoffs

Propositions

explicitCode-level design concerns (naming, duplication, dead code, mixing responsibilities, modularity, coupling, cohesion) are largely automatable by agentic pipelines.conf: high
explicitHigh-level software design remains human territory, with agents providing assistance rather than replacement.conf: high
explicitLLMs reinforce bad code because they mimic the style and patterns of the existing code when generating new code.conf: high
explicitcorroboratedAs generated code quality improves, production issues fall in relative terms but rise in absolute terms because the volume of production code grows exponentially, leaving humans the most complex issues with the most dramatic outcomes.conf: medium
supports ←AI doesn't create great developers, it amplifies them · p6 — Both observe the same quality-at-scale pattern: as AI-driven code volume grows, the absolute amount of downstream maintenance burden (duplication/churn/review time here; production issues there) grows too, even when the relative or per-unit quality picture looks acceptable or improving.
explicitReliably producing high-quality agent-generated code is achieved by splitting the work into stages (generate and verify it works, then strict deterministic static analysis, then agentic triage of each smell, then atomic refactors) under high test coverage, rather than generating high-quality code in one step.conf: high
explicitSmaller bounded contexts reduce an agent's context-window size and token cost, and a documented scope lets agents warn when a feature request violates that scope.conf: high
explicitClear, human-readable shared language remains necessary even if LLMs could work with opaque identifiers, because the language is shared across conversations, specs, diagrams, UIs, APIs, and MCPs, and because LLMs are trained on and simulate human language with insufficient training data for hypothetical new opaque languages.conf: high
explicitFeeding an agent an explicit domain model before generating an application yields better code structure and database performance than prompting requirements alone.conf: high
explicitcorroboratedFormal modelling is on the rise in agentic development because agents lower its barrier: they can create and explain formal models and then use them to verify their outputs.conf: medium
supports ←Podcast: Formal Methods for Every Engineer in an AI-Powered Future · p3 — That doc claims formal modelling is on the rise because agents lower its barrier (they can create/explain models and use them to verify outputs); this conversation is the concrete embodiment — AI generating Quint/TLA+ specs plus the glue code that verifies against implementations.
explicitSpecifications could replace code as the single source of truth, turning software engineering into specification engineering.conf: high
explicitestablishedExecutable specifications are the strongest bet because letting non-deterministic agents write code is safest when deterministic verification can predictably find faults.conf: high
supports ←Podcast: Formal Methods for Every Engineer in an AI-Powered Future · p7 — Supports 'executable specifications are the strongest bet because non-deterministic agent code is safest when deterministic verification can predictably find faults' — model-based testing is precisely deterministic replay of a spec against the implementation.
supports ←Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation · p15 — Shared thesis: let non-deterministic agents generate, but wrap them in deterministic verification (executable specs / must-check gates) that predictably finds faults.
explicitFully automated dark-factory pipelines are only safe for organisations that already have high test coverage, skilled engineers, and an established high-quality engineering culture; adopting them without these fundamentals risks high costs or major accidents.conf: high
explicitTeams should build systems that can revert from agentic code generation back to human engineering, as a hedge against AI's large externalities, rising costs, and the risk of regulation or an imploding bubble.conf: high
implicitIn agentic development the decisive human skills do not disappear but migrate upstream into modelling, language, specification, test suites, type systems, and rigour.conf: medium

Arguments

Teams should invest in code design quality even though it is uncertain whether low-level quality matters to agents. strength: high

Explicit premises:

If the quality-sceptics (camp 1) are wrong, they will have to catch up on quality and spend a lot to repair their existing code.
If the quality-advocates (camp 2) are wrong, they can easily remove their quality infrastructure at low cost.
If the sceptics are right, they will have saved money but gained no competitive advantage over the advocates.
If the advocates are right, they will save money and gain a major advantage.

Implicit premises:

The cost of investing in quality when it turns out to be unnecessary is small and reversible, while the cost of lacking quality when it turns out to matter is large and hard to retrofit.
Under deep uncertainty the rational choice is the strategy that dominates or minimizes regret across outcomes.

Inferences:

The payoff matrix is dominated by the quality-investment strategy, so betting on code design quality is rational regardless of which camp is ultimately correct.

Clear domain models, ubiquitous language, and bounded contexts remain essential in agentic development even if the machine does not strictly need them. strength: high

Explicit premises:

Language is shared across human conversation, specifications, diagrams, user interfaces, APIs, and MCPs, not only the code.
LLMs are trained on massive amounts of human language and simulate human reasoning, and there is not enough training data for hypothetical non-human-readable languages.
Specifications must be sufficiently human-readable to be verified, which requires clear language, models, and boundaries.
Feeding a domain model first, and iterating models before writing code, produced better results in the author's and participants' experience.

Implicit premises:

The value of design lies in coordinating humans and artefacts and enabling human verification, not only in machine execution.
Human verification of what agents produce remains indispensable.

Inferences:

Because design serves the whole sociotechnical system and human verification, agents do not eliminate the need for it.

Organisations should cover their quality and design fundamentals first and build systems that can revert from agentic generation to human engineering. strength: medium

Explicit premises:

Dark factories are presently hard to set up and require highly skilled engineers and an established high-quality engineering culture that many organisations lack.
AI's externalities are huge (energy and water demands, data-centre community impacts, declining cognition, AI companies burning funds, risk of a bubble imploding).
AI may become too expensive for all but the wealthiest companies, and these are valid arguments for regulating AI.
As Sam Ruby observed, rigour does not vanish when the agent writes the code; it migrates upstream into specifications, tests, type systems, and damage-based tiering of code.

Implicit premises:

The continued affordability and availability of AI is genuinely uncertain, so reversibility has option value.
Fundamentals of quality and design are the substrate that makes reversion to human engineering feasible.

Inferences:

Investing in fundamentals plus reversibility is a robust hedge across futures where AI keeps improving, becomes too costly, or is curtailed.

Narratives

The author's account of Thoughtworks' invite-only Future of Software Engineering retreat in Engelberg, Switzerland: ~60 industry leaders hosted by Martin Fowler, using an open space format of group debates mostly focused on agentic development.
→ Grounds the essay's observations and its recurring two-camp framings in a real gathering of practitioners with widely varied agentic practice.
The 'dark factory' borrowed from manufacturing: a fully automated facility where humans are not allowed, used to describe the fully automated end of the agentic-development spectrum.
→ Provides a vivid analogy for full automation and its risks, and sets up the later warning that dark factories demand pre-existing quality culture and skills.
Joe Armstrong's aphorism, quoted by the author: make it work, then make it beautiful, then (only if you really must) make it fast, since making it beautiful usually already makes it fast.
→ Anchors the staged generate-then-refactor quality pipeline in an established craft lineage and its resemblance to TDD.
The author's own experiment: feeding an agent a domain model before oneshotting an application yielded much better results than just prompting requirements, whereas without a model the agent made dubious code-structure and database-schema choices.
→ Personal evidence that explicit domain models still improve agent output, supporting the claim that high-level design retains value.

Questions addressed

✅ Does software design at the granularity of code still matter when agents lower the cost of change?
Code-level quality is automatable, and although the author is unsure it matters much in its own right apart from token cost, the asymmetric payoff makes betting on it the rational choice; agents also reinforce existing (bad) code, which strengthens the case.
✅ Does high-level design (domain models, ubiquitous language, bounded contexts, evolvability) still matter in agentic development?
Yes: evolvability and model coherence stay valuable, bounded contexts also reduce context/token cost, shared human language remains necessary, domain-model-first improves output, and formal modelling is becoming more accessible via agents.
⭕ Is code still the single source of truth, or do specifications replace it?
The community is genuinely split between code-as-truth and specifications-as-truth (specification engineering); the author bets on spec-driven development with executable specs but remains unconvinced that code can be thrown away and regenerated at will.
✅ Should organisations adopt fully automated dark-factory pipelines?
Only if they already possess high test coverage, skilled engineers, and a high-quality engineering culture; otherwise they should cover their fundamentals first, since pushing unverified code to production is riskier than doing without full automation.
✅ How should AI's risks and externalities factor into design decisions?
By building high-quality, well-modelled, test-covered systems that can revert from agentic generation to human engineering, hedging against cost, regulation, and a possible bubble.

Gaps

illogicalThe asymmetric-payoff argument for betting on quality assumes that quality-sceptics can 'easily remove their quality infrastructure at low cost' if wrong, while sceptics who guessed wrong must 'spend a lot to repair' their code. This treats the cost of removing quality as small and the cost of retrofitting it as large without examining the symmetry; the whole recommendation rests on that unexamined asymmetry, which the author only partly acknowledges when admitting he is unsure low-level quality matters apart from token cost.
Read next: Read on the economics of refactoring and of retrofitting quality, tests, and modelling into large agent-generated codebases, to test whether the cost asymmetry actually holds.
incompleteThe essay surveys the debate over disposable, regenerable code but leaves it unresolved by admission: it does not settle when the token and verification cost of regenerating code from specifications beats patching, nor whether frequent regeneration makes the system less deterministic.
Read next: Seek empirical data or benchmarks comparing regenerate-from-spec versus patch-in-place on cost, determinism, and verification of functional and non-functional requirements.
uninformedThe central bet on design quality depends on long-term maintainability and evolvability, yet the author concedes there 'isn't much data on long term evolvability with agentic development' because the space is young. The most load-bearing timescale of the argument is therefore supported largely by analogy to human software engineering rather than by evidence from agentic development itself.
Read next: Watch for longitudinal studies of agent-maintained codebases as they mature, and for evidence on whether agentic assumptions about cost-of-change transfer from the human case.
incompleteThe closing externalities argument (energy, water, data-centre impacts, cognitive decline, funding burn, bubble risk) is presented as an unquantified list, and the jump from 'externalities are large' to 'build revertible systems' does not examine whether reversion to human engineering is actually achievable once specifications, agents, and toolchains are deeply embedded and human familiarity with the code has eroded.
Read next: Read AI energy and water lifecycle analyses and work on lock-in and exit costs of agentic toolchains, plus Bainbridge-style analysis of eroded human competence after automation.

Software Design in the Agentic Age: Place Your Bets

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents