Technology Radar

An opinionated guide to today's technology landscape

The information in our interactive Radar is not available in your preferred language.

Thoughtworks Technology Radar is a twice-yearly snapshot of tools, techniques, platforms, languages and frameworks. This knowledge-sharing tool is based on our global teams’ experience and highlights things you may want to explore on your projects.

New
Moved in/out
No change

No blips

techniques platforms tools languages-and-frameworks .all-quadrants.js-enabled { display: none; }

Each insight we share is represented by a blip. Blips may be new to the latest Radar volume, or they can move rings as our recommendation has changed.

The rings are:

Adopt. Blips that we think you should seriously consider using.
Trial. Things we think are ready for use, but not as completely proven as those in the Adopt ring.
Assess. Things to look at closely, but not necessarily trial yet — unless you think they would be a particularly good fit for you.
Caution. The industry should consider alternative options or even proactively avoid these things. We’ve had negative experiences that have impacted our work.

Explore the interactive version by quadrant, or download the PDF to read the Radar in full. If you want to learn more about the Radar, how to use it or how it’s built, check out the FAQ.

Download the PDF

English | Português

Sign up for the Technology Radar newsletter

Subscribe now

Themes for this volume

For each volume of the Technology Radar, we look for patterns emerging in the blips that we discuss. Those patterns form the basis of our themes.

The challenge of evaluating technology in an agentic world

AI is changing not only technology but also how we assess and evaluate it. While assembling this volume of the Technology Radar, we noticed that evaluating technology is becoming harder as the industry adopts AI. One contributing factor is semantic diffusion: the rapid emergence of new terms for evolving practices, often before their meanings have stabilized. For example, terms such as spec-driven development and harness engineering are sometimes used inconsistently or overlap in meaning. Without shared definitions, it’s difficult to determine whether we’re seeing distinct techniques or simply different labels for similar ideas. Distinguishing between a mature, standalone engineering methodology with clear guardrails from the everyday use of AI tools such as coding assistants is an ongoing difficulty.

The challenge extends beyond semantics. The pace of change compounds this uncertainty. We encountered several tools that were less than a month old — some promising, but ultimately too young to assess. In many cases, these tools were maintained by a single contributor working with a coding agent. AI has lowered the barrier to building developer tooling, creating a constant stream of new tools. This stretches the traditional rhythm of the Radar: if we allow tools time to mature, our guidance risks becoming outdated; if we move too quickly, we risk highlighting trends that disappear just as fast. It also raises questions about sustainability: when something can be created quickly and with relatively little effort, what ensures continued investment in maintaining and evolving it?

This environment also risks creating codebase cognitive debt. As more code is generated by AI, it’s easier to adopt solutions without developing the mental models needed to understand how they work. Over time, this gap in understanding accumulates, making systems harder to reason about, debug and evolve.

Retaining principles, relinquishing patterns

An interesting consequence of AI in software development is that it’s not only forcing us to look to the future; it’s also pushing us to revisit the foundations of our craft. While assembling this edition, we found ourselves returning to many established techniques, from pair programming to zero trust architecture, and from mutation testing to DORA metrics. We also revisited core principles of software craftsmanship, such as clean code, deliberate design, testability and accessibility as a first-class concern. This is not nostalgia, but a necessary counterweight to the speed at which AI tools can generate complexity. We also observed a resurgence of the command line: After years of abstracting it away in the name of usability, agentic tools are bringing developers back to the terminal as a primary interface.

That said, this is not a story of continuity alone. AI-assisted software development represents a fundamental shift in engineering practice, requiring us to rethink — and in some cases discard — long-held assumptions. In particular, how we collaborate and structure teams will need to evolve as we better understand what is possible with agentic systems. We may need to consider agent topologies alongside team topologies, and rethink feedback cycles accordingly. Several techniques in this edition reflect this shift. For example, measuring collaboration quality with coding agents points toward a broader redefinition of what it means to be a software developer. Ultimately, we’re likely only at the beginning of a deeper transformation in how we build, understand and interact with software systems.

At the heart of this is the challenge of managing cognitive debt in an AI-driven environment. We must retain the principles of good software engineering without allowing AI tools to amplify complexity or accelerate decision fatigue. Our craftsmanship tradition has long held that speed without discipline compounds cost — a principle worth holding onto as agentic systems make it easier than ever to move quickly and understand what we’ve built.

Securing permission-hungry agents

"Permission hungry" describes the bind at the heart of the current agent moment: the agents worth building are the ones that need access to everything. OpenClaw and Claude Cowork supervise real work tasks; Gas Town coordinates agent swarms across entire codebases. These agents require broad access to private data, external communication and real systems — each arguing that the payoff justifies it.

However, like a skier who's just learned to turn and confidently points themselves at the hardest black run, the safeguards haven't caught up with that ambition. The appetite for access collides with unsolved problems. Prompt injection means models still can't reliably distinguish trusted instructions from untrusted input. Simon Willison's "lethal trifecta" definition of an unsafe agent — private data, untrusted content, external action — now describes most useful agents by default, not by misconfiguration. Injection isn't the only threat. Model behavior is still inconsistent: a task completed successfully once offers no guarantee it will succeed the next time, let alone at scale. Agents find creative exfiltration paths, push to branches they shouldn't touch and erode approve/deny chokepoints without any malicious intent or explicit prompting.

What can we do today? Zero trust, least privilege, model improvements and defense in depth are now table stakes, but there is no silver bullet. We expect safe agent systems to be composed not of monolithic agents, but of pipelines of more constrained agents, with strong monitoring and control. Emerging practices such as Agent Skills as a controlled alternative to MCP, durable agents and techniques to prevent agent instruction bloat all point in this direction. The space is evolving rapidly, which is exciting — but for now, caution is essential to avoid a costly misstep.

Putting coding agents on a leash

As coding agents become more capable and produce better results, humans are increasingly being tempted to step out of the loop. To mitigate the risks of reduced human supervision, teams are beginning to invest in coding agent harnesses: controls that guide agents’ behavior before code is generated and provide feedback afterwards to enable self-correction.

Feedforward controls anticipate what the agent needs to increase the likelihood of a correct first attempt. Agent Skills have been a major recent advancement, helping modularize instructions and conventions, and load them just in time. Superpowers is an example of a catalog of useful skills for software teams, and the emerging concept of plugin marketplaces is making it easier to distribute skills and other context configurations. Our teams have also seen value in spec-driven development frameworks such as GitHub Spec-Kit and OpenSpec, which structure workflows and guide agents through planning, design and implementation.

Feedback controls, by contrast, observe behavior after the agent acts and create a loop for self-correction. This approach is captured by feedback sensors for coding agents: deterministic quality gates — compilers, linters, type checkers and test suites — integrated directly into agent workflows so failures trigger auto-correction before human review. Examples from this Radar include cargo-mutants and other mutation testing tools, fuzz testing tools such as WuppieFuzz and code quality analysis tools such as CodeScene. Beyond in-loop feedback, some of our teams have also reduced architectural drift by combining deterministic structural rules with LLM-based evaluation.