Interviewing Thoughtworks' Radar in the Age of AI.

One of the reference sources I rely on to get my bearings on technology and the industry is the Thoughtworks Radar.

It's a well-known document. Obviously, its content isn't set in stone and it doesn't have the context of the Spanish market as such, but it does provide an overview of the state of the art and its trend, since if you follow it across its different volumes, you can see how the concepts it includes evolve.

I believe that at this moment of brutal change and uncertainty in the industry, consulting documents of this type and quality is of vital importance to know what is becoming a proven reality and what should be taken with caution.

The knowledge source: the Thoughtworks Radar

As I mentioned in the introduction, the Thoughtworks Radar is well known. You've probably checked it out more than once, but if not, I encourage you to do so because I find it very interesting, especially in these times of so much change and uncertainty.

Roughly every six months, they publish a volume with what they consider relevant. The volumes are extensive, detailed documents, about 45-50 pages each, organized around four fundamental pillars:

• Techniques
• Platforms
• Tools
• Languages and frameworks

For each pillar, a series of "interesting things or items" ("blips" in their terminology) are analyzed and classified into four levels:

• Adopt: the industry should adopt these items. They are items already consolidated in the sector.
• Trial: worth trying because it's important to understand how to develop these capabilities. Companies should test this technology on projects where the risk can be managed.
• Assess: worth exploring these items with the goal of understanding how they will affect the company.
• Hold: proceed with caution when implementing them.

What's really interesting isn't so much which blips are in each block, but the trend: which blips appear, which ones are "promoted" to trial or adopt, and which ones need to be treated with caution, either because their maturity indicates so or because risks or shortcomings have been detected that need to be taken into account.

The medium for the interview: an advanced RAG

As could hardly be otherwise these days, I relied on AI to conduct the interview, but not in the way you might initially think, using ChatGPT, Gemini, NotebookLM, or similar to analyze the radar and issue conclusions, but instead building a system that I tried to give as "human" a way of thinking as possible so that this would feel like a real interview.

The system is based on a 100% serverless architecture on AWS (Cloudfront, API Gateway, Lambda, Bedrock, Opensearch, DynamoDB, S3), which can be spun up and torn down via IaC.

The "core" basically consists of an advanced RAG with hybrid search (BM25 + vector embeddings) over a series of indexed sources (hierarchical chunking) in an AWS Bedrock Knowledge Base on Opensearch.

When a question is asked, the most relevant fragments of the corpus are retrieved and injected into the model's context together with a cumulative summary of the conversation (automatically generated by a lightweight model after each turn and persisted in DynamoDB), thereby maintaining the thread of the interview without relying on the model's native memory.

To try to give the system "a certain human behavior" and make it feel like a real interview, the system prompt is designed so that it acts as a person who works on producing the radar, a member of the Thoughtworks Technology Advisory Board (TAB), who is being interviewed.

For this PoC I decided to set the knowledge base within a roughly two-year time range, analyzing the last four volumes:

• 📊 Volume 31 (October 2024)
• 📊 Volume 32 (April 2025)
• 📊 Volume 33 (November 2025)
• 📊 Volume 34 (April 2026)

The UI, to which I tried to give a journalistic editorial style, allows you to configure both the most important query parameters (model, tokens, retrieved fragments, or even the system prompt) and to explore the radar by ring, quadrant, and edition.

It also allows you to export the full transcript as a PDF in a two-column newspaper-style format. At the end of the session, if needed, a second model generates a structured executive report (summary, key themes, trends, and recommendations) based exclusively on what was discussed during the interview.

I won't go into much more detail about the project in this article because that's not its purpose (the purpose is the interview itself), and I'll publish a more technical article soon with all the details.

Now, the interview

Now that I've laid out the context in which the interview takes place, let's move on to conducting it and asking the questions. I have to say that, in my opinion, it produced some very significant insights:

• Hello, let's begin this long-awaited interview. Let's start with the first question. This year, 2026, has been a dizzying one in terms of technology's impact, but from your point of view, how would you describe the evolution of the tech industry over the last few years, up to this current point?

Good question to kick things off. If I had to sum it up in one sentence: we've gone from enthusiastic experimentation to responsible engineering, but with a lot of noise along the way.

What we've observed across the last few editions of the Radar is an unprecedented acceleration, but with a recognizable pattern. Every technology cycle follows a similar curve: euphoria, saturation, and then — if the technology has real value — consolidation. With generative AI we've lived through that curve in fast-forward.

Three or four years ago, the debate was whether LLMs were anything more than a sophisticated toy. Then came the explosion of the ecosystem — RAG, vector databases, guardrails, agent frameworks — which in the 2024 Radar we already described as a "Cambrian explosion." It was chaotic, but it made sense: the initial simplicity of the text prompt was giving way to real software engineering.

This is the point we most want to emphasize: technology matures when it stops being magic and becomes discipline. And that's exactly what we're seeing now in 2026 with agents, with context engineering, with LLM evaluation patterns.

But we've also seen what didn't work as expected. We were initially optimistic about full autonomy for coding agents, and we've had to be honest: the supervised approach is still essential. Complacency with AI-generated code is a real, documented antipattern, backed by data.

One of the patterns we keep seeing is that the speed of the tools outpaces the maturity of the practices. And that has a cost: cognitive debt, AI-accelerated shadow IT, architectures that drift out of control.

The industry is in an exciting moment, but engineering fundamentals — testing, observability, architectural design — have never been more relevant than they are now.

• I find it very interesting what you said about "engineering fundamentals having never been more relevant than now." Why are they a key piece now? Haven't they always been?

Yes, they always have been. But there's a crucial difference between something being important and its absence being immediately catastrophic.

Before, if a team had low test coverage or a mediocre architecture, the damage accumulated slowly. There was friction, technical debt, but the system degraded gradually and visibly. Now, with coding agents generating massive changesets in minutes, that same lack of discipline can destroy a system's coherence within hours. Speed amplifies everything, the good and the bad.

This is where things get interesting. What we're documenting in the Radar as codebase cognitive debt isn't simply traditional technical debt. It's something more subtle and more dangerous: it's the loss of the collective mental model of how the system works. When the code is generated by AI and no one reviews it in depth, the team starts operating on a black box that they themselves built without understanding it. The GitClear data is fairly telling on this: more duplicated code, more churn, less refactoring.

And here's the paradox that worries us most: coding agents work best on well-structured, well-tested codebases with clean design. In other words, the practices that some teams were tempted to relax because "the AI will fix it" are exactly the ones that make the AI work well. Good design for humans is also good design for agents.

That's why in the latest Radar we put things like DORA metrics, context engineering, zero trust, and OpenTelemetry in Adopt. They're not new. They're reminders that without that foundation, the speed AI promises turns into compound debt.

What has changed isn't the importance of the fundamentals. It's the cost of ignoring them.

• Looking at how things have evolved over the last few years, what points do you consider key for the adoption of AI to be a success today in a company?

The first thing I'd say is that the most common failure we see isn't technical. It's organizational. Companies that are failing with AI don't fail because they chose the wrong model or the wrong framework. They fail because they tried to layer AI on top of a foundation that was already fragile.

That said, there are several patterns we've documented as critical.

First, treating context as an engineering asset, not an implementation detail. Context engineering is in Adopt in the latest Radar precisely because we've seen that organizations that do it well — that design context as a dynamic, managed pipeline — get qualitatively different results. Those that ignore it end up with agents hallucinating or behaving inconsistently.

Second, invest in feedback signals before scaling. DORA metrics in Adopt isn't nostalgia. It's a reminder that if you don't measure lead time, deployment frequency, and rework rate, you won't know whether AI is generating real value or just more code. And rework rate specifically is the canary in the coal mine for detecting accumulated cognitive debt.

Third, govern agents from the start. Zero trust architecture in Adopt for agents isn't optional. The "lethal trifecta" that Simon Willison describes — private data, untrusted content, external action — describes most useful agents by default. If you don't have least privilege and continuous monitoring from day one, you're building on sand.

And fourth, and this is perhaps the most counterintuitive part: the most successful companies are the ones that first invest in cleaning up their codebase and their engineering practices, and only afterward bring in agents. Not the other way around.

What we repeatedly observe is that AI amplifies whatever already exists. If you have discipline, it amplifies that. If you have chaos, it amplifies that too. And at a speed that leaves no time to react.

• In terms of technologies, over these last few years, which ones have fully settled in and which ones have fallen by the wayside or are fading out?

This is a question I love because the movement between rings is where you really see whether something has substance or was just noise.

The ones that have truly settled in:

OpenTelemetry is perhaps the cleanest example. It moved from Assess to Adopt almost inevitably, because it solved a real problem — observability fragmentation — with the right abstraction. When Datadog, New Relic, and Grafana all adopt the same protocol, you know something has won. That's not hype, that's genuine consolidation.

RAG — Retrieval-Augmented Generation — reached Adopt in record time. What surprised us wasn't the speed, but that the technique survived the scrutiny of production. It keeps evolving — GraphRAG, Corrective RAG, Self-RAG — but the core pattern held up.

And in tooling, things like Renovate or Vite: no glamour, no keynote talks, but in Adopt because they simply work and teams don't want to live without them.

The ones that are fading out or never took off:

SAFe is still in Hold, and with every edition the language gets harsher. It's not that it isn't used — it's used too much — but we still aren't seeing the results it promises.

Local coding assistants is an interesting case: they arrived with a lot of expectation for privacy reasons, but we put them in Hold because local models simply don't compete with cloud-based ones in agentic capabilities. Technical reality beat organizational desire.

And the most telling one: "Replacing pair programming with AI" in Hold. This is almost a statement of principle on our part. Not because AI doesn't help, but because it confuses individual speed with team health. Those are different things.

The pattern I see: what settles in solves real friction with durable abstractions. What fades out is usually either a solution looking for a problem, or a local optimization that ignores systemic consequences.

• What do you think are the main risks or antipatterns that have been detected over the last few years and that can do a lot of damage if no action is taken?

This is perhaps the most important question we can ask ourselves right now, because we're at a point where the speed of adoption clearly outpaces the speed of understanding the consequences.

The first and most dangerous one: complacency with AI-generated code. It's not new — we've had it in Hold for several volumes now — but it's getting worse. What used to be a developer reviewing Copilot suggestions is now an agent modifying dozens of files in parallel while the developer supervises at a high level. The risk of automation bias multiplies exponentially. And what you get isn't bad code — it's code that works but that no one fully understands. That leads us directly to the second antipattern.

Codebase cognitive debt. We recently introduced this term into Caution, and I think it's one of the most important concepts we've articulated in years. It's not classic technical debt — it's the gap between what the system does and what the team understands it does. With agents generating changes at high speed, that gap silently widens until one day a small change breaks something unexpected, and no one knows why.

Third: MCP by default. We explicitly put this in Caution. The pattern we see is: "I have an API, I turn it into an MCP server, done." Without thinking about the security model, without analyzing toxic flows, without asking whether you really need MCP or whether a CLI script solves the problem just as well. The naive conversion of APIs into MCP is an attack surface that most organizations aren't managing.

And fourth, one that worries me especially at the organizational level: AI-accelerated shadow IT. Non-coders building agentic workflows that process sensitive data, with no governance, no audit trail, without IT even knowing. The difference from classic shadow IT is the scale and the speed. What used to take months to become a critical problem now takes weeks.

The common pattern across all these antipatterns is the same: AI amplifies speed before the organization has built the necessary control mechanisms. And when something fails, it fails fast and at scale.

• I find these points very interesting, especially when there's talk of the disappearance of the developer role. And yet, you're detecting many risks associated with automatically generating most of the code without review, increasing technical debt. How does this really affect the developer role? Will this role end up disappearing, or will it become more important than it is now?

The narrative that "the programmer is going to disappear" is, frankly, one of the most irresponsible ones circulating right now. And I say that with conviction because the data we see in the Radar points in exactly the opposite direction.

What we're observing is a transformation of the role, not its extinction. And that transformation makes it, if anything, more critical and harder to do well.

Think of it this way: when an agent generates hundreds of lines of code in seconds, who decides whether that solution is architecturally correct? Who catches that the agent solved the problem with thirty nested conditionals instead of applying the Strategy pattern? Who understands the hidden coupling that change introduces? That requires more technical judgment, not less.

What does disappear — and this is important — is the developer who only knows how to write mechanical code, without understanding design, without understanding systems, without understanding trade-offs. That profile was already declining before AI. What's emerging is a developer who acts more like a systems engineer and technical director of agents: someone who knows how to specify intent precisely, who can evaluate output at a high level, who maintains the mental model of the whole system.

And here's the paradox that concerns us deeply: AI is lowering the barrier to entry at the same time as it's raising the bar for what it means to do it well. That creates an enormous gap. You'll have more people generating code, but fewer people capable of understanding what's been generated. And that gap is exactly what feeds the codebase cognitive debt we mentioned earlier.

**What the Radar consistently reinforces — pair programming, TDD, fitness functions, rigorous code review — aren't relics of the past. They're the mechanisms that let a team maintain collective understanding of the system while the speed of generation skyrockets.

The developer role doesn't disappear. It forks: those who deeply understand systems become exponentially more valuable; those who delegated that understanding to AI become dispensable. AI doesn't eliminate the need for technical judgment. It makes it more expensive when it's missing.

• On another note, you also mentioned "MCP by default," and I find that very interesting since there was, or still is, a boom around this concept, with MCPs popping up out of nowhere. What real risks does it carry to overuse this concept or use it when it's not really needed?

The MCP boom is a textbook case of what happens when a technology solves a real problem but the industry overextends it until it becomes a hammer looking for nails.

MCP has genuine value. When you need structured tool contracts, OAuth authentication boundaries, and governed multi-tenant access, it's the right solution. The problem is that we're seeing teams and vendors use it as a default integration layer, even when a well-designed CLI with decent --help output and structured JSON responses would achieve exactly the same thing without the protocol overhead.

The first real risk is what we call the "abstraction tax". Every protocol layer between an agent and an API loses fidelity. For simple APIs that's tolerable; for complex APIs, those losses accumulate. The agent receives an impoverished version of the original interface, and that translates into degraded behavior or increasingly elaborate prompts to compensate.

The second risk is a security one, and this is the one that worries us most. Internal APIs typically expose sensitive data or allow destructive operations. When a human developer consumes them, there's architecture, code reviews, and organizational context that mitigate those risks. When you do a naive API-to-MCP conversion and hand it to an autonomous agent, you remove those safeguards. There's no deterministic way to prevent the agent from misusing those endpoints. And here the lethal trifecta shows up again: private data, untrusted content, external action. Most useful MCP servers meet all three by default.

The third risk is unnecessary operational complexity. MCP introduces maintenance, versioning, and governance overhead. If you adopt it without needing it, you're paying that cost without getting the benefit.

What we recommend is a mandatory question up front: does your system really require protocol-level interoperability? If the answer isn't a clear "yes," a well-designed CLI or a direct function call is the better option. MCP has its place, but that place isn't "everywhere."

• I'd also like to talk about the last risk you mentioned, "AI-accelerated shadow IT." How does this actually affect an organization? What implications does it have in every sense, including costs or security?

This is one of the risks that worries us most precisely because it doesn't look dangerous until it's already too late.

What we're observing is a turbocharged version of something that already existed. Spreadsheets that "silently run the business" have been a problem for decades. But now, with tools like Claude Cowork, n8n with AI API integrations, or simply a product manager with access to a coding agent, the jump from "informal automation" to "ungoverned critical system" happens in days, not months.

The organizational impact is multidimensional.

On security, the core problem is that these systems are built with no threat modeling, no permissions review, no secrets management. An n8n workflow that connects Slack to a CRM via OpenAI could be exfiltrating customer data without anyone knowing. And here's the lethal trifecta again: private data, untrusted content, external action. That workflow meets all three by default.

On costs, the problem is invisibility. Finance teams don't see the calls to model APIs piling up on corporate cards or personal cloud accounts. We've seen organizations with dozens of parallel integrations making redundant calls to GPT-4 because no one knew the team next door had already solved the same problem.

On technical debt and governance, what starts as a throwaway prototype turns into critical infrastructure. No one documents it, no one tests it, and when the original creator leaves, no one knows how it works. It's exactly the Excel-macro pattern, but with the ability to execute actions on external systems.

What we recommend isn't banning it, but channeling it. Instrumented internal sandboxes where non-developers can experiment with visibility. A shared catalog of existing workflows to avoid duplication. And clear criteria for determining when a prototype needs to become a production application with real engineering behind it.

AI democratizes software building. That's genuinely valuable. But democratizing without governing is simply accelerating chaos.

• Thank you so much for all this valuable information you've given us. To wrap up the interview, in a few words, what do you think both industry professionals and companies need to keep in mind in order to survive this tsunami that's already here?

What we've learned from all these Radar cycles can be condensed into something that might sound paradoxical: the best way to adapt to AI's speed is to invest in what doesn't change.

Engineering fundamentals — clean code, testing, deliberate design, short feedback loops — aren't nostalgia. They're exactly what allows AI to amplify value instead of amplifying chaos. We've seen it over and over.

For professionals, the message is clear: don't compete with AI on code-generation speed. Compete on judgment. On the ability to ask the right questions, to spot when an agent is heading down the wrong path, to understand the whole system. That's what AI can't replace yet, and it's what holds the most value right now. Invest in deeply understanding the systems you build, not just in building them faster.

For companies, the costliest mistake we can see is treating AI as an individual productivity initiative instead of a systemic transformation. If you introduce agents on top of broken processes, undisciplined codebases, teams with no feedback culture, you're simply going to reach disaster faster.

And there's something I think is critical for both: learning to distinguish between speed and progress. More PRs, more lines of code, more automated workflows aren't progress if the rework rate goes up, if no one understands what's been built, if cognitive debt piles up silently.

The tsunami is already here, yes. But those who survive won't be the ones who swim fastest. They'll be the ones who know when to swim, when to stop, and when to change direction.

If you'd like to have the interview content in PDF, you can download it directly.

% text:Conclusions
% level:2
% type:--h30-15-400
% align:left
% endblock

In my opinion, one of the most relevant conclusions is that engineering fundamentals (testing, observability, or architectural design) have never been more critical than now, not because they are new, but because their absence has immediate, large-scale consequences in an environment where agents can generate new code and massive code changes within minutes.

I like how the interview concludes with a clear message, both for professionals and for organizations, that the best way to adapt to AI's speed is to invest in what doesn't change. The key isn't to compete with AI on generation speed, but on judgment, technical criteria, and a deep understanding of systems.

In my opinion, and I believe I share the Radar's view, companies that treat AI as an individual productivity initiative instead of a systemic transformation run the risk of reaching disaster faster.

I hope you enjoyed the approach I took with this article, and as I mentioned, we'll publish another article with the "making of," the repository, and the technical details of the RAG used. I'll read you in the comments! 👇