This document is a merged compilation of the two Thoughtworks Future of Software Engineering retreat reports, in the original English:

• Part 1 — The Future of Software Engineering: Retreat Findings and Strategic Insights (February 2026, Utah)

• Part 2 — The Future of Software Engineering (June 28–30, 2026, Engelberg, Switzerland)

The two parts are reproduced verbatim from the source PDFs, with only minimal cleanup applied: page numbers, running headers and footers from the PDF layouts have been removed; the two styled callouts that were mis-extracted as fragmented tables in the Utah PDF have been restored to their original callout form; and heading levels have been normalized. The body text itself is unchanged.

---

Part 1: The Future of Software Engineering — Retreat Findings (February 2026, Utah)

The future of software engineering

Retreat findings and strategic insights

Thank you all for joining us to wrestle with the questions that matter most as AI reshapes how we build software. What follows is a synthesis of key themes and takeaways from across all breakout sessions. The retreat was conducted under the Chatham House Rule. No participant names or affiliations are disclosed in this summary. February 2026

Executive summary

Senior engineering practitioners from major technology companies gathered for a multi-day retreat to confront the questions that matter most as AI transforms software development. The discussions covered more than twenty topics across breakout sessions, but the most significant insights didn’t emerge from one single session. Instead, they surfaced at various intersections; we found that the same concerns kept appearing in different conversations, framed by different people solving different problems. This publication synthesizes those cross-cutting themes, organized around the patterns that senior leaders need to understand and act on now. The retreat did not produce a single, unified vision of the future, but instead produced something more useful: a map of the fault lines where current practices are breaking and new ones are forming. “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.”

Themes at a glance

| Theme | Horizon | Core Insight | | Where does the rigor go? | Now | Engineering quality doesn’t disappear when AI writes code. It migrates to specs, tests, constraints, and risk management. | | From code review to risk tiering | Now | Code review is being unbundled. Its four functions (mentorship, consistency, correctness, trust) each need a new home. | | The productivity/experience paradox | Now | Developer productivity and developer experience are decoupling. Organizations face hard choices about which to optimize. | | Security as afterthought | Now | Agent security is woefully underdeveloped. Email access alone can enable full account takeover. | | The middle loop | Now–1 yr | A new category of supervisory engineering work is forming between inner-loop coding and outer-loop delivery. Nobody has named it yet. | | Cognitive debt | Now–1 yr | Technical debt is becoming cognitive debt: the gap between system complexity and human understanding. | | Agent topologies | 1–3 yrs | Conway’s Law applies to agents too. Enterprise architecture must now account for agent mobility, specialization, and drift. | | Knowledge graphs & semantic layers | 1–3 yrs | Decades-old technologies are suddenly relevant again as the grounding layer for domain-aware agents. | | The future of roles | 1–3 yrs | PM, developer, and designer roles are converging. Staff engineers face new expectations. Juniors are more valuable than ever. | | Self-healing systems | 2–5 yrs | Moving from human incident response to agent-assisted healing requires solving the ‘latent knowledge’ problem first. |

1. Where does the rigor go?

The single most important question of the retreat. It surfaced in nearly every session. If AI takes over code production, the engineering discipline that used to live in writing and reviewing code does not disappear; it moves elsewhere. The retreat spent more time on this question than any other, approaching it from various viewpoints, including code review, testing, language design, self-healing systems and organizational design. The group identified five destinations where rigor is already moving:

Upstream to specification review

Several practitioners reported shifting their review efforts from code to the plan that precedes it. One described focusing on “pre-reviewing the plans and post-reviewing engineering” rather than the code itself. The logic is straightforward: if an AI generates code from a spec, the spec is now the highest-leverage artifact for catching errors. Bad specs produce bad code at scale. This has practical implications. Organizations experimenting with spec-driven development report that the specifications themselves need new formats. Traditional user stories are too vague. Some teams are adopting structured approaches like EARS (Easy Approach to Requirements Syntax), state machines and decision tables. These are not new techniques, but they are being rediscovered because they give AI agents enough precision to produce correct implementations.

Into test suites as first-class artifacts

One of the retreat’s most shareable insights was that test-driven development produces dramatically better results from AI coding agents. The mechanism is specific: TDD prevents a failure mode where agents write tests that verify broken behavior. When the tests exist before the code, agents cannot cheat by writing a test that simply confirms whatever incorrect implementation they produced. This reframes TDD as a form of prompt engineering. The tests become deterministic validation for non-deterministic generation. Several practitioners described moving review efforts entirely to the test suite, treating the generated code as expendable. If the tests are correct and the code passes them, the code is acceptable regardless of how it looks.

Practitioner insight

“I’ve gotten better results from TDD and agent coding than I’ve ever gotten anywhere else, because it stops a particular mental error where the agent writes a test that verifies the broken behavior.”

Into type systems and constraints

The retreat surfaced strong interest in using programming language features to constrain AI-generated code. Rather than reviewing code after generation, practitioners are exploring how to make incorrect code unrepresentable. This draws on ideas from formal methods and strong type systems, applied not as academic exercises but as practical guardrails for agent output. A key insight was the separation of specifications from constraints. Specifications describe what should change; constraints define the bounded contexts in which change is allowed, including what must not be touched. These constraints limit blast radius and let agents work safely across domain boundaries. When a constraint must be broken, it signals a new system boundary and prompts refactoring.

Into risk mapping

Not all code carries the same risk. The retreat discussed tiering code by business blast radius, distinguishing between internal tools, external-facing services and safety-critical systems. This risk mapping determines where human review is essential and where automated verification is sufficient. One practitioner framed this as the new core engineering discipline: instead of asking “did someone review this code?” organizations need to ask “what is the blast radius if this code is wrong, and is our verification proportional to that risk?” This moves engineering from a craft model (every line is hand-reviewed) to a risk management model (verification investment matches exposure).

Into continuous comprehension

