Software Design in the Agentic Age: Placing Your Bets

aardling.eu · article · 2026-07-03 Reader 🖥️

Agent Harness Agentic Engineering Changeability & Optionality Code Quality Dark Factory (Fully Automated Software Pipeline)Software Design Fundamentals Spec-Driven Development

Even though no one yet has evidence that classic code-design and domain-modeling discipline is necessary for agentic development, the author bets on maintaining it anyway — high test coverage, sound domain models and Ubiquitous Language, disciplined Bounded Contexts, and code quality — because doing so is the dominant strategy under uncertainty (cheap to unwind if unnecessary, expensive to retrofit if not) and because it preserves the option to revert an organization from agentic code generation back to human engineering if AI's economics or reliability falter.

Primarily practical: a first-person report of practitioner debate at Thoughtworks' Future of Software Engineering retreat (Engelberg), ending in the author's own actionable investment decision under uncertainty. Theoretical scaffolding is borrowed from DDD (domain model, Ubiquitous Language, Bounded Contexts) and informally from decision theory (a payoff-matrix argument for betting on quality). · Expository-then-argumentative retreat report: descriptive summary of two-camp debates (low-level code quality; code-vs-specification as source of truth) followed by the author's own persuasive case ('Placing your bets') for a specific practical stance. — This is one of several independent write-ups of the same 2026 Thoughtworks retreat already in the corpus (Fowler's fragments, Jimmy Nilsson's LinkedIn reflection, Sam Ruby's 'What Survived Contact', 'Why did Martin Fowler invite 60 engineers'). Unlike Fowler's deliberately un-synthesized fragments, this piece takes an explicit position and argues for it.

Structure

Part	Role
Summary bullets	thesis preview
The retreat's participants	context-setting: spectrum of agentic-adoption styles among ~60 invited practitioners, from small delegated changes to full 'dark factory' pipelines
Low-level code quality	lays out a two-camp debate (design principles obsolete vs. still essential) plus the author's payoff-matrix argument for betting on quality
Achieving code quality	describes a concrete four-stage agentic pipeline (generate/verify, static analysis, agent-triaged smells, atomic refactor) and likens it to TDD
High-level software design	argues DDD's four essential qualities (domain model, Ubiquitous Language, Bounded Contexts, continuous evolution) remain essential and largely human territory
Specifications or code?	presents the retreat's most divisive question — code vs. specifications as single source of truth — without resolving it
Placing your bets	author's own concluding argument, citing Sam Ruby's 'rigor migrates' framing and the dark-factory skills gap, to justify continued investment in quality/testing/modeling as a hedge and reversibility strategy

Key terms

dark factory Dark Factory (Fully Automated Software Pipeline)
A fully automated agentic development pipeline (generate, verify, deploy) where human oversight is limited almost entirely to improving the pipeline itself — borrowed from the manufacturing term for a facility with no humans allowed on the floor.
model drift
The growing distance between the mental/documented domain model and how the code actually behaves, increasing cognitive load and cost of change.
specification engineering
A hypothesized successor discipline to software engineering in which specifications, not code, are the primary artifact iterated on and verified, with code as a disposable, regenerable output.
placing your bets
The article's framing device: choosing which engineering investments (code quality, testing, domain modeling) to keep making now, under genuine uncertainty about which camp will prove right, using an asymmetric-payoff/reversibility argument rather than proof.
harness engineering Agent Harness
Engineering the surrounding pipeline/tooling around agents to guarantee outcomes reliably, independent of adoption style.

Propositions

explicitLow-level code-quality concerns (naming, duplication, dead code, modularity, coupling, cohesion) remain important in agentic development because LLMs share human-like readability limitations, because quality's payoff is long-term rather than short-project-scale, because complexity inflates both the LLM's context window and token cost, because humans must debug unfamiliar agent-written code the LLM itself can't fix, and — most consequentially — because LLMs mimic and reinforce the existing style and patterns of the codebase they generate into, entrenching rather than correcting bad code.conf: high
supportsFragments: July 6 · p11 — Same claim (LLMs imitate and amplify existing code, magnifying rather than correcting design problems) independently reported from a different write-up of the same retreat.
extendsJimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat · p2 — Supplies the concrete causal mechanisms (token cost, context-window sensitivity, human debugging needs, LLM code mimicry) that nilsson-fose-linkedin's 'fundamentals matter more than ever' claim left unstated.
explicitAs agentic code generation improves, the share of easily-solvable production issues will fall in relative terms even as the absolute volume of production code (and therefore of issues) grows exponentially — leaving humans disproportionately with the most complex, highest-consequence issues (an instance of Bainbridge's Ironies of Automation).conf: low
explicitA four-stage agentic pipeline — generate and minimally verify then atomically commit; run traditional deterministic static analysis at its strictest settings; have an agent assess the validity and worth of each flagged smell; have an agent atomically refactor and commit one smell at a time — is reported by retreat participants to work well for achieving code quality, structurally mirrors TDD ('make it work, then make it beautiful'), and depends on high test coverage to ensure refactors change only form, not behavior.conf: medium
supportsSoftware Teaming in the Age of AI with James Herr and Woody Zuill · p14 — The retreat's refactor pipeline treats test coverage purely as a verification/guardrail gate for atomic refactors, not as a TDD design tool — consistent with Zuill/Herr's reframing of tests-as-guardrails for LLM-authored code.
explicitHigh-level software design — a clear domain model expressed across code, tests, documentation, UI and stakeholder conversation; a well-defined shared Ubiquitous Language; pragmatically-scoped Bounded Contexts; and continuous evolution of all three — remains essential and largely human territory even where low-level code generation is automated. Bounded Contexts additionally help agentic development directly by capping context-window size and token cost.conf: high
supportsThe Almedra Token-Efficiency Benchmark, Updated For GLM 5.2 · p5 — Retreat consensus that scoping (Bounded Contexts) and harness engineering control token/context cost corroborates Almedra's empirical finding that harness/context-management design, not the underlying model, drives efficiency differences.
explicitFeeding an agent a domain model before one-shotting an application produced markedly better results than prompting requirements alone, in the author's own experiment (without a model, the agent made dubious code-structure and database-schema choices that worked but were harder to understand and performed worse); multiple retreat participants likewise reported iterating on domain models with an agent before allowing code generation, sometimes mixing text and diagrams (PlantUML, Mermaid) as agent input.conf: medium
explicitThe retreat's most divisive question was whether code remains the single source of truth (iterated on directly, verified by agents plus traditional methods) or whether specifications become the single source of truth, with code demoted to a disposable, possibly-regenerated artifact — a shift the author labels 'software engineering becomes specification engineering.'conf: high
extendsWhy did Martin Fowler invite 60 engineers to a ski resort? · p3 — 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).
extendsSoftware Teaming in the Age of AI with James Herr and Woody Zuill · p13 — Raises the same regeneration/determinism tension James Herr's deterministic-generator practice already answers concretely in a different setting; this document treats it as an open industry debate without engaging that existing mitigation (see gap g4).
explicitThe author is unconvinced that code can be safely discarded and regenerated at will from specifications, because regeneration carries its own cost and could increase the cost of re-verifying functional and non-functional requirements (security, performance) on every regeneration; he is also unsure whether low-level code quality matters much beyond its effect on token cost — yet he still bets on high test coverage, sound domain models/Ubiquitous Language/Bounded Contexts and code quality, primarily as a hedge that preserves the option to revert an organization from agentic generation back to human engineering if AI's economics or reliability don't hold up.conf: high
explicitcorroboratedQuoting Sam Ruby's account of the same retreat: rigor does not vanish when the agent writes the code, it migrates — upstream into specifications, downward into test suites treated as first-class artifacts, into type systems and constraints, and into tiering code by how much damage a mistake could cause.conf: high
supportsWhat Survived Contact · p1 — Independent citation of the same Sam Ruby 'rigor migrates' framing already central to what-survived-contact's own thesis; both retreat write-ups treat this as the settled cross-retreat finding.
supports ←AI Demands More Engineering Discipline, Not Less · p4 — Both independently arrive at 'rigor does not vanish when the agent writes the code, it migrates' — Majors specifies the destination as production/observability discipline rather than only upstream specs and downstream ops.
explicitDark-factory pipelines (fully automated generate-verify-deploy with human oversight limited to improving the pipeline) are currently very hard to set up and require highly skilled engineers plus an already-established high-quality engineering culture; organizations that attempt one without that foundation risk high costs or major accidents.conf: medium
implicitThe author's bet-placement logic implicitly rests on a maximin/regret-minimization argument: if 'design principles are unnecessary for agents' turns out right, quality infrastructure can be cheaply removed; if 'design still matters' turns out right and an organization skipped it, that organization faces expensive catch-up — so investing in quality dominates on downside protection, even absent long-term evolvability data.conf: medium
explicitdevelopedHuman-legible naming and Ubiquitous Language likely still matter functionally in agentic development, not merely for human comfort, because language must be shared across code, specifications, diagrams, UIs, APIs and MCPs and across human/agent conversation — and because LLMs are trained on massive amounts of human language, not on hypothetical non-human-readable agent-only languages, which lack sufficient training data to be viable.conf: high
supportsWhy did Martin Fowler invite 60 engineers to a ski resort? · p8 — 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.
extends ←Writing vs. Thinking · p11 — Both argue naming/ubiquitous language does real cognitive and design work, not just readability/comfort; this doc supplies a concrete before/after example (ProcessRequest -> ValidateEligibility/CalculatePremium/IssuePolicy/NotifyCustomer) for the general claim.

Arguments

Organizations should keep investing in code-design quality, test-coverage rigor, domain modeling and Ubiquitous Language even though it is not yet proven necessary for agentic development, because doing so is the dominant strategy under uncertainty and preserves the option to revert to human engineering. strength: medium

Explicit premises:

If low-level code-design principles turn out unnecessary for agents, quality infrastructure built anyway can be cheaply removed.
If code-design principles remain necessary but an organization ignored them, that organization faces expensive catch-up and must repair its existing code.
Dark-factory pipelines currently require highly skilled engineers and an established high-quality culture; without that foundation the risk is high cost or major accidents.
AI is new, capital-burning, and of uncertain long-term affordability, so the ability to revert from agentic generation to human engineering has real value.
Reverting to human engineering requires humanly understandable systems, which requires people who already have the relevant design experience.

Implicit premises:

The cost of building and maintaining quality infrastructure now is low relative to the cost of not having it if it turns out to matter (an unstated, load-bearing asymmetry assumption).
Unattributed, unquantified opinion from ~60 senior invited practitioners at one retreat is reasonably representative evidence.
Preserving organizational reversibility (the ability to un-commit from agentic tooling) is itself valuable, i.e., irreversible lock-in is a real risk worth hedging against.

Inferences:

Narratives

The manufacturing 'dark factory' analogy — a fully automated facility where humans are not allowed — used to describe the most automated end of the agentic-development spectrum some retreat participants already run in production.
→ Vivid illustrative analogy that anchors the far end of the human-involvement spectrum and motivates the later risk argument about skills and culture prerequisites.
Author's personal one-shot-app experiment: feeding an agent a domain model before prompting for an application yielded better code structure and database performance than skipping the model, which instead produced working-but-hard-to-understand results.
→ First-person evidentiary anecdote supporting the domain-model-first claim.
Joe Armstrong quote: 'Make it work, then make it beautiful, then if you really, really have to, make it fast... if you make it beautiful, it will already be fast.'
→ Authoritative historical quotation used to reframe the novel-seeming agentic quality pipeline as a rediscovery of classic TDD discipline rather than something new.
Sam Ruby's blog quote on rigor migrating rather than vanishing when agents write code.
→ External corroborating authority from a different attendee's independent write-up of the same event, used to strengthen the author's closing bet.

Questions addressed

✅ Does code-level design quality (naming, modularity, coupling, cohesion) still matter when agents write the code?
Provisionally yes — for LLM-shared readability limits, token/context cost, human debugging needs, and to prevent LLMs reinforcing bad patterns; the author personally bets on it despite acknowledging there is no confirming long-term data yet.
⭕ Is code or the specification the true source of truth in agentic development?
Presented as the retreat's most divisive open question; the author states a personal leaning (skeptical of full code disposal/regeneration) without claiming the debate is resolved.
✅ Does agent-friendly code/language differ fundamentally from human-friendly code/language — could a non-human-readable agent language work?
Rejected — LLMs are trained overwhelmingly on human language, and there isn't enough training data for hypothetical machine-only languages, so human-legible naming and Ubiquitous Language remain functionally necessary.
✅ How should organizations hedge against the risk that agentic development doesn't pan out economically or technically?
By deliberately maintaining human-understandable systems (test coverage, sound models, code quality) so the organization retains the option to revert to human engineering.

Gaps

incompleteThe report never quantifies how many participants held each position ('some,' 'a few,' 'many,' 'people in the second camp') or names them beyond one externally-linked Sam Ruby quote, so a reader cannot tell whether 'camp 2 offered compelling arguments' reflects a genuine majority shift or the author's own selective emphasis — the same structural problem the corpus already flags for sibling retreat reports (cf. extract-future-of-software-development#g3 on pre-filtered attendance; extract-nilsson-fose-linkedin#g4 on in-group consensus).
Read next: Seek an attributed, quantified account of the same debate, or dissenting views from practitioners outside this self-selected, AI-engaged invite list.
incompleteThe payoff-matrix argument for betting on code-quality investment never assigns probabilities, timeframes, or a magnitude to the cost of maintaining quality infrastructure — it establishes only a qualitative asymmetry (cheap to remove vs. expensive to add later) without showing that asymmetry outweighs the opportunity cost of near-term velocity foregone if camp 1 (agents don't need design principles) turns out substantially right in the near-to-medium term.
Read next: Look for a quantified real-options or cost-of-delay analysis applied to engineering-practice investment decisions under this kind of technological uncertainty.
incomplete'Rigour and engineering practices remain crucial' and the whole quality-pipeline description are reported as retreat consensus that 'seemed to feel...was working well,' with no outcome data (defect rates, cost, cycle time) — continuing the same DORA-empirics gap the corpus already flags for other retreat-adjacent reports (extract-heis-14-oystein-ulseth-pendler-lede-levere#g5; extract-fowler-fragments-july-6#g3).
Read next: Look for DORA-style or controlled empirical studies of agentic quality-pipeline outcomes at scale, rather than practitioner self-report.
uninformedThe author frames the specs-vs-code and 'throw away code and regenerate' debate as unresolved and untested, without engaging James Herr's already-reported deterministic-generator technique (have the LLM write a DSL/generator once, then produce all code thereafter deterministically from that generator) described in a separate retreat-adjacent conversation — a concrete existing answer to exactly the determinism/cost worry the author raises about full-code regeneration.
Read next: Read extract-software-teaming-age-of-ai-zuill-herr#p13 (and the corpus's deterministic-code-generators concept) and ask whether that pattern resolves, or only partially resolves, the regeneration-cost/determinism concern raised here.

Closes gaps elsewhere

Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat · g2 — Supplies the concrete causal mechanisms nilsson-fose-linkedin's claim left unstated for why DDD/XP/TDD/CD-style fundamentals matter more under agentic coding: LLM context-window and token-cost sensitivity to complexity, humans needing to debug unfamiliar agent-written code, and LLMs mimicking/reinforcing existing code patterns rather than independently improving them.
Why did Martin Fowler invite 60 engineers to a ski resort? · g4 — 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.