Technology Radar, Volume 34

Thoughtworks (Technology Advisory Board) · pdf · 2026-04-14 source ↗ Reader 🖥️

practical · expository — An opinionated, graded catalog (Adopt/Trial/Assess/Caution) of ~120 techniques, platforms, tools and languages, framed by a short thematic essay. Each entry argues for a specific stance toward adoption; the themes essay is the closest thing to an overall thesis.

Structure

Key terms

• Blip
  A named technology, technique, platform or tool the Radar tracks; blips move between rings over successive editions as confidence changes.
• Rings (Adopt / Trial / Assess / Caution)
  A graded recommendation strength: Adopt = should be standard practice now; Trial = worth building the capability on a risk-tolerant project; Assess = worth understanding its implications; Caution = proceed carefully, real concerns outweigh current benefits.
• Semantic diffusion Agile & XP
  The rapid emergence of new terms (e.g. 'spec-driven development', 'harness engineering') for evolving practices before their meanings stabilize, making it hard to tell whether two labels name distinct techniques or the same one.
• Codebase cognitive debt
  The growing gap between a system's implementation and a team's shared understanding of how and why it works, worsened by AI-accelerated change velocity and multiple contributors (including agent swarms).
• Permission-hungry agents
  The class of agents (e.g. OpenClaw, Claude Cowork, Gas Town-style swarms) whose usefulness is proportional to how much access to private data, external communication and real systems they are granted — making them structurally prone to the 'lethal trifecta' of unsafe agent design.
• Agent topologies (vs. team topologies) Sociotechnical Architecture
  The shape and coordination structure of a group of collaborating agents (orchestrator + role-specific sub-agents, or swarms of many agents) — argued to need to be considered alongside human team topologies, not as a separate concern.
• Harness / harness engineering
  The controls (feedforward — shared instructions, skills, spec-driven frameworks — and feedback — linters, tests, mutation testing, LLM-based architecture checks) built around a coding agent to guide its behavior before it acts and correct it after.

Propositions

• explicitAI is making technology evaluation itself harder, not just technology adoption, because semantic diffusion (overlapping new terms like 'spec-driven development' and 'harness engineering') and extremely short tool half-lives (some tools under a month old, built by one person with a coding agent) outpace the normal maturation cycle a radar relies on.conf: high
• explicitAI-generated tooling lowers the barrier to building developer tools so far that it raises a sustainability question: when something can be created quickly and cheaply, what ensures continued investment in maintaining and evolving it?conf: high
• explicitRetaining craftsmanship principles (clean code, deliberate design, testability, accessibility) is not nostalgia but a necessary counterweight to the speed at which AI tools can generate complexity.conf: high
• explicitdevelopedTeams must rethink how they collaborate and structure themselves for agentic systems — considering agent topologies alongside existing team topologies and rethinking feedback cycles accordingly.conf: high
  extends ←Team Topologies: Organizing Business and Technology Teams for Fast Flow · p5 — This book originates and defines the 'team topologies' taxonomy that the Radar's call to consider 'agent topologies alongside team topologies' explicitly references and builds on, without itself addressing agents.
  extends ←Technology Radar: An opinionated guide to today's technology landscape (Volume 30) · p7 — Vol 30's early, single-case 'AI team assistants' idea (team-shared prompts/knowledge beyond individual tool adoption) is the direct ancestor of Vol 34's broader claim that teams must rethink collaboration structure and agent topologies for the agentic era.
• explicitThe agents organizations most want to build are exactly the ones that need broad access to private data, external communication and real systems ('permission-hungry'), and the safeguards for that access have not caught up with the ambition to grant it.conf: high
• explicitSimon Willison's 'lethal trifecta' (private data + untrusted content + external action) now describes most useful agents by default, not as a misconfiguration — meaning unsafe-by-default is the normal case, not the exception, for agents worth building.conf: high
• explicitSafe agent systems will likely be composed of pipelines of multiple constrained agents with strong monitoring, not monolithic highly-privileged agents.conf: medium
• explicitA deliberate, small team of coding agents (an orchestrator plus a few role-specific agents, e.g. reviewers or backend/frontend implementers) is a meaningfully different — and currently more mature — approach than a large agent swarm (dozens to hundreds of agents with AI-determined composition), despite industry tendency to conflate the two terms.conf: high
  supportsThe Conductor Developer · p3 — Laycock (Thoughtworks CTO, same TAB this Radar edition reports to) independently describes developers orchestrating multiple agents; the Radar's 'team of coding agents' blip gives that orchestration a concrete, role-specific shape.
• explicitCoding agent swarm experiments that succeeded (Anthropic's C compiler, Cursor's week-long browser build) relied on unusually well-specified problems with clear automated verification (comprehensive test suites); this is not representative of typical product development where requirements are underspecified and verification is harder, so swarms remain costly and immature for most real work.conf: high
• explicitcorroboratedMeasuring AI-assisted development success by coding throughput alone (lines of code, PR counts) in isolation negatively shapes developer behavior, producing a flood of poorly-reviewed code that slows reviews, harms delivery, and introduces security risk; first-pass acceptance rate is a more meaningful leading indicator because it exposes the hidden rework cost and connects directly to DORA's change failure rate and lead time.conf: high
  supportsPatterns for Reducing Friction in AI-Assisted Development · p6 — Both identify first-pass acceptance rate as the metric that connects AI-coding behavior to DORA's change failure rate; the Radar generalizes Garg's specific claim into a named technique ('measuring collaboration quality with coding agents').
  supports ←AI doesn't create great developers, it amplifies them · p8 — Both make the same methodological warning: measuring AI-assisted development success by raw output metrics (lines of code, commits, PR counts) in isolation is misleading and can itself distort behavior, rather than revealing AI's true causal contribution.
• explicitDORA's five delivery metrics (lead time, deployment frequency, MTTR, change failure rate, and the newer rework rate) matter more, not less, in the AI era, because faster code generation only counts as improvement if it shows up in delivery flow and stability — a degrading rework rate is an early warning sign of AI-driven technical debt.conf: high
• explicitContext files (CLAUDE.md, AGENTS.md) accumulate rules over time into 'agent instruction bloat': instructions grow long, start conflicting, and models attend less to content buried mid-context, so adding more rules can make an agent less reliable, not more — and hand-written instruction files tend to outperform LLM-generated ones.conf: high
• explicitIgnoring durability (crash recovery, resumable state) in long-running or multi-day agent workflows is an anti-pattern that works in development but fails in production, because LLM/tool calls fail for ordinary distributed-systems reasons (network blips, server crashes) and a reactive, non-resumable design compounds that fragility at agent timescales.conf: high
• explicitReaching for MCP as the default integration layer between agents and systems is often the wrong call: a well-designed CLI with structured output frequently gives an agent everything it needs without the 'abstraction tax' of an added protocol layer, and MCP should be reserved for cases that actually need protocol-level interoperability, OAuth boundaries or governed multi-tenant access.conf: high
  extendsAI coding creates two kinds of debt. You're only measuring one · p1 — The Radar's 'codebase cognitive debt' blip names the same concept (gap between implementation and shared understanding) and adds the AI-swarm-specific acceleration mechanism and three candidate countermeasures that the two-kinds-of-debt piece does not offer.
• implicitCodebase cognitive debt and agent-accelerated change velocity reinforce each other in a vicious loop: weaker shared understanding of a system reduces developers' ability to steer agents effectively, which in turn produces more code nobody fully understands.conf: high
• explicitTreating curated, shared AI instructions (CLAUDE.md/AGENTS.md anchored into service templates, or a live reference application as source of truth) as a collaborative team engineering asset — rather than something each developer writes ad hoc — is now the more mature practice than individual prompt libraries.conf: high

Arguments

Narratives

• A Thoughtworks team built 'temporal fakes' — stateful, time-evolving simulators of GPU data-center hardware (NVIDIA DCGM, InfiniBand fabric) — to let a coding agent inject faults like thermal throttling and verify that observability dashboards and alerts fired correctly, without needing to procure or damage real hardware.
  → Supports the proposition that agentic coding lowers the cost of building high-fidelity test infrastructure, but also implicitly supports the durability/feedback-sensor themes: it is an example of engineering a trustworthy feedback loop for an agent rather than trusting the agent's own report of success.
• Two closely-watched coding-agent-swarm experiments (Anthropic's C compiler, Cursor's week-long from-scratch browser build) both succeeded, but both relied on unusually well-specified problems with comprehensive automated test suites as ground truth.
  → Implicitly supports the caution on 'coding agent swarms': the narrative shows swarms working, but the conditions under which they worked are precisely the conditions absent from typical underspecified product development, undercutting any inference that swarms are broadly production-ready.

Questions addressed

• ⭕ How should a team evaluate and adopt AI coding tools when the tools themselves are changing faster than any evaluation cycle can keep up with?
  The Radar names the problem (semantic diffusion, short tool half-life, single-maintainer tools) explicitly but offers no resolution beyond 'proceed with caution' and favoring durable principles over specific tools.
• ✅ How should teams measure whether AI-assisted development is actually improving delivery, rather than just producing more code faster?
  Shift from throughput metrics to DORA metrics plus first-pass acceptance rate / collaboration-quality metrics (iteration cycles, post-merge rework, review burden).
• ⭕ How should team structure change as coding agents move from single-agent assistants to teams/swarms of agents?
  The Radar raises 'agent topologies alongside team topologies' as a needed rethink but does not propose a concrete model for how human team structure and agent topology should map onto each other.

Gaps

• incompleteThe Radar explicitly flags that 'how we collaborate and structure teams will need to evolve' and that 'agent topologies' should be considered 'alongside team topologies,' but offers no concrete model, pattern, or case study for what a reconciled human-team + agent-topology structure actually looks like — it names the gap without filling it.
  Read next: Look for a dedicated treatment of team/agent topology mapping — e.g. an update to Team Topologies itself, or practitioner case studies of teams that have explicitly redesigned their org structure (not just tooling) around agent orchestration roles.
• incomplete'Codebase cognitive debt' is diagnosed with real specificity (the reinforcing loop between change velocity and shrinking shared understanding) and three named countermeasures (feedback sensors, tracking team cognitive load, architectural fitness functions) are listed, but none is elaborated into a concrete method — there is no worked example of how a team would actually measure or 'pay down' cognitive debt in practice.
  Read next: See extract-fowler-fragments-february-13#g2 and extract-ai-coding-two-kinds-debt, which raise the same measurement gap from a different angle; a concrete practitioner writeup of 'tracking team cognitive load' in production would close both.
• uninformedThe document is an industry-wide, cross-client synthesis produced by a 22-person advisory board; it does not — and structurally cannot — speak to how any of these recommendations play out inside a specific team's existing culture, legacy codebase, or organizational politics. Every blip is stated as a general recommendation, not a contingent one.
  Read next: Pair with team-level case studies or first-person practitioner accounts (e.g. this corpus's own harness-engineering and agent-config-decay extractions) to ground the Radar's generalizations in a specific team's experience.

Closes gaps elsewhere

• Fragments: February 13 · g2 — The Radar's 'codebase cognitive debt' blip supplies the missing 'method for detecting, measuring, or paying it down' that the gap asked for — naming feedback sensors for coding agents, tracking team cognitive load, and architectural fitness functions as concrete countermeasures — though still short of a worked, measurable procedure.

Related documents

• The Conductor Developer
• Just Talk To It - the no-bs Way of Agentic Engineering
  Agent Config Decay Agent Harness Agent Security MCP (Model Context Protocol)
• Claude Code: Best practices for agentic coding
  Agent Harness Feedback Loops MCP (Model Context Protocol) Multi-Agent Orchestration
• The Future Of Software Engineering
  Agent Security Cognitive Debt Sociotechnical Architecture Team Topologies
• The 8 software engineering metrics AI broke
  Cognitive Debt DORA & Engineering Metrics Measuring AI Impact
• Agentic AI and Code Reviews
  Agent Security Feedback Loops Multi-Agent Orchestration
• Agentic Code Review
  Agent Security Cognitive Debt Measuring AI Impact
• AI coding creates two kinds of debt. You're only measuring one
  Cognitive Debt DORA & Engineering Metrics Measuring AI Impact
• AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy
  Cognitive Debt Feedback Loops Measuring AI Impact
• The Anatomy of an Agent Harness
  Agent Harness Feedback Loops Multi-Agent Orchestration