If code changes faster than humans can review it, the traditional model of building mental models through code review breaks down. The retreat discussed alternatives: weekly architecture retrospectives, ensemble programming where multiple engineers work simultaneously on the same code and AI-assisted code comprehension tools that generate system overviews on demand. The underlying concern is real. One practitioner noted that code review has historically served as much as a learning mechanism as a quality gate. Mentorship, shared understanding and codebase familiarity all happened through review. Losing that channel without replacing it creates a comprehension gap that compounds over time. “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. Constantly trying to understand what this code is doing.”

2. The middle loop: a new category of work

The retreat’s strongest first-mover concept. Nobody in the industry has named this yet. Software development has long been described in terms of two loops. The inner loop is the developer’s personal cycle of writing, testing and debugging code. The outer loop is the broader delivery cycle of CI/CD, deployment and operations. The retreat identified a third: a middle loop of supervisory engineering work that sits between them. This middle loop involves directing, evaluating and fixing the output of AI agents. It requires a different skill set than writing code. It demands the ability to decompose problems into agent-sized work packages, calibrate trust in agent output, recognize when agents are producing plausible-looking but incorrect results and maintain architectural coherence across many parallel streams of agent-generated work. The practitioners who are excelling at this new work tend to share certain characteristics: ●​ They think in terms of delegation and orchestration rather than direct implementation. ●​ They have strong mental models of system architecture. ●​ They can rapidly assess output quality without reading every line. These are skills that experienced engineers often possess, but they are rarely explicitly developed or recognized in career ladders.

Career impact

The middle loop creates a genuine identity crisis for developers who fell in love with programming. Many were hired specifically to translate pre-digested tickets into working code. That their work is disappearing. The new work requires different aptitudes and different sources of professional satisfaction. Organizations that don’t help people through this transition will lose most experienced talent to frustration.

The retreat drew a parallel to the history of computer graphics. In 1992, engineers hand-coded polygon rendering algorithms. Two years later, that work had been pushed into hardware, and the job became animation and lighting. Today, it’s custom physics and game worlds. Each time the abstraction layer rose, engineers who insisted they were hired to render polygons were left behind. The same dynamic is playing out now with code production. The product management side of this equation is equally unsettled. If developers are now thinking more about what to build and why, they are doing work that used to belong to product managers. One large technology company is actively researching whether the PM role needs a new name. Another is training all product managers to work in Markdown inside developer tools. The convergence is real, even if nobody agrees on where it lands.

3. Agent topologies and enterprise architecture

Conway’s Law didn’t retire. It got more complicated. The retreat introduced the concept of “agent topologies” as an extension of the Team Topologies framework. The premise: if organizations design systems that mirror their communication structures, what happens when agents become first-class participants in those structures? Unlike humans, agents can be duplicated instantly and deployed across multiple teams without onboarding friction. A specialized database agent can exist on every team simultaneously, bringing consistent expertise without the centralization bottleneck that comes with a single human database specialist. This sounds like a pure win, but the retreat identified several complicating factors.

The speed mismatch

Agents burn through backlogs so fast they collide with slow organizational dependencies. One participant described the experience: you give a team AI tools, they clear their backlog in days and then hit a wall of cross-team dependencies, architecture reviews and human-speed decision-making. The result is not faster delivery. It is the same speed with more frustration, because the bottleneck has shifted from engineering capacity to everything else.

Agent drift

Agents that learn from their context will diverge over time. The database agent working on the e-commerce backend accumulates different patterns and preferences than the one working on the ERP system, even if they started from identical configurations. This mirrors the human problem of team-specific norms, but on an accelerated timeline. The retreat debated whether this drift should be managed (analogous to standardization efforts in human teams) or embraced (analogous to letting teams optimize locally).

Decision fatigue as the new bottleneck

If agents can produce work faster than leaders can review and approve it, the constraint shifts from production capacity to decision-making capacity. Middle managers who previously served as coordination points now become approval bottlenecks. Several practitioners reported this already happening at their organizations: agents generating job specifications, code fixes and feature implementations faster than anyone can say yes. The retreat asked a pointed question: if humans have capacity limits for understanding systems but agents do not, do we need as many middle managers? The group did not reach consensus, but the question itself signals a significant organizational challenge ahead. “We optimized the software delivery process for humans. Now that it’s not just humans, we have to ask what organizing actually means.”

4. Self-healing and self-improving systems

The ambition is real. The prerequisites are far from met.

The retreat explored whether software systems can move beyond human-driven incident response toward agent-assisted self-healing. The group distinguished between two levels of ambition: self-healing (returning a system to a known good state) and self-improving (actively evolving a system’s non-functional qualities like performance and reliability).

Prerequisites that don’t yet exist

Self-healing requires several foundations that most organizations lack: ●​ A clear ledger of every change, so agents can understand what happened. ●​ An operating system for agents with identity controls and permission boundaries. ●​ Strong generic mitigation capabilities (rollback, feature flags) that work without code changes. ●​ Fitness functions that define what “healthy” means in terms agents can evaluate. The retreat was blunt: code changes should be the last resort for incident remediation. The path to self-healing runs through better rollback, better feature flags and better observability before it runs through agents rewriting production code.

The latent knowledge problem

Senior engineers bring decades of pattern-matching to incident response. They remember that a specific error code is actually a symptom of a deeper infrastructure issue. They know that high CPU on a particular service means checking the database connection pool before anything else. This knowledge is almost never documented. It lives in people’s heads and gets applied through experience. To replicate this for agents, organizations need to build what the retreat called an “agent subconscious”: a knowledge graph built from years of post-mortems and incident data that gives agents historical context for interpreting real-time signals. Some organizations are already doing this with automated post-mortem drafting, but the human step of adding nuance and context remains essential.

The incident commander problem

Human incident commanders challenge assumptions, push back on comfortable hypotheses and maintain situational awareness. LLMs tend toward positive reinforcement and agreement. Building an effective agent incident commander requires solving this behavioral mismatch. One suggestion: train “angry agents” that are specifically designed to challenge the dominant hypothesis.

