On 6 July 2026, Martin Fowler published a set of fragmentary notes from Thoughtworks' second Future of Software Development Retreat, held in Europe. The value of the post is not a single conclusion — Fowler is explicit that the event forms none. It is a snapshot of where practitioner consensus has actually moved between the February retreat in Utah and this one.
This article pulls out three shifts the notes document: agentic development crossing from theory into production, the rise of "harness engineering," and the token-cost reckoning now hitting large enterprises.
From "whether" to "how"
The clearest signal in Fowler's notes is a change in tone between two gatherings of largely the same people.
Greg Herlein, quoted in the post, put it bluntly. In February the conversation was aspirational — what agentic development might look like. By July: "Everybody in the room was doing it. Shipping it. Not slides — production. The whole debate about whether this changes software engineering is over."
The argument has moved from whether AI changes software engineering to how. That is a meaningful relocation. Debates about "whether" are cheap — they cost opinions. Debates about "how" are expensive — they cost architecture decisions, tooling investment, and operational commitments.
The evidence is in that agentic development works. What remains unclear is which patterns and practices make it work reliably.
Fowler is careful not to overclaim. Patterns are emerging, not established — one attendee had catalogued dozens of competing agentic engineering pattern libraries. A dozen pattern libraries is not a mature discipline; it is a field still finding its shape. But the direction is set.
Harness engineering as a discipline
The term Fowler flags as new is harness engineering — a phrase that "wasn't even a term in Utah," five months earlier. Its rapid arrival is itself the point: the vocabulary is moving faster than the practice.
A harness is the scaffolding around a model that turns raw text generation into useful work — the tools it can call, the context it receives, the approval and execution rules, the memory it persists. Harness engineering is the emerging craft of building and tuning that scaffolding.
The notes capture one concrete workflow shared at the retreat:
- Take a story from the backlog.
- Talk it over with an agent until you reach agreement.
- Record the agreed spec as an ADR (architecture decision record) for a persistent, human-readable trace.
- Have the agent generate a task list.
- Have the agent complete the tasks.
Note what that workflow preserves: a durable spec, agreement before execution, and a task decomposition a human can inspect. Harness engineering is not about handing the model a prompt and hoping. It is about building the rails — spec capture, decision records, review points — that make agent output reviewable and repeatable.
Does architecture still matter?
Fowler surfaces a debate carried over from Utah with two competing hypotheses about whether design still matters when agents write the code.
| Hypothesis | Claim | Implication |
|---|---|---|
| Galaxy Brain | The model is capable enough to handle any amount of spaghetti | Architecture and design become optional |
| Circle | "The Venn diagram of Developer Experience and Agent Experience is a circle" (Laura Tacho) | Good design helps agents as much as humans |
The second hypothesis is the more useful one for builders. Its logic: an agent understands a codebase using the same constructs humans do — module boundaries, names, structure. So good modularity and clear naming are not human conveniences the agent can ignore. They are the same signals the agent relies on to navigate and modify code correctly.
Mathias Verraes, cited in the notes, adds a risk-based argument for design. Good design is a hedge against AI dependence. Costs may rise. Governments have blocked access to models. Public opposition to data centers is growing. If AI tooling becomes more expensive or less available, well-designed software is the code you can still maintain by hand. Design is insurance against a future where the agent is not there.
The token-cost reckoning
The most concrete shift in the notes is financial. Where earlier gatherings wanted to incentivize people to use AI at all, "people are now worrying about the cost of tokens."
Fowler cites reporting (from 404 Media, based on leaked internal material from companies including Citi and Amazon) with numbers that explain the worry:
- One company's token bill rose from $5 million in August 2025 to $15 million in May 2026, on track to exceed $120 million for the fiscal year.
- Companies are urging staff to use less powerful models — or cutting off frontier models entirely.
- The biggest driver was not agentic software engineering. It was staff "chewing tokens" on tasks like turning PDFs into presentation slides.
That last point is the one builders should sit with. The runaway cost came from undirected general use, not from the disciplined agent workflows the retreat was celebrating. Consulting firms that spent a year urging clients to adopt AI heavily are now, Fowler notes with some irony, selling services to control the resulting costs.
One reported cost-reduction tactic: a skill that gets AI tools to "speak like cavemen" — fewer tokens per exchange. The absurdity of the fix underlines the seriousness of the problem.
What this means for builders
Four takeaways from Fowler's notes.
Invest in the harness, not just the prompt. The retreat's consensus is that reliable agentic development comes from scaffolding — spec capture, ADRs, task decomposition, review gates — not from clever one-shot prompts. Treat the harness as engineered infrastructure with the same rigor as CI.
Keep design quality high, because agents read it too. If the "circle" hypothesis holds, clear module boundaries and naming improve agent performance directly. Do not let "the model will figure it out" become an excuse to skip design — it degrades the agent's inputs.
Meter and attribute token spend now. The enterprises in trouble did not see the curve until it was a nine-figure line item. Instrument token usage per team and per task type early. The expensive uses are often mundane document-shuffling, not engineering.
Treat model availability as a risk, not a given. Between rising costs, government model blocks, and data-center opposition, the assumption that frontier models will always be cheap and available is not safe. Design software you could still maintain if that assumption fails.
Conclusion
Fowler's July 6 fragments capture a field mid-transition. The "whether" debate about AI in software is over; the "how" debate is where the real work now sits. Harness engineering has a name but not yet a settled practice. And the token-cost reckoning has arrived — driven less by disciplined agent workflows than by unmetered general use.
The through-line is maturity. Agentic development is no longer a bet on the future; it is production reality with production problems. The teams that treat harness design, code quality, and cost metering as first-class engineering concerns will be the ones still shipping when the novelty and the free-token era both wear off.