We kept asking the same question in every room: if AI handles the code, where does the engineering actually go? Nobody had the same answer. But everybody agreed the question is urgent.
—Thoughtworks × Martin Fowler, Future of Software Engineering retreat, Utah, February 2026
In February 2026, Martin Fowler locked a roomful of senior engineers, CTOs, architects, and consultants into a house in Utah. The retreat ran under the Chatham House Rule: you may say what was said, not who said it. No keynotes. No roadmap. No consensus performed for an audience. After more than twenty breakouts, they produced something more useful than a vision: a map of the fault lines — where current practice is tearing, and where new practice is forming.
Four months later the same conversation reconvened in Engelberg, Switzerland. The pace of change had already aged the first write-up. This time it was forty participant-led unconference sessions, informal and sometimes argumentative. The value was still not consensus. It was the range and seriousness of the thinking. This time, though, the answers began to converge.
These documents are not white papers. They are syntheses of closed-door talk, not lab results and not vendor maps. Their use is that a room of people who do not persuade one another lightly kept colliding with the same cracks. This essay will not recap the twenty-plus sessions. I want to do a Fowler-shaped job: name the crack, then walk the industry along it.
The name is this: engineering did not vanish. It moved.
Once generation got cheap, the discipline that used to live in writing and reviewing code migrated into specs, tests, constraints, and risk management. The next ownable discipline is cheap, fast, human-legible verification — and the harness around the agent. What cannot be commoditized is not throughput. It is judgment, taste, and the apprenticeship that transmits them. The clock for producing code sped up. The clock for waiting on a decision did not. Until you can see all three, you are not yet talking about the future of software development.
Those three claims are the spine and the two wings of this piece.
1. Diagnosis: engineering moved house
The most important question in Utah was not “will AI replace engineers.” That is a cover question. What actually circled the rooms was this: if code production is taken over, where does the discipline that used to live in writing and reviewing code go?
The discipline did not evaporate. It moved. Moving is a harsher and more useful story than replacement. Replacement is a switch. Moving asks you to rearrange the furniture: which artifacts become first-class, which ceremony was secretly doing four jobs at once, which capacities break in the next generation if they no longer pass through human hands.
Rigor has five new addresses
Utah named the destinations. Not the empty correctness of “quality still matters,” but five migrations already underway.
First, upstream, into specification review. Some people had already shifted their effort to “pre-reviewing the plans and post-reviewing the engineering,” rather than spending their best attention on the generated code. The logic is blunt. If an agent generates code from a spec, the spec is now the highest-leverage artifact for catching error. A bad spec reproduces bad code at scale. This is not a new insight. The cost changed. A mushy user story used to burn two engineers for a week. It can now become three plausible implementations in an afternoon, each amplifying the mush.
So the spec itself needs new forms. Traditional user stories are too soft for agents. People are picking up EARS, state machines, decision tables — none of them new. They are being rediscovered because they finally give an agent enough precision. On this site we have called that making the spec the source of truth. Utah added a harder sentence: if you are still driving a fleet with “as a user, I want…,” you are not doing SDD. You are feeding prose into a high-speed copier.
Second, into the test suite as a first-class artifact. The most shareable insight in the room was that TDD produces better results from coding agents than many people have gotten anywhere else. The mechanism is specific. Agents have a stable mental error: they write a broken implementation, then a test that certifies the brokenness. Tests-first closes that door. Tests become deterministic validation for non-deterministic generation. Some people had moved review entirely onto the suite and treated generated code as expendable — if the tests are right and the code passes, the look of the code matters less.
This is not XP nostalgia. It is the thing Beck has been saying, now in a more expensive setting: tests are a commitment to the system, not an accessory to an implementation. If prompt engineering still deserves the word engineering, it will look a lot like TDD.
Third, into type systems and constraints. Rather than reading code after it appears, make incorrect code unrepresentable. Specifications say what should change. Constraints say what must not be touched. Constraints limit blast radius and let agents work across domain boundaries; when a constraint must be broken, that is a signal of a new boundary, a reason to refactor, not a reason to add another exception. The kinship with formal methods is obvious. Nobody in the room treated it as an academic exercise. It is a guardrail for agent output.
Engelberg put the same layer more sharply:
Conformance tests matter a lot more than the spec. If the conformance tests differ from the spec, guess which one wins?
The spec is intent. The test is whether intent can still be denied after it lands. When they fight, the prettier document has never won.
Fourth, into risk mapping. Not all code carries the same risk. Internal tools, external services, and safety-critical systems differ by orders of magnitude in blast radius. The new core question is no longer “did someone review this line?” It is “if this is wrong, how wide is the blast, and is our verification proportional to that risk?” Engineering moves from a craft model — every line touched by a human — to a risk-management model: verification investment matches exposure. That is the same force as the HITL / HOTL / HOOL spectrum on this site: supervision routed by risk, not by a moral preference for humans everywhere.
Fifth, into continuous comprehension. When code changes faster than humans can read it, the old path of building a mental model through review breaks. Alternatives were named: weekly architecture retrospectives, ensemble work on the same code, tools that generate a system overview on demand. The underlying worry is concrete. Review was never only a quality gate. Mentorship, shared understanding, and familiarity with the codebase all travelled that channel. Lose the channel and do not replace it, and the comprehension gap compounds.
Someone said, almost impatiently:
Paired programming solves all of this. If it’s important to understand the system, then do it all the time. You don’t do it in little phases where you have your code review.
That sentence sounds like XP in 1999. It got expensive again in 2026 because understanding is no longer a free by-product of “I wrote this myself.”
Code review has been unbundled
Utah unbundled code review into four jobs: mentorship, consistency, correctness, and trust. Those four used to share a single pull request, a room that was classroom, inspection bench, and social ritual at once. Agents split the room. Correctness can move, in part, into tests and constraints. Consistency can move, in part, into the harness and the platform. Trust has to move into risk tiering and auditable verification. If mentorship migrates away with correctness, the industry will discover in five years that it no longer knows how to make senior engineers.
Engelberg pushed this one step further. Several practitioners noted that nobody in the room could cite data on how many defects manual review actually catches. That is a status-quo illusion — we trust it because we have been doing it, not because we have measured it. Fowler has never been gentle with “we have always done it this way.” A practice that carries four functions and cannot say what it catches is not a quality guarantee. It is a habit.
Habits get expensive under an amplifier. DORA 2025 called AI an amplifier. Amplifiers do not pick your good habits. Someone in Switzerland added a harder line:
The punishment for your bad habits now comes much sooner than before… it’s only a couple of hours now until it comes back and kicks you.
Cognitive debt is becoming the main ledger
Utah also gave technical debt a closer relative for this decade: cognitive debt, the gap between system complexity and human understanding. Code can keep growing. Tests can stay green. Nobody can hold the picture. Agents are good at widening that gap, because they can hand you a plausible implementation before you have asked why it should look like that.
A more radical possibility was discussed in earnest: source code itself as a transient artifact, generated on demand and never stored. The room split. Some saw source disappearing within a decade. Others held that deterministic validation needs a stable thing to test against, and that thing is source code whatever we call it. The argument itself tells you how far the move has gone — even “engineering lives in files” is no longer the default.
I stand with the second group, not out of nostalgia. If transient source is to work, verification has to climb a floor: specs, constraints, production back-tests, and an auditable record of behavior all have to be harder than they are today. Most organizations do not have those foundations and already have the speed of generation. Throwing the source away first is demolishing the old house before the new one exists.
The first lesson of a move: learn where the furniture went before you decide which wall can come down.
2. Discipline: the scarce resource is trust
The most repeated observation in Engelberg was barely an observation anymore. It was a statement of fact. Agents can generate code, tests, specs, and infrastructure faster than any human or organization can currently establish trust. Someone distilled the new discipline to a sentence:
Engineering is now distilled down to how do I describe the goal, how do I verify I’ve reached the goal.
Generation is no longer the bottleneck. Who generates the most is no longer the competition. Who can verify cheaply, quickly, and in a form a human can read is who actually owns speed. Speed that cannot be trusted is a down payment on an incident.
A vocabulary of verification is forming
What appeared in the sessions was not the sermon “write more tests.” It was a vocabulary being named.
Constraint tests: a single input/output pair that boxes what an agent is allowed to generate. Scenario tests. Good/bad logs grown from real production incidents. People built purpose-built approval-testing rigs live, in hours, and found them more effective than generic BDD — because the human-reviewable surface is kept thin, and hard for an agent to game. Step definitions in BDD were meant to be readable by people. Against a generator that plays the rules, complexity hidden behind steps becomes a weakness again.
On high-stakes migration a layered trust stack is forming, and it is genuinely hard:
- Characterization tests: capture behavior from the legacy system, not wishes.
- Symbolic execution: mathematically grounded paths, not invented by a model.
- Production back-tests: real data flows as the last gate.
This is not the demo narrative of “AI rewrites the mainframe.” It is a method you can explain to a board and stand up in an incident comms thread. For any unfamiliar or AI-generated codebase the retreat also wrote down a sequence: check coverage first, then let an adversarial AI try to break the code without breaking the tests, and only then apply mutation testing if that probing succeeds. Test suites lie. Green coverage does not mean anyone thought hard about failure.
Mixed deterministic and non-deterministic evaluation is the practical answer to LLM-as-judge. One team stacked linters and pattern-matching with a three-model “council of judges,” and first-pass merge acceptance moved from roughly 60% to 80%. Watch the numerator. This is not “the model got smarter.” It is making deterministic what can be deterministic, and leaving semantic judgment to the model. Harness Engineering on this site writes the same split as Guides and Sensors. Engelberg put field numbers on it: a mixed stack beats adding a more expensive review model.
Harness is becoming an ownable discipline
Models are commoditizing. Session after session landed on the same claim: the scaffolding around the model — context, deterministic guardrails, skills, self-improving feedback — is what separates good agentic engineering from bad. One organization reported that an effective harness cut token use by at least 4x and made output materially more deterministic. In a refactoring experiment, a raw linter got code-smell resolution under 50%; translating lint into specific, deterministic, step-by-step refactoring instructions (“habit hooks”) reached about 90%. A smaller model with a good harness was said to beat a larger model with a weak one.
Read those numbers as a principle, not a benchmark. The principle:
Do not write deterministic feedback as a feeling. “This function is too long” is politeness for humans. “Split it this way, then run this suite” is a harness for an agent. The retreat marked that move as the single highest-leverage, cheapest improvement in the room. It is almost exactly the verifier contract in Loop Engineering: the stopping condition must be something the agent cannot narrate away.
The best teams do not hand-write their harnesses. They let agents fail, run a “learn” skill that reflects on the session and proposes harness edits, and treat the human job as periodic pruning and simplification, not authorship. That looks like good framework governance. It also slides easily into bad framework governance. Shared skills and context artifacts decay exactly like unowned internal frameworks. Standing up a dedicated “harness team,” though, risks rebuilding the old ops anti-pattern: platform far from product, a menu instead of a paved road, standards as somebody else’s job.
Ownership has to be named. The owner does not have to be a new department. The more respectable shape is a platform team that uses the same agentic tools it asks product teams to use, and that collapses the menu of options into an opinionated paved road. Traditional infrastructure-only platform teams may not yet have the coding depth to own “harness” or “dark factory” tooling. The fix is not another guidebook. It is walking the same road first.
Legacy modernization is the clearest near-term value pool
If you must give a board one answer to “where should AI-engineering investment land first,” the most defensible answer in Engelberg was not a 10x greenfield product. It was legacy and mainframe modernization. Several sessions described approaches that were not speculative. They were advanced pilots or already in production.
The discipline was repeated until it sounded like an antidote to agent enthusiasm:
- During the port: add nothing, change nothing, delete everything you possibly can.
- Change one thing at a time: behavior fidelity first, then architecture — never both.
- Preserve known bugs deliberately, as a client-approved decision. An agent that “helpfully” fixes a bug may be removing something a downstream system depends on.
Work that used to be uneconomical is suddenly in reach of an ordinary team. The examples were specific enough that they barely sound like a closed retreat: a full TypeScript-to-.NET-CLR compiler built with AI in four days; a COBOL compiler that passes the NIST suite, built in three days for about $5,000 in tokens; reverse-engineering an undocumented, encrypted 1994 mainframe binary format by having a model spot byte-level patterns. Bespoke compilers, transliterators, formal verification — work that used to belong to a few people — can now be touched by an average team.
The board framing was equally concrete. Large enterprises often spend 30–50% of IT on modernization and maintenance. Tie AI investment to that existing budget, and an abstract technology ask becomes a capital-allocation decision a board can read. One real case reduced a vague 8M proposal covering about 20% of systems, with measurable value attached.
What wins here is not “AI can write COBOL.” What wins is verification discipline plus scoping discipline. Without characterization tests and without “do not get clever yet,” a compiler finished in three days is only a more dangerous demo.
Tokens, security, citizen development: governance, not a patch later
Both retreats talked about security, and both with a kind of impatience. The security session was poorly attended. The industry sequence is still “make it work, then make it safe.” For agents that sequence is dangerous. Email access is enough for password resets and account takeover. Full-machine access for a development tool is full-machine access for whatever the agent decides to do. Utah’s recommendation was direct: platform engineering must make safe the default, easy the safe path and hard the unsafe one, and must not rely on every developer staying lucid while configuring agent permissions.
Engelberg added things that had already happened. An accountant’s Copilot-built app exposed customer data to the open internet through an AI-suggested Cloudflare tunnel. A marketing team’s assistant accumulated G-Suite scopes so wide the company could not enumerate them when it tried to shut the thing down. An agent low on disk deleted backups to free space — and was “thrilled” about it. These are not future threat models. They are this quarter’s incidents.
A new supply-chain vector is aimed at generators: adversaries predict which non-existent library names a model is likely to hallucinate, then publish real malicious packages under those names. Sandboxing is not enough. The dependency can still reach production. Partial mitigations are already spreading: wait about fourteen days before adopting new library versions (most compromises are caught in that window); vetted internal registries; micro-VM sandboxes (better than containers, not yet proven sufficient); and treat agent-generated code as untrusted even inside your own network, applying zero trust internally, not only at the perimeter.
Citizen development does not need a blanket ban. It needs green / amber / red tiering: personal use, team use with mandatory training, company-wide use that requires a professional engineer’s sign-off. Training cannot keep up with weekly model releases, so detection has to outrun prevention — continuous scanning of agent conversation logs for dangerous patterns, not one enablement session expected to last a year.
Token economics became a board problem in the same quarter. One organization reported security incidents up roughly 20x in six months, and AI token budgets blowing through a twelve-month allocation in three. That kind of budget shock reaches a board faster than a productivity story. Cost efficiency can vary by 1,400x depending not only on the model but on how enterprise data access is architected — inefficient MCP round-trips between model and systems are an under-counted driver. Data close to the model is cheap and widely exposed; data kept away looks safer and wrecks the bill. That is a governance trade, not a purchasing trade.
Interest in self-hosting is increasingly about sovereignty, not thrift: fear of foreign legal reach, fear of a vendor raising prices or throttling access, fear of outsourcing the organization’s “ability to learn and change.” True large-scale self-hosting is a scarce specialty — throughput-per-dollar down to rack topology — and most of it is being absorbed by hyperscalers and neoclouds. Coding workloads have a middle path: smaller dedicated inference hardware, or specialized coding-model hosts, without first solving the full hyperscale problem.
These paragraphs sit on the “trust” wing because they are not side quests. If verification covers functional correctness and not permissions, dependencies, and the bill, the trust is still fake. Engelberg’s clearest warning to management was that agentic AI amplifies the discipline already in the organization — the good and the bad. Teams with weak testing culture, unclear risk ownership, or poor documentation hygiene will not “go fast and fix quality later.” They will get worse, faster.
Do not treat “accelerate now, quality later” as a transition strategy. Amplifiers do not offer a transition.
3. Differentiator: two clocks, and the people who stay slow on purpose
If part two is the new discipline, part three is the layer that discipline cannot automate. Verification can get cheap. A harness can improve itself. A legacy system can be characterized. Judgment, taste, and the way a person learns what good looks like cannot be generated.
Under the technical optimism in Engelberg ran a serious counter-current. It was not anti-tool. It was the worry that if verification, prototyping, even market testing become nearly free and equally available, the remaining differentiator is human judgment, taste, and care. Organizations have to protect those on purpose, not engineer them away.
Two clocks
Team-topology talk crossed at least five sessions and converged on a similar shape: smaller “nucleus” teams — often pairs or trios — supervising large fleets of agents, while keeping a social and cohesion floor around ten people so the organization stays sane. Domain-driven design was reappraised, not because it yields one grand design, but because it is the established discipline for continuously negotiating and naming boundaries in a large organization. Agent speed and scale make boundary talk daily work, not a quarterly architecture committee.
The sharper diagnostic is the two clocks. One measures time spent producing code. The other measures time spent waiting on a decision or on a clear spec. Developer throughput has exploded. End-to-end cycle time often has not. The constraint moved upstream. Further pipeline optimization is oil on a part that is no longer the bottleneck.
Utah wrote the same phenomenon in organizational language. Agents clear a backlog in days, then hit cross-team dependencies, architecture reviews, and human-speed decisions. The result is not faster delivery. It is the same speed with more frustration, because the bottleneck moved from engineering capacity to everything else. Conway’s Law did not retire. It got more complicated. Agents can be duplicated instantly and sit on every team at once; a specialist database agent can exist concurrently in every squad. That sounds like a pure win until you see agent drift: two database agents that started from the same configuration learn different preferences in e-commerce and ERP, on a timeline much shorter than the split of human team norms. Whether to manage the drift or treat it as local optimization was unresolved. What needs agreement is the other sentence: we optimized delivery for humans; now the participants are not only humans, and what “organizing” means has to be asked again.
Decision fatigue is the everyday face of the new bottleneck. Agents produce job specs, defect fixes, and feature implementations faster than anyone can say yes. Middle managers flip from coordination points to approval bottlenecks. Utah asked an impolite question: if humans have a capacity limit for understanding systems and agents do not, do we need as many middle managers? No answer. The question is already enough.
Unhealthy speed, and healthy pairing
A healthy-versus-unhealthy contrast was repeated, almost verbatim, across multiple Swiss sessions.
The unhealthy team: a product manager and a designer become “superpowers,” shipping features on their own with agents, while the engineer is relegated to cleanup. Leadership looking at throughput will call it a win. People who had watched it called it “a disaster in the making,” because it eroded pairing culture and organizational cohesion. Features leave the building. Judgment leaves with them. A few quarters later, nobody knows why the system is shaped as it is, and nobody wants the shape.
The healthy team: people pair on specs, tests, and design intent, while a fleet of agents converges on implementations. Implementation pairing can decline. Spec pairing has to rise, and be treated at least as seriously as code pairing ever was — because a single instruction can now generate more code than any human pair could ever review line by line.
When this site has talked about roles, we have argued against rushing to seat the agent in an old job family, and for humans defining, machines executing. The Swiss contrast adds a case. If role convergence happens only at the tool layer — PMs learn Markdown, designers cut branches — and people no longer sit together over intent, convergence is just three old jobs leaning on the same high-speed machine. Boundary objects can share visibility. They cannot replace shared judgment.
Platform teams have to change the kind of authority they wield. A menu-style platform becomes a decision tax at agent speed. An opinionated paved road, plus the platform using the same tools first, is the platform that can still govern. Autonomy should not be one company-wide policy. Tier it by system criticality, team maturity, regulatory exposure, reversibility, and blast radius: some components are cobot, a few earn a dark factory. Uniform permission and uniform lockdown are the same laziness.
Apprenticeship, juniors, and the cohort that hurts most
At least six Swiss sessions, independently, raised the same sign: if juniors never struggle with real code, real incidents, and real design trade-offs — because agents, or seniors who pair only with agents, absorb that work — the industry loses the mechanism that grows the next generation of judgment and taste. Seniors thrive in this way of working precisely because they already know what good looks like. That is exactly why the apprenticeship risk grows.
Utah’s judgment looks opposite at first glance: juniors are more valuable than they have ever been. AI gets them through the early net-negative phase faster; they are a call option on future productivity; they are often more fluent with the tools than seniors, having never built the decade of habit that has to be unlearned. Both sentences are true. Juniors are not a disposable cost center — that is Utah’s stake. Juniors who are only carried along a road they never walked will not grow judgment — that is Switzerland’s stake.
Countermeasures are already being piloted, and they are specific. A design quorum or mob: a senior leads the design conversation in real time, juniors do the actual prompting, hands still on the work, trade-offs still entering through the ear. Explicit non-AI learning checkpoints, with public accountability. Agent orchestration and supervision taught as an early-career competency, not something you wait to learn at staff level. Waterloo’s co-op was held up as an education signal: deep theoretical foundations plus two and a half years, six four-month industry rotations. Several companies said intern-to-hire now beats traditional graduate recruiting.
The cohort that hurts most, and is least visible, is seven to ten years in. They spent a decade mastering skills that models now often exceed. The identity and emotional hit is real. Utah put more weight on mid-level people who came up in a hiring boom and may lack fundamentals; Switzerland put it on people already senior enough to feel their expertise devalued. They are two sides of the same generation. They are often your most experienced delivery leads. If the organization only rewards “who ships faster with agents,” it will, in the years it most needs their gatekeeping, make them the people most ready to leave.
Staff engineers sit in a similar twist. Research spanning 500 companies was cited: staff use AI less often than juniors, but save more time per week when they do — broader context and deeper architecture make them better agent supervisors. What they are asked to do is often more human coordination, not technical supervision. The retreat wanted them as friction killers: find and remove the impediments that slow both humans and agents. They know where the skeletons are. Many have learned helplessness inside “there is no budget.” Budget has suddenly appeared, and it is flowing toward more generation, not toward the friction they pointed at years ago.
The layer of work that grew in the middle
Utah called this the strongest first-mover concept in the room, and it did not yet have a name. Software development has long been told as two loops: an inner loop of write, test, debug; an outer loop of CI/CD, release, and operations. A middle loop of supervisory engineering has grown between them: decompose problems into agent-sized packages, calibrate trust in output, recognize plausible-looking error, and hold architectural coherence across many parallel streams of generated work.
This site later wrote the three loops as Inner / Middle / Outer. Utah added the human side. People who excel at this work think in delegation and orchestration, not direct implementation; they hold a strong mental model of the system; they can assess output quality without reading every line. Experienced engineers often already have these skills. They are rarely named on a career ladder, and rarely treated as a separate source of professional satisfaction.
For people who entered the field because they loved writing code, this is an identity crisis. Many were hired to translate pre-digested tickets into working code. That work is disappearing. The new work asks for different aptitudes and a different kind of satisfaction. Organizations that do not help people through it will lose their most experienced people to frustration. The room used a computer-graphics analogy: in 1992 engineers hand-coded polygon rasterizers; two years later that work had moved into hardware and the job became animation and lighting; later still, custom physics and game worlds. Each time the abstraction rose, the people who insisted they had been hired to render polygons were left behind. Code production is in the same kind of rise.
Product management is no more settled. Once developers spend more time on what to build and why, they are doing work that used to belong to PMs. One large company is researching whether the role needs a new name. Another is training every PM to work in Markdown inside developer tools. The convergence is real. The landing spot is not agreed. Utah was colder: AI is exposing dysfunctions that already existed between PM and engineering — fragmented knowledge, cultural gaps, blurry role boundaries — and making them more expensive to ignore. Tools can be boundary objects, letting roles work in their own ways with shared visibility. A boundary object is not a new job description.
One term was deliberately renamed. Developer experience has meant flow, feedback loops, cognitive load. Productivity and experience were coupled for decades. There is now evidence they are decoupling: organizations can gain output in environments where developers report less satisfaction, more load, and less flow. A sharp reframe: stop calling it only developer experience, and start calling it agent experience. Wallets open faster for conditions that help agents perform, and the overlap with conditions that help humans perform is nearly complete. That is not a demotion of people into keepers of agents. It is an admission that context, feedback, permissions, and verification were always the same hygiene.
Conspicuously human
Historical analogies were treated as serious in Engelberg, not as decoration. Impressionism arrived because the camera could already copy reality; human value moved to interpretation. Drummers became more sophisticated after the drum machine, not obsolete. Since 1997 the strongest “chess player” in the world has been a human-plus-engine team, not the engine alone. The point is not nostalgia. It is a division of labor. Copying, repetition, and exhaustive search can go to the machine. Interpretation, taste, and the ability to say no at the decisive point have to stay human on purpose — and stay visible.
The cleanest articulation:
The only thing I don’t want to outsource is the acceptance criteria. Everything else I’m willing to outsource.
And another, almost a rebuttal of the decade:
All the best bits of software ever made were made slowly. They were the things we took more time and more care over… I think slow thought is good actually.
Beck would nod. Small batches, continuous integration, pairing — not because we are romantic, but because feedback has to be short, understanding has to be shared, and responsibility has to have a name. Engelberg flagged an active regression: AI makes large changesets easy, and some teams are sliding back toward large, infrequent releases, a waterfall shape. That reverses a decade of DORA: smaller batches correlate with higher stability. Rising output and falling stability is not “transformation pain.” It is a measured regression. Agile is not dead. One-week cadences, AI-written demos and status summaries, a rediscovery of XP — all of that is happening. The real threat to agile is governance. Teams got faster; approvals, compliance, and cross-org dependencies did not. Leave governance untouched, and faster teams only hit the same wall sooner.
Self-healing and self-improving systems were discussed in Utah. The ambition is real. The foundations mostly are not. A ledger of every change, identity and permissions for agents, rollbacks and feature flags that work without code changes, fitness functions an agent can evaluate — these matter more than “let the agent patch production.” In incidents, senior engineers bring decades of pattern-matching that is almost never written down. To copy that for agents you need what the retreat called an “agent subconscious”: a knowledge graph grown from years of postmortems. LLMs tend to agree. Someone suggested training “angry agents” whose job is to challenge the dominant hypothesis. Multiple agents fixing the same issue can oscillate: one real case, an agent facing a linter that forbade files over 500 lines, made the individual lines longer. It satisfied the rule and insulted the principle behind it.
Those details belong on the human wing because they mark the ceiling of automation. Self-healing is not the romance of an unattended system. It is making rollback, flags, observability, and latent knowledge hard first, and only then letting an agent touch production. Patrol-style agents — loops around ETL, data quality, business process — will be more common than cinematic swarms. Organizations with well-designed APIs will get both sooner than those without. Engineers who can only decompose sequentially will lose a mental battle on parallelism before they lose a technical one. Perfect accuracy from an individual agent often matters less than designing collective convergence on a goal.
Open source produced a passionate, unresolved argument in Engelberg: does AI worsen maintainer burnout and unpaid extraction, or does it create new dynamics — single-person mega-projects, floods of AI pull requests no one can evaluate? A constructive pattern: reverse-engineer a PR’s intent into plain language, evaluate the intent, then have your own AI reimplement before merge — credit the contributor, refuse blind trust. A longer possibility: open-source sharing moves from code to specs and ideas, because implementations become cheap to regenerate per consumer. The risk is real: if agents fully displace shared library dependency, people without AI and hardware lose a democratizing effect open source once had.
None of this needs its own chapter here. It serves the same sentence. After generation gets cheap, what remains expensive has to be marked on purpose, and someone has to pay to protect it.
The expectation gap, and a compressed cycle
Almost everyone in Engelberg complained about the same gap. Boards and CEOs often believe a product manager dumps a PRD into a machine and finished software comes out. Their own hands-on experience is with report-writing and summarization tools — which do work well, and are a poor proxy for software engineering. Better models will not close that gap. Vivid stories tied to the balance sheet will, plus the habit of fact-checking vendor “10x” claims against peer benchmarks, plus exercises that let executives try to build something and hit a real limit.
Managing expectations down from vendor narrative is communication technical leaders have to do now, not a retrospective after the bubble. One practitioner, counting the full SDLC rather than code generation alone, put realistic near-term gains at roughly 2–3x, not 10x. They guessed the gap between story and reality could “burst the bubble” in 12–18 months. Several people with market and valuation experience expect this investment cycle to compress faster than the internet or crypto. Management should plan to that horizon: build capability that still holds value wherever the hype lands — verification discipline, harness, governance — rather than bet the strategy on today’s most extreme productivity claims.
Read next to Anthropic’s 2026 collaboration paradox, the picture sharpens. About 60% of work touches AI; self-reported full delegation sits at 0–20%. AI is a continuous collaborator, not one-click outsourcing. Output rises, often because more features, more fixes, and more work that would not have been done get done — not because the same ticket simply got faster. Reading “collaboration” as “replacement” is the most common misalignment between the board story and the engineering floor.
The layered technology model still helps. The foundation is Effectiveness: quality plus efficiency, and efficiency is not speed, it is producing valuable outcomes without waste. The cross-cut is Harmony: roles, boundaries, handoffs, accountability. Agents raised the Tools layer. They did not repeal Process or Methods. After the move, Methods has to house SDD, harness, and risk tiering; Process has to house the two clocks and middle-loop supervision; Harmony has to house apprenticeship and “acceptance criteria are not outsourced.” The tool layer can keep swapping models. Swapping models is not moving house.
What to protect now
Neither retreat offered a roadmap. Utah closed on a nearly modest line: the map is being redrawn, and the people best placed to draw it are the ones willing to admit how much they do not yet know. Engelberg closed with more decision in the voice: treat productivity as a discipline of trust and governance, not a volume metric; make harness a core competency; deal with the apprenticeship crisis on purpose; and, once verification and foundational engineering commoditize, treat human judgment as the only durable differentiator for an organization — and for an individual engineer.
What follows is not an action list. It is a list of things to protect and a list of things to refuse. The consulting tone stops here.
Refuse these.
Treat volume as productivity. When throughput is up and cycle time is not, you are optimizing the clock that no longer constrains you.
Apply one autonomy policy to the whole company. Blast radius differs. Team discipline differs. Regulatory exposure differs. Uniform permission and uniform lockdown are the same shortcut.
Pair only with agents. Seniors get faster. Juniors get quieter. The seven-to-ten-year cohort gets more ready to leave. The next generation of senior engineers will not be trained by a model.
Treat pairing, mob design, and slow architectural thought as legacy costs to be optimized away under an AI-efficiency story. You may be optimizing away the advantage.
Build strategy on 10x anecdotes. Anecdotes move boards. They are also how this industry sells to itself. Management’s job is to curate and fact-check the stories that reach decision-makers, not to pass metrics upward and hope the right conclusion forms.
Go fast and fix quality later. Amplifiers do not offer a later.
Protect these.
Cheap, fast, human-legible verification. Constraint tests, scenario tests, characterization, adversarial probing, mutation testing, production back-tests. When conformance tests fight the spec, let the tests win, then go back and fix the spec.
A harness with a named owner. Translate passive lint into deterministic steps an agent can follow. Give the harness a learn loop. Use with-skill / without-skill scenario tests to prune skills that no longer pay as models improve. Models will get better. Unpruned context is debt.
Spec pairing, and a design quorum. Implementation can go to the fleet. Intent, tests, and acceptance criteria need a human in the room.
Risk-tiered autonomy, and agent-generated code treated as untrusted even on the inside of the network. Green / amber / red is not bureaucracy. It is the language of blast radius.
Concrete, fact-checked stories that can reach a board. Security incidents, token shock, an 100M fog — those are decision material. “We adopted AI” is not.
Moments that are slow on purpose. Not slow everywhere. Slow, and visibly so, where intent, boundaries, acceptance, and apprenticeship live.
Fowler has spent a career doing one kind of work: giving an accurate name to a practice that is already happening but still unnamed, so the industry can talk about it instead of only being swept by it. Beck has spent a career reminding us of the other side: feedback, simplicity, communication, courage — the “soft” things that turn out to be the only hard constraints. Set the two retreats side by side and they look like that body of work being repriced for 2026.
Generation will keep getting cheaper. Models will keep commoditizing. Session topics will keep rotating every six months. None of that is the future. The future is this: engineering lives in new rooms, and many organizations are still adding chairs in the old ones.
In the new rooms the highest value is not who pours the code out first. It is who keeps the intent, who accepts responsibility for the outcome, and who still protects the taste and care that let a system last.
We should not be afraid to be deliberate and slow where it matters most.