Agent coordination risks

Multiple agents attempting to fix the same issue can create feedback loops where one agent’s fix triggers another agent’s correction, creating an escalating cycle. The retreat cited a real example: an agent with access to a linter that enforced a 500-line file limit responded by making individual lines longer, technically satisfying the rule while violating the principle behind it. When multiple agents make different prioritization decisions about trade-offs, the system can oscillate rather than converge.

5. The human side: roles, skills and experience

AI is not replacing people. It is rearranging what people do and how they feel about doing it.

The productivity/experience paradox

Developer experience has traditionally been defined across three dimensions: flow state, feedback loops and cognitive load. Productivity and developer experience have been tightly coupled for decades; the retreat explored evidence that they are now diverging. Organizations can achieve productivity gains through AI tools even in environments where developers report lower satisfaction, more cognitive load and reduced sense of flow. This creates a genuine dilemma. If the organization can get more output without investing in developer experience, the business case for that investment weakens, unless the definition of developer experience itself evolves to account for the new realities of agent-supervised work. One practitioner offered a sharp reframe: stop calling it developer experience and call it agent experience instead. Wallets are likely to open faster to invest in conditions that help agents perform well, and the overlap with conditions that help humans perform well turns out to be nearly complete.

The staff engineer under pressure

Staff engineers are simultaneously more important and more stressed than ever. Data from one research firm spanning 500 companies shows that staff engineers use AI tools less frequently than junior engineers, but when they do use them, they save more time per week. Their broader context and deeper understanding of system architecture makes them more effective agent supervisors. The tension is in what staff engineers are asked to do versus what they should be doing. Many spend disproportionate time on human coordination rather than technical supervision. The retreat argued for a deliberate shift: staff engineers should become friction killers, identifying and removing the impediments that slow both human and agent work. Their deep knowledge of where the skeletons are buried makes them uniquely positioned for this role, but many have experienced learned helplessness after years of being told there’s no budget for the improvements they recommend.

Junior developers are more valuable, not less

The retreat challenged the narrative that AI eliminates the need for junior developers. Juniors are more profitable than they have ever been. AI tools get them past the awkward initial net-negative phase faster. They serve as a call option on future productivity. And they are better at AI tools than senior engineers, having never developed the habits and assumptions that slow adoption. The real concern is mid-level engineers who came up during the decade-long hiring boom and may not have developed the fundamentals needed to thrive in the new environment. This population represents the bulk of the industry by volume, and retraining them is genuinely difficult. The retreat discussed whether apprenticeship models, rotation programs and lifelong learning structures could address this gap, but acknowledged that no organization has solved it yet.

Education signal

The retreat highlighted the University of Waterloo’s co-op program as a model: deep theoretical foundations combined with 2.5 years of industry internships (six four-month rotations). Graduates emerge with both the fundamentals and the practical judgment that AI tools cannot replace. Several companies reported that intern-to-hire pipelines now outperform traditional graduate recruiting.

The future of product management

Nobody at the retreat could define what product managers will do in an AI-driven world. Some organizations are pushing PMs closer to technical tooling, training them to work in Markdown and developer environments. Others see the roles diverging further, with PMs becoming strategic orchestrators while developers take on more of the tactical product decision-making. What is clear is that AI is exposing existing dysfunctions in the PM-developer relationship rather than creating new ones. Knowledge fragmentation, cultural gaps between disciplines and unclear role boundaries existed before AI. AI is simply making them more expensive to ignore. The retreat emphasized tools as “boundary objects” that allow different roles to work in their own ways while maintaining shared visibility.

6. Technical foundations: languages, semantics and operating systems

The infrastructure for the agent era doesn’t exist yet. These are the pieces being assembled.

Programming languages for agents

Every programming language in existence was designed with humans as the primary user. Dynamic typing exists to reduce cognitive overhead for human programmers. Strong static typing exists to catch human errors. The retreat asked what a language designed for agent-generated code would look like, and whether it would also serve humans better. The group converged on a principle: what is good for AI is good for humans. Languages that make incorrect code unrepresentable (through strong types, restricted computation models and formal constraints) help agents produce correct output and help humans verify it. Conversely, languages that favor expressiveness over safety make both agent generation and human review harder. The more radical possibility is that source code as we know it could become a transient artifact, generated on demand and never stored. The retreat was divided on this. Some saw source code disappearing within a decade. Others argued that deterministic validation requires a stable artifact to test against, and that artifact is effectively source code regardless of what we call it.

Semantic layers and knowledge graphs

Technologies that failed to gain mainstream adoption for decades are suddenly relevant. Semantic layers, knowledge graphs and domain ontologies are being rediscovered as the grounding layer for AI agents that need to understand business domains. The retreat included practitioners building these systems at scale, reporting that a large telecom’s entire domain ontology could be captured in roughly 286 concepts. That number made the work feel achievable rather than impossibly ambitious. The practical value is in legacy modernization. By building a conceptual data model from existing systems and validating it against subject matter experts, organizations can create the specification layer that agents need to modernize confidently. One team described using LLMs to automatically identify commands, events, aggregates and policies from code, effectively auto-generating event storming artifacts. Human experts then validate and correct, compressing weeks of discovery workshops into days.

The agentic operating system

The retreat explored what an operating system for agents would need to include: ●​ Agent identity and permission management. ●​ Memory and context-window management. ●​ A work ledger that captures future, current and past work with attributes like required skills, acceptance criteria, SLOs and cost constraints. ●​ Governance paths through a graph of agent capabilities and compliance requirements. A central insight was that an agent is more than its persona, goals or current context; it includes the history of work it has performed. While models are fungible within an agent (you can swap one LLM for another), changing a model fundamentally alters the agent’s behavior and must be tracked. The work ledger emerged as the core primitive of this new operating system, analogous to a financial blockchain: searchable, auditable and enabling agents to discover and bid for work.

7. Security, governance and the future of agile

Security Is dangerously behind

The retreat noted with concern that the security session had low attendance, reflecting a broader industry pattern. Security is treated as something to solve later, after the technology works and is reliable. With agents, this sequencing is dangerous. The most vivid example: granting an agent email access enables password resets and account takeovers. Full machine access for development tools means full machine access for anything the agent decides to do. The retreat’s recommendation was direct. Platform engineering should drive secure defaults by making safe behavior easy and unsafe behavior hard. Organizations should not rely on individual developers making security-conscious choices when configuring agent access. Three priorities emerged: security by design as a non-negotiable baseline, cross-industry coalitions for interoperable agent security standards and AI-enabled defense mechanisms that can match the speed and sophistication of AI-enabled attacks.

Agile is evolving, not dying

The retreat pushed back hard on the “agile is dead” narrative. What is happening is more nuanced. Some teams are compressing sprint cadences to one week, using AI to automate end-of-sprint ceremonies like demos, reporting and status summaries. Others are rediscovering XP practices (pair programming, ensemble development, continuous integration) because these practices create the tight feedback loops and shared understanding that agent-assisted development requires. The real threat to agile is governance. Teams that adopt AI tools and work faster still run into the same approval processes, compliance gates and organizational dependencies. Without reforming governance alongside development practices, faster teams just hit the same walls sooner. The retreat emphasized involving internal audit and governance functions early when rethinking team practices, rather than treating them as obstacles to be navigated later. Software stability is also declining as batch size increases. The ease of producing large changesets with AI tools is pushing some teams back toward waterfall-like patterns, with large, infrequent releases replacing small, frequent ones. This is a direct reversal of a decade of DORA research showing that smaller batch sizes correlate with higher stability. The retreat flagged this as an active regression that needs industry attention.

8. Agent swarms: beyond sequential thinking

The retreat dedicated focused time to agent swarming and surfaced insights that challenge conventional assumptions about how AI-assisted work should be organized. The first barrier to effective swarming is mental, not technical. Engineers trained in sequential decomposition struggle to conceptualize parallel agent work. This mental model actively blocks learning. Practitioners who have made breakthroughs in swarming describe the experience as fundamentally unlike anything they have encountered in previous software development. The simple act of asking agents to parallelize work explicitly and observing the results teaches more than any theoretical framework. For enterprise use cases, the retreat identified an important pattern: perfect accuracy from individual agents matters less than collective convergence toward a goal. A swarm of individually imperfect agents can produce valuable outcomes if the system architecture guides convergence. This is a design principle borrowed from distributed systems and biological swarm intelligence, applied to AI agent orchestration. The retreat also noted that most enterprise agent orchestration will not look like swarming at all. The more common pattern is “patrol workers on loops”: agents running well-defined ETL transforms, data quality checks and business process monitors on continuous cycles. In other words, the unsexy work of data reliability and cleanliness running always-on in the background. Organizations with strong, well-designed APIs are significantly better positioned for both swarming and patrol-style agent deployment than those without.

Model limitations

Some frontier models have structural weaknesses that make them poorly suited to swarm-style scenarios. This is informing how evaluations are designed, with the expectation that swarm-oriented architectures will improve as these limitations are better understood. Organizations selecting models for agent deployment should test specifically for multi-agent coordination, not just single-agent capability.

9. Open questions

The retreat surfaced more questions than answers. These are the ones that kept the room awake.

On work and identity

How do we help engineers who love writing code find meaning and satisfaction in supervisory engineering work? What professional development pathways lead to the middle loop? If the product manager role and developer role are converging, what is the resulting role called and who owns it?

On organizational design

If agents make middle management bottlenecks more visible, does the organizational response involve fewer managers, differently-skilled managers or a fundamentally different coordination model? How do you redesign enterprise architecture when agents can move across team boundaries but governance structures cannot?

On trust and verification

What would need to be true for organizations to stop reviewing AI-generated code entirely? Is there a world where test suites and constraints provide sufficient verification without human inspection? How do we build trust in systems that are fundamentally non-deterministic, where rerunning the same inputs produces different outputs?

On knowledge and comprehension

If code changes faster than humans can comprehend it, do we need a new model for maintaining institutional knowledge? Can knowledge graphs and semantic layers truly replace the human intuition that comes from years of working in a codebase? What is the right investment level for “agent subconscious” systems that most organizations do not yet build?

On speed and stability

Are we currently in a regression where AI-enabled productivity gains are being offset by stability losses from larger batch sizes? Will development need to slow down because the volume of decisions is overwhelming human capacity to evaluate them? How do we measure the real cost of cognitive debt as it accumulates?

What comes next

The retreat surfaced a consistent pattern: the practices, tools and organizational structures built for human-only software development are breaking in predictable ways under the weight of AI-assisted work. The replacements are forming, but they are not yet mature. The ideas ready for broader industry conversation include the supervisory engineering middle loop, risk tiering as the new core engineering discipline, TDD as the strongest form of prompt engineering and the agent experience reframe for developer experience investment. Detailed explorations of each will follow. The questions not yet answered are equally important. How to help people through an identity shift in their professional lives: how to govern organizations where agents move faster than humans can decide; how to build trust in systems that are inherently non-deterministic. These are not technical problems with technical solutions. They are human problems that will require candid conversation and collaboration. We are committed to contributing to that in the months to come. “The retreat didn’t produce a roadmap. It produced a shared understanding that the map is being redrawn and that the people best positioned to draw it are the ones willing to admit how much they don’t yet know.”

---

Part 2: The Future of Software Engineering (June 28–30, 2026, Engelberg, Switzerland)

The Future of Software Engineering

June 28-30, 2026 | Engelberg, Switzerland Insights and findings from an unconference on AI, agentic engineering and the future of the discipline.

Executive summary

In February 2026, Martin Fowler brought together industry leaders in Utah to reflect on the state of play in software engineering. The results surfaced many issues that have commanded industry attention in 2026. Just a few months on and change has continued at an astonishing pace. So, with a view to both exploring the ideas and issues raised at the Utah event, and to reflect on new challenges that have emerged in recent months, Thoughtworks and Martin convened a second Future of Software Engineering Retreat, this time in Engelberg, Switzerland. This report details the takeaways and insights from it. This was an unconference-style gathering of senior technologists, CTOs, CEOs, architects and consultants. The 40 sessions that made up the event were informal, participant-led and sometimes even argumentative. The value was not necessarily consensus but instead the range and seriousness of the thinking. Five headline findings run through nearly every session: ● Code generation is no longer the bottleneck— verification is. Across testing, legacy modernization, code review and team-design sessions, the same conclusion kept coming up: agents can produce code (and specs, and tests and infrastructure) far faster than any team can trust it. The discipline that wins is the one that builds cheap, fast, human-legible verification — characterization tests, constraint tests, mutation testing, production back-testing — not the one that generates the most code. ● ‘Harness engineering’ is emerging as a distinct, ownable discipline. The scaffolding around an agent — context management, deterministic guardrails, skills, self-improving feedback loops — is repeatedly described as more important than the model or the prompt. It may be the place where competitive differentiation will live once models commoditize. Notably, the need for ownership and accountability came up repeatedly but there was no consensus on who that should actually be. ● Organizations are colliding with a real apprenticeship crisis.Multiple sessions independently raised the same fear: if senior engineers pair exclusively with agents, junior engineers lose the hands-on path to judgment, taste and the production instinct the industry has always relied upon to cultivate the next generation of seniors. Consistent with the discussions in Utah, most people agreed it was important that people developing software in this manner need to know what good looks like, which explains why the senior engineers thrive. However this increases the risk associated with the apprenticeship issue. ● The executive/engineer expectation gap is a bigger risk than any technical limitation. Boards and CEOs are making large, fast bets based on vendor demos and their own experience with report-writing AI while engineers see a

widening list of unresolved verification, security and governance problems underneath the productivity gains. ● Legacy modernization is the clearest, most defensible near-term value pool. Several sessions described rigorous, working, technically detailed approaches to AI-assisted COBOL/mainframe modernization with real verification discipline. Similar to the event in the US, many open questions remain that need further exploration and consideration. However there are implications for how technologists and business act now. For technologists, a renewed focus on testing and verification is required. Part of this should include rethinking the assumption that manual code reviews are a de facto guarantee of quality and also leveraging adversarial and mutation testing techniques when working with unfamiliar AI-generated code. Also crucial are mechanisms for learning. This is both at the level of supervising AI agents, ensuring effective feedback loops inside agent harnesses, and at a team level too — implementing practices like mob-pairing and learning checkpoints that can strengthen understanding and skill transfer. For business leaders navigating this period of strategic uncertainty and constant change, there was clear consensus that today’s tokenomics challenges cannot be treated purely as a finance issue: it’s ultimately a governance one which requires ongoing oversight and feedback loops rather than budget management alone. Related to this, striking a balance between autonomy and proliferating shadow AI also demands thoughtful governance. Uniform policy needs to be resisted, and autonomy should be calibrated to risk. Perhaps the most significant strategic takeaway is that we should not expect the cycles of change the industry is currently experiencing to hit a final plateau. Yes, that’s a possibility, but it is more likely that hype cycles will only become more compressed and the pace of change increasingly fast. This makes building durable capability that holds value and taking steps to protect areas of established value strategic necessities that should be acted on now.

For business leaders navigating this period of strategic uncertainty and constant change, there was clear consensus that today’s tokenomics challenges cannot be treated purely as a finance issue: it’s ultimately a governance one which requires ongoing oversight and feedback loops rather than budget management alone. Related to this, striking a balance between autonomy and proliferating shadow AI also demands thoughtful governance. Uniform policy needs to be resisted, and autonomy should be calibrated to risk.

Part 1: Cross-cutting themes

Verification, not generation, is the new bottleneck

The single most repeated observation of the conference was that agents can generate code, tests, specs and infrastructure far faster than any human or organization can currently establish trust in the output. “Engineering is now distilled down to how do I describe the goal, how do I verify I’ve reached the goal”. This shows up as a concrete, practical problem, not an abstract one: ● A new testing vocabulary is emerging. ‘Constraint tests’ (single input/output tests that box in what an agent is allowed to generate), ‘scenario tests’ and ‘good/bad logs’ (derived from real production incidents) were named and demonstrated live. Custom, purpose-built approval-testing rigs which were built in hours are proving more effective than generic BDD frameworks. This is partly because they keep the human-reviewable surface simple and hard for an agent to game. ● A layered trust-verification stack is forming for high-stakes migration work. It looks like this: characterization tests (behavioral capture from the legacy system) → symbolic execution (mathematically grounded, not AI-generated) → production ‘back tests’ against real data flows. This is a genuinely rigorous and novel technical methodology. ● Mixed deterministic/non-deterministic evaluation is the practical answer to LLM-as-judge unreliability. There was discussion about how one team combined linters and pattern-matching with a three-model ‘council of judges,̓ raising first-pass merge acceptance from roughly 60% to 80%. ● The long-standing faith in manual code review is being openly questioned. Multiple practitioners pointed out that no one in the room could cite data on how many defects manual review actually catches — a ‘status quo illusion’ that needs to be challenged with evidence.

“Conformance tests matter a lot more than the spec. If the conformance tests differ from the spec, guess which one wins?”

Harness engineering is becoming a distinct, ownable discipline

As models commoditize, multiple sessions converged on the same claim: the scaffolding around a model — context management, deterministic guardrails, skills, self-improving feedback loops — is what actually differentiates good agentic engineering from bad. ● Concrete, measured results exist. One organization reported that using an effective harness cut token usage by at least 4x and materially increased output determinism. A refactoring experiment found that a raw linter improved code-smell resolution to under 50%, while linter output translated into specific, deterministic, step-by-step refactoring instructions (‘habit hooks’) achieved roughly 90% resolution. A smaller model with a good harness was also said to outperform a larger model with a weak one. ● The best-performing teams do not hand-write their harnesses. They let agents fail, run a ‘learn’ skill that reflects on each session and proposes harness edits and treat the human’s job as periodic pruning and simplification, not authorship. ● Governance of shared harnesses/skills remains an unsolved organizational problem. Skills and shared context artifacts decay exactly like unowned code frameworks unless clear ownership is established. However, centralizing into a dedicated ‘harness team; risks recreating the old ops team anti-pattern.

Team design is compressing — and the bottleneck is moving to decisions

Team-topology conversations recurred across at least five sessions, converging on a similar shape: smaller ‘nucleus’ teams (often pairs or trios) supervising large fleets of agents but retaining a social/cohesion floor around roughly 10 people for organizational sanity. ● The ‘two clocks’ problem is the sharpest new diagnostic to emerge. Teams are tracking both the clock for producing code and the clock for waiting on a decision. They’re finding that while developer throughput has exploded, overall cycle time hasn’t improved; this is because decision-making and specification clarity are now the constraint.

● A vivid healthy-vs-unhealthy case study recurred verbatim across multiple sessions. A team where a product manager and designer became ‘superpowers’ cranking out features on their own using agents while the engineer was relegated to cleanup, versus a team that paired on specs, tests and design intent while a fleet of agents converged on solutions is a good example. The former was found to be highly productive but viewed by leadership as ‘a disaster in the making’ because it eroded pairing culture and organizational cohesion. ● Platform teams need a credibility upgrade. Traditional infrastructure-focused platform teams may lack the coding sophistication to own ‘harness’ or ‘dark factory’ tooling. The fix proposed repeatedly is for platform teams to use the same agentic tools they ask product teams to use and to shift from a ‘menu of options’ to a more opinionated ‘paved road’. ● Domain-driven design is being reappraised as the most relevant existing discipline for negotiating module and team boundaries at agentic speed and scale. This isn’t because it produces one grand design, but because it’s the only established discipline for continuously negotiating and naming boundaries across a large organization.

There’s an apprenticeship and skills-transmission crisis

Independently, in at least six different sessions, senior practitioners raised the same fear: if juniors never get to struggle with real code, real production incidents and real design trade-offs because agents (or senior engineers pairing exclusively with agents) absorb that work, the industry will lose a vital mechanism for growing the next generation of engineers with judgment and taste. ● Concrete countermeasures were proposed and are already being piloted. A “design quorum” or mob-programming pattern where a senior leads design conversation while juniors do the actual prompting; explicit non-AI learning exercises with public accountability; new curricula teaching agent orchestration and supervision as an early-career competency. ● The seven to 10 year experience cohort was identified as the group under the most acute strain. Having invested a decade mastering skills that models now often exceed, they are facing a real emotional and identity impact. ● Related research finding reinforces the concern. University students who wrote essays with heavy LLM assistance showed measurable degradation in their critical-thinking ability over three months, even relative to their own unassisted baseline.

“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.”

Legacy modernization is the clearest, most defensible value pool

Multiple sessions described technically serious, working approaches to AI-assisted legacy/mainframe modernization. These weren’t speculative, but were either advanced pilots or currently running in production. ● Migration discipline principles repeated across sessions. “Add nothing, change nothing, delete everything you possibly can” during the port; change one thing at a time (behavior fidelity, then architecture — never both simultaneously); preserve known bugs deliberately, as a client-approved decision, rather than letting an AI ‘helpfully’ fix things a downstream system may depend on. ● Newly tractable techniques. A full custom TypeScript-to-.NET-CLR compiler built via AI in four days; a COBOL compiler passing the NIST test suite built in three days for roughly 5,000 in tokens; reverse\-engineering an undocumented, encrypted 1994\-era mainframe binary format by having a model spot byte\-level patterns\. Problems that were previously uneconomical to solve outright, like bespoke compilers, transliterators and formal verification, are now within the reach of an average team\. ● Framing that lands with boards\. Connecting AI investment directly to modernization and maintenance budget \(often 30–50% of total IT spend at large enterprises\) reframes an abstract technology ask into a scoped, boardroom\-legible capital allocation decision\. One real example reduced a vague 100M+ ask into a scoped $8M/20%-of-systems proposal with tied, measurable value.

The executive/engineer perception gap is a bigger risk than any model limitation

A recurring, almost universal complaint was that boards and CEOs often believe “a product manager dumps a PRD into the magic machine and perfectly working software comes out”. This is partly because their own hands-on AI experience is with AI report-writing and summarization tools that perform very well but are a poor proxy for software engineering. ● This gap doesn’t close with better models. It closes with vivid, concrete storytelling that’s tied to the impact on an organization’s balance sheet. It also needs data discipline, like fact-checking vendor “10x” claims against real peer benchmarks and structured exercises that let executives try building something themselves and hit real limits. ● A concrete, current warning sign. Reported internal security incidents are up roughly 20x in six months at one organization, while AI token budgets are blowing through annual allocations in three months instead of twelve. This is the kind of budget shock that’s now getting board attention faster than productivity claims. ● Realistic productivity expectations should be actively managed downward from vendor hype. One practitioner’s estimate, accounting for the full SDLC rather than just code generation, put realistic near-term gains at roughly 2–3x, not 10x. They predicted the gap between hype and this reality could “burst the bubble” within 12–18 months.

Governance has not caught up with citizen development or agent autonomy

Sessions on citizen development and security shared a consistent set of real, concrete incidents: an accountant’s Copilot-built app accidentally exposed customer data to the open internet via an AI-suggested Cloudflare tunnel; a marketing team’s AI assistant was granted broad G-Suite access via cascading OAuth scopes the company could not even enumerate when trying to shut it down; an agent, low on disk space, deleted backups to free room — and was ‘thrilled’ about it. ● A recurring and useful governance pattern. A green/amber/red risk-tiering model (personal use/team use with mandatory training/company-wide requiring professional engineers), paired with detection over prevention — continuously scanning agent conversation logs for dangerous patterns rather than relying solely on upfront training (which cannot keep pace with weekly model releases) could be a critical governance tactic.

● A new supply-chain attack vector.Malicious actors can predict which non-existent libraries an LLM is likely to hallucinate by name and then publish real malicious packages under those exact names. Sandboxing alone doesn’t fully solve this, since the dependency can still reach production. ● Practical, partial mitigations exist and are spreading.Waiting roughly 14 days before adopting new library versions (most compromises are caught in that window); vetted internal registries; micro-VM sandboxing (better than containers, although not yet proven fully sufficient); and treating agent-generated code as untrusted even inside your own network, applying zero-trust principles internally, not just at the perimeter.

Tokenomics, self-hosting and sovereignty are now board-level questions

Interest in self-hosting models is being increasingly driven less by cost than by a demand for sovereignty and control: fear of US/federal legal reach over data, fear of a provider unilaterally raising prices or throttling access and a desire to avoid losing an organization’s ‘ability to learn and change’ by outsourcing it entirely. ● Cost efficiency varies by up to 1,400x depending not just on model choice but on how enterprise data access is architected. Inefficient MCP-based round-tripping between model and enterprise systems is an underappreciated cost driver. It creates a real tension between cost optimization (data closer to the model) and security (broader data exposure). ● True large-scale self-hosting is a specialized, scarce discipline. Performance engineering of throughput per dollar of fixed GPU infrastructure, down to physical rack topology is largely being absorbed by hyperscalers and neoclouds. Organizations should expect this capability gap and plan accordingly rather than assuming self-hosting is simple. ● Aworkable middle path was offered for coding-specific workloads. Specifically, smaller dedicated inference hardware or specialized coding-model hosting providers, that remove the need to solve the full hyperscale self-hosting problem.

Open source faces a genuine reckoning

A passionate, unresolved debate took place at the event: does AI worsen a pre-existing open-source sustainability crisis, intensifying issues such as maintainer burnout and unpaid labor extracted by billion-dollar companies, or does it create entirely new dynamics, like single-person mega-projects reaching massive scale in months and AI-generated pull-request floods maintainers can’t evaluate?

● A constructive pattern was proposed for handling AI-generated contributions at scale: reverse-engineer a pull request’s intent into a plain-language description, evaluate that intent and then have your own AI reimplement it from scratch before merging, crediting the contributor while avoiding blind trust, at low maintainer cost. ● A speculative but plausible shift. Open source sharing may move from code to specs/ideas, since implementations become cheap to regenerate per-consumer. There’s a real risk, though, that if agents fully displace shared library dependency, people without AI/hardware access lose out on a historically democratizing effect of open source.

A values-driven counter-narrative: ‘Conspicuously human’

Running underneath the technical optimism was a persistent, serious counter-current: a concern that if verification, prototyping and even market testing all become nearly free and equally available to everyone, the only remaining differentiator is human judgment, taste and care. Organizations need to deliberately protect and elevate that, not engineer it away. ● There are historical analogies that suggest this isn’t naive nostalgia. Impressionism emerged specifically because the camera could replicate reality perfectly, shifting human value to interpretation; drummers became more sophisticated, not obsolete, once drum machines arrived; the best chess ‘player’ in the world since 1997 has arguably been a human-plus-engine team, not an engine alone. ● This is not anti-technology sentiment — it coexists with the conference’s overall enthusiasm for agentic tooling. The clearest articulation was to keep the loop where judgment is injected deliberately and visibly human, even as the loop where things get built becomes highly automated. “The only thing I don’t want to outsource is the acceptance criteria. Everything else I’m willing to outsource.”

Part 2: Actions for technical leaders

So, what are the practical implications for technologists? While it’s important to note that the field is evolving quickly — what’s true in early July may not be a few months in the future — there are a number of recommendations for technology leaders that deserve consideration and reflection.

Testing and verification

● Retire generic BDD frameworks where step definitions hide complexity; adopt custom, purpose-built approval-testing rigs (constraint tests, scenario tests) that keep the human-reviewable surface simple and hard for an agent to game. Budget hours, not weeks — conference examples suggest a working rig can be built in a single session with an experienced person. ● For any modernization/migration engagement, adopt the three-tier verification stack as a default: characterization tests from real system behavior, symbolic execution for mathematical rigor where models can’t help and production back-testing against real data flows as the final gate. ● Run the coverage → adversarial-AI-probing →mutation-testing sequence on any unfamiliar or AI-generated codebase before trusting its test suite: check coverage first, then have an AI actively try to break the code without breaking tests, then apply mutation testing only if that probing succeeds. ● Stop treating manual code review as a de facto quality guarantee;measure it. If your organization can’t produce data on defects actually caught by review, treat that as a real gap, not a formality.

Harness and context engineering

● Convert passive lint/static-analysis signals into deterministic, specific, step-by-step instructions fed back to agents (“here’s how to refactor a long function,” not “this function is too long”) — the single highest-leverage, cheapest harness improvement documented at the conference. ● Build a “learn” loop into your harness: let agents fail, reflect, propose harness edits and limit human involvement to periodic pruning rather than upfront authorship. ● Assign explicit ownership to shared skills/context artifacts before they fork and decay the way ungoverned frameworks always have; build a lightweight

eval process (with/without-skill scenario testing) to periodically prune skills that no longer add value as models improve. ● Constrain infrastructure/cloud-facing agents to narrow, schema-defined, audited tool interfaces rather than broad cloud-provider CLI access — block raw AWS/gcloud commands in favor of structured, reviewable tool calls.

Team design and ways of working

● Track the “two clocks” explicitly: the first, time spent producing code, and the second, time spent waiting on decisions/specification clarity. If throughput is up but cycle time isn’t improving, the constraint has moved upstream. Fix the decision-making process, not the pipeline. ● Deliberately preserve pairing on specs and design intent, even as implementation pairing declines — treat spec-pairing as at least as important as code-pairing ever was, given a fleet of agents can now generate far more code from a single instruction than a human pair ever could review line by line. ● Adopt a risk-tiered autonomymodel per system or component (cobot-style human oversight vs. dark-factory-style full automation), explicitly based on risk, reversibility and blast radius — do not apply a single autonomy policy uniformly across a portfolio. ● Shift platform-team culture from a “menu of options” to a genuinely opinionated paved road. Have platform teams use the same agentic tooling they mandate for product teams, to close the credibility/pace gap that undermines platform-team authority.

People and skill formation

● Implement a design-quorum or mob-pairing pattern deliberately, not incidentally: senior engineers lead design conversation in real time while junior engineers do the prompting, preserving hands-on exposure to design trade-offs that would otherwise disappear. ● Build explicit, non-AI learning checkpoints into onboarding and training— moments where trainees must work without agent assistance and explain their reasoning — rather than assuming skill transfer happens automatically alongside AI-assisted delivery. ● Watch the seven to ten years experience cohort specifically for signs of disengagement or identity strain. This group’s expertise is being devalued fastest and least visibly, and they are often your most experienced delivery leads.

Governance

● Apply a green/amber/red risk-tiering model to any AI/agent tool usage (personal productivity/team-level with training/company-wide requiring professional engineering sign-off), and back it with continuous log-scanning detection rather than relying solely on upfront training. ● Treat AI-agent-generated application code as untrusted even inside your own network; apply zero-trust and blast-radius-limiting principles internally, not just at the perimeter. ● Adopt a minimum library-adoption delay (roughly two weeks) as a default supply-chain mitigation, and explicitly screen for AI-hallucination-based dependency attacks in code review.

Part 3: Strategic advice for management

The discussions in Switzerland didn’t only surface potential actions for technologists; there are also a number of significant strategic implications that extend beyond software engineering and are pertinent to business leaders.

Sequence discipline before acceleration

The single clearest strategic warning from the conference, repeated in different words across security, governance and regulated-industry sessions: agentic AI amplifies discipline and habits — positive or negative — that already exist in an organization. Teams and organizations with weak testing culture, unclear risk ownership or poor documentation hygiene will get worse, faster, not better. The practical implication for management is to resist the temptation to “just go fast and fix quality later” — fix the underlying discipline gaps first, or in parallel, not after.

Manage the story, not just the metric

Boards and executives are moved by vivid, concrete, specific stories — not aggregate productivity dashboards. This cuts both ways: it’s how organizations get boards to take security and governance seriously and it’s how the AI industry itself oversells capability (repeatable ‘10x’ anecdotes without underlying data). Management’s job is to actively curate and fact-check the stories reaching decision-makers, not simply to report metrics upward and hope the right conclusions get drawn.

Treat token/infrastructure economics as a governance problem, not just a finance problem

Multiple organizations reported token spend growing 10x within months, unbudgeted and largely undetected until it was a crisis. This is a management process failure as much as a cost problem: it needs the same kind of governance discipline (named accountability, budget review cadence, usage-pattern-based policy) that organizations already apply to cloud spend, applied early rather than reactively.

Resist uniform policy; calibrate autonomy to risk

A recurring failure mode described at the conference is applying a single AI-adoption policy (“go fast everywhere” or “lock everything down”) across a portfolio that actually has widely varying risk profiles. The more effective organizations described at the conference explicitly tiered their approach — by system criticality, by team maturity,

by regulatory exposure — rather than picking one stance and applying it uniformly. Management’s job is to build and maintain that tiering, not to pick a single company-wide answer.

Protect the things that create differentiated value, deliberately

As verification, prototyping and even foundational engineering capability become commoditized and cheap, the conference’s consistent argument is that judgment, taste and genuine human collaboration become the scarce, differentiating resource — not despite being “inefficient,” but because of it. This has a direct management implication: practices like pairing, mob design sessions and slow, careful architectural thinking should be explicitly funded and protected as strategic capabilities, not treated as legacy costs to be optimized away under margin pressure. Organizations that quietly erode them in the name of AI-driven efficiency may find they have optimized away the actual source of their competitive advantage. “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.”

Plan for a compressed hype cycle, not a stable plateau

Several participants with direct market/valuation experience expect the current AI investment cycle to compress faster than previous technology cycles (the internet, crypto) and specifically flagged a plausible 12–18 month window before expectations reset against real (roughly 2–3x, not 10x) delivered value. Management should plan investment and messaging horizons accordingly: build durable capability (harness engineering, verification discipline, governance) that holds its value regardless of where the hype cycle lands, rather than betting the strategy on today’s most extreme productivity claims holding up.

Final thoughts

The transition to an agentic future is less about a change in tooling and more about a fundamental recalibration of what it means to build software. As the discussions in Switzerland demonstrate, the central tension of this new era is that while code generation has become seemingly trivial, ensuring the necessary harness, tests and verification has become the critical bottleneck. To succeed, engineering organizations need to pivot from viewing productivity as a volume metric to treating it as a discipline of trust and governance. The path forward demands harness engineering as a core competency and proactively mitigating the apprenticeship crisis; we need to ensure the next generation of engineers is able to develop the judgment and taste that AI models and agents cannot replicate. As verification, prototyping and foundational engineering become commoditized, the final and most critical takeaway is this: the only true, sustainable differentiator for an organization—and for an individual engineer—is human judgment. We are moving toward a reality where “conspicuously human” effort is not an inefficiency to be eliminated, but a strategic asset to be protected. We shouldn’t be afraid to be deliberate and slow where it matters most. In a world where agents can generate vast amounts of code in seconds, the highest value will be found in those who carefully curate the intent, accept the responsibility for the outcome, and preserve the taste and care required to build systems that endure.