It is half past six in the evening. Someone on your team has a whole feature well specified and could hand it to a coding agent until tomorrow. They don't, because at nine in the morning nobody could say whether what the agent produced can be merged.
Thoughtworks Technology Radar 35, published this month, puts that night in the Trial ring and, around it, the list of what you need in order to trust the result. Almost nothing on that list is a new tool.
We read the whole volume, all 117 entries, and kept what is in Adopt and in Trial and affects a team that develops with agents. We have organized it by the questions that team asks.
How to read the Radar
The Radar is put together by the Thoughtworks Technology Advisory Board, 18 senior technologists who meet twice a year; this edition comes from their September 2026 meeting in Recife (Brazil). Each entry, which they call a blip, falls into one of four rings:
- Adopt: they believe the industry should adopt it, and they use it in their projects when it fits.
- Trial: worth pursuing; companies can try it on a project that can handle the risk.
- Assess: worth exploring to understand how it affects you.
- Caution: proceed with care, because it has serious problems.
By our count, in this volume Adopt has 11 entries and Trial has 49. And of what is inside: of the six techniques in Adopt, five are justified by the Radar itself by the arrival of agents or generative AI (isolating the agent, mutation testing, mapping the path to production, giving context in stages and threat modeling); the sixth is post-quantum cryptography. Among the tools, OpenAI Codex moves to Adopt and, according to the text, joins Claude Code and OpenCode as terminal agents that its teams use every day.
With three coding agents cited as daily-use tools, choosing an agent no longer sets one team apart from another. What the Radar moves up a ring is what surrounds the agent, and it gives it one of its four themes, harness engineering at scale: the harness is everything built around the agent, from memory and context to correction loops and limits, and the Radar describes it as "a living asset" that needs ongoing ownership and maintenance.
| Radar 35 entry | Ring | What it asks of your team |
|---|---|---|
| Path-to-production mapping | Adopt | Draw the path of the code from the laptop to production and mark where it gets stuck |
| Mutation testing | Adopt | Check that the tests, including the ones the agent writes, really detect a failure |
| Agent sandboxing | Adopt | Have every agent work isolated and with minimum access |
| Progressive context disclosure | Adopt | A short agent file, with links to what it can look up when it needs to |
| Threat modeling | Adopt | Decide with people where non-deterministic behavior is accepted and where it is not |
| OpenSpec, grilling and visual plans | Trial | Specify and clarify the intent before the agent writes |
| Risk-tiered human oversight | Trial | Review more or less deeply depending on what the change could break |
| Feedback flywheel and self-improving harness | Trial | Turn what fails in each session into harness changes, including removing rules |
| Agent plugin marketplace and Agent Package Manager | Trial | Share skills and instructions across teams with version and provenance |
| Toxic flow analysis for AI | Trial | Find where a prompt injection could get in and where data could get out |
| Unattended overnight agentic builds | Trial | Have all of the above in place before leaving the agent alone with a large task |
Our own selection of the Adopt and Trial entries that affect teams developing with agents; the description in the third column is our reading of the text of each entry. Source: Thoughtworks, Technology Radar vol. 35, November 2026.
Before the agent writes: specify without burying it in Markdown
OpenSpec, a lightweight Spec-Driven Development (SDD) framework that works with any agent, moves from Assess to Trial. According to the Radar, several Thoughtworks teams have used it successfully, including on existing code, and report that the agent produces more predictable results and fewer unrequested changes than when it is given only a prompt. What they highlight is that each change is written as a difference against a persistent specification, which remains the current reference for the system.
In the same ring there are two techniques for the conversation beforehand. With grilling, the agent interviews you about the plan before acting, so it does not guess where your intent is unclear; the Radar adds that it forces you to review your own assumptions and leaves decisions that can be recorded. With interactive visual plans, the agent prepares a plan in HTML with diagrams and screen sketches that the team walks through before implementing; its teams warn against turning it into a big design up front and recommend working in small, verifiable steps.
The counterweight is in Caution: AI-driven documentation sprawl, the documentation that agents generate in large amounts and that nobody prunes. The Radar names Spec Kit and BMAD as tools where this happens, speaks of a "big ball of documentation mud" and warns that obsolete or contradictory specifications consume context and lead the agent astray. Its recommendation is to treat Markdown as a first-class artifact and to spend deliberate human effort pruning it.
Our reading is that the Radar separates the two entries by maintenance: a specification nobody updates ends up as noise the agent reads as if it were true. Even for OpenSpec itself the Radar asks for discipline to keep the specification persistent.
It is also what I see with the teams we work with. I always explain that we align them with OpenSpec because our way of working already follows the same approach, but that tools like Spec Kit do not fit their project's needs today, because they come with skills and templates that are too generic.
Context: fewer instructions, loaded when they are needed
Progressive context disclosure moves to Adopt because, according to the Radar, it is already almost universal in serious applications: the agent starts with the essentials and loads the rest when it needs it. In code, that means a short AGENTS.md with links to documentation the agent reads if it needs it, and skills and tools that take up no context until they are used.
The Caution entry that goes with it is agent instruction bloat: instructions grow, each rule looks useful on its own and over time the whole grows long and contradicts itself. The Radar proposes converting everything you can into automatic checks and reviewing the instructions with each new model to delete the ones it no longer needs. As an example, it says Anthropic removed over 80% of Claude Code's system prompt for its latest models with no measurable loss. What to keep in that file we have covered separately (CLAUDE.md and AGENTS.md: what to keep in the agent file).
Three Trial entries go in the same direction. Subagents for context management do the exploration and retries outside the main session and hand back only the essentials; the Radar suggests two to four at a time and acknowledges that their benefit has not yet been measured systematically. Agent-maintained knowledge bases keep the team's knowledge in linked text files that an agent keeps up to date, with the risk that they drift from reality if no person reviews them. And anchoring agents to a reference application lets them look up the platform's current conventions on the spot, which change faster than any template.
Caution also holds agent skill cognitive surrender: importing whole libraries of community skills without understanding what they do. The Radar puts one of those libraries, mattpocock/skills, in Trial precisely because the skills are small and easy to adapt, and asks you to read each skill before using it and to prefer the ones the team writes for its own domain.
The check: where a person looks and where a machine looks
With more agents working, the Radar sees the bottleneck in review capacity and in the path to production. Its answer in Trial is risk-tiered human oversight: the riskiest or hardest-to-reverse changes are applied by a person, intermediate ones go through human review and low-risk ones can be merged by the agent through continuous integration. To classify them it proposes two routes, zones in the code that require more review and a classification of the change with a language model, which the Radar calls fallible, and it mentions the process Meta has published.
The alternative, reviewing everything with the same intensity, the Radar puts in Caution under its own name: human-in-the-loop theater, the person who approves changes they cannot realistically evaluate and turns approval into a place where nobody is responsible for the decision. For what a person does not review, it proposes watching the system with checks: mutation testing, property-based tests, formal models and agent-assisted semantic review.
Mutation testing is in Adopt for a very specific reason: the agent generates many tests, code coverage is easy to inflate with superficial tests, and mutation testing introduces small faults on purpose to see whether any test catches them. The Radar adds that the agent itself can do it inside its loop, and advises limiting it to the packages that matter or to the changed code, because it is slow.
The other Adopt in this part is path-to-production mapping, a long-standing Thoughtworks practice that, according to the Radar, is relevant again: if the agent writes more code, the bottlenecks show up at another point on the path. It is a workshop with all the people who design, develop, deploy and operate the software: first the steps are written on a whiteboard, from the developer's desk to production, and in a second pass, the pain points.
Two tools in Trial help the agent receive its own mistakes before a person does: Act, which runs GitHub Actions workflows locally so the agent can test the continuous integration before pushing, and ast-grep, whose structural rules a Thoughtworks team uses to check the agent's code and hand the result back. In Caution, the Radar again warns against measuring productivity by the percentage of AI-generated code or by tokens consumed, and recommends DORA metrics and business outcomes.
The harness is maintained, like any other system
The feedback flywheel moves to Trial because, according to the Radar, editing the harness is already routine. The practice adds a question at the end of each session (does anything need to change in a shared artifact?) and an item in the retrospective where the team decides what to update. The Radar insists that the flywheel also has to remove: rules that only accumulate end up in the instruction excess described above. A team can start by noting down each correction it makes to the agent (what your team's corrections teach).
Manel Marcos, our CTO, solves it with a person: we leave a context engineer role in the team we work alongside, and we teach that person to look after the harness and the context and to improve them continuously.
The next step, also in Trial, is the self-improving harness: agents that analyze execution traces and evaluation results and propose or apply improvements to the harness itself. The Radar recommends doing it with bounded experiments and regression tests, with people who set the goals and the limits of what can be modified.
When several teams in a company use agents, the problem of sharing what works appears. The Radar puts in Trial the agent plugin marketplace, a documented Git repository from which skills, instructions, MCP servers and subagents are published, and Agent Package Manager, which manages them as dependencies with recorded version and provenance, and looks for hidden Unicode that could hijack the agent. The next level, the enterprise harness shared across the whole organization, stays in Assess, with the advice to keep it thin and federated until there is consensus on how to do it well.
Security: the agent, isolated and with minimum access
Agent sandboxing reaches Adopt as the default option for all agents, including those acting on business systems: isolated environments with restricted privileges and access to external systems, with a risk-based approach that comes out of threat modeling. Threat modeling, in Adopt, should be a regular part of the development cycle, led by people and supported by agents, and end with explicit decisions: where it is acceptable for the model to behave non-deterministically and where deterministic limits are needed.
In Trial, toxic flow analysis for AI looks for dangerous data paths in a system with agents. The Radar starts from the combination it calls the "lethal trifecta": access to private data, exposure to untrusted content and the ability to communicate externally. And it warns that the risk also comes through skills that look useful and hide instructions to exfiltrate data. The managed agents runtime, running agents on a platform that manages their execution, away from the developer's laptop, is also in Trial, with the recommendation to treat it as production infrastructure.
If you build agents that do not code
One Trial entry interests anyone taking agents to business processes: the coding harness for general-purpose agents. More and more teams build the loop of their agents on the engine of a mature coding agent (the Claude Agent SDK, the Codex SDK, the OpenCode server or Pi), which already handles context compaction on long tasks and persistent sessions. The price is less control, and the Radar asks you to review its default instructions, designed for writing code, and to watch token consumption.
Around it there are several production components in Trial: stateful guardrails, which evaluate the whole conversation, turn by turn; Promptfoo, for repeatable evaluations and attack tests; Presidio, to detect personal data before sending it to a model, with the warning that it is not infallible; Temporal and Restate, for long processes that wait for a person; and LibreChat, which the Radar presents as a controlled way to give AI tools to people outside engineering. On models, open-weight and small ones move to Trial, and using the most powerful model for everything, without looking at cost or latency, stays in Caution.
Limit The Radar reflects the opinion of a group of technologists at a consultancy, based on their own projects; it is not a study with measured data. Trial is an invitation to try it on a project that can handle the risk, and in several entries the text itself acknowledges that experience is short: the benefit of subagents has not been measured systematically and some recommendations rest on the experience of a single team. Thoughtworks sells this kind of work, just as we do.
Tonight's test
Of all the entries, the one that works best as a diagnostic is the night one. The Radar explains that "overnight" is in the name because it is hard to fake, and that a team that does not leave an agent coding unwatched overnight probably is not running fully autonomous work during the day either. It also says the practice has entry requirements and that a big part of its value is pushing the team to meet them. Turned into questions for your team, plus one that comes from the risk-based review:
- Does the agent work in an isolated environment, without access to what it does not need for that task?
- Is the task specified before starting, with criteria that can be checked, as in Spec-Driven Development?
- Does the agent receive its own errors (tests and continuous integration status) and can it correct them without waiting for a person?
- Do you have a tested harness that validates the result, so you do not depend on reading a night's work line by line?
- Do you know which changes a person reviews in the morning and which the system itself can merge?
In our own product, where we have reached a high level of maturity, this is how we do it: once a feature has all its open questions resolved, we leave the agents developing a sprint of user stories overnight and review the sprint audit in the morning.
If any answer is "no", the Radar suggests treating the night as a goal that justifies building that foundation. That is the work of AI-Accelerated Development. We build two things with your team that stay with you: the context the AI works in, and the process you work with, from idea to up-to-date documentation. If you want someone from outside to review what you are missing, there is a free diagnostic.
Frequently asked questions
What is the Thoughtworks Technology Radar?
It is the guide in which Thoughtworks gives its position on techniques, platforms, tools and languages. It is put together by its Technology Advisory Board, a group of 18 senior technologists who meet twice a year, based on what they see in their projects. Volume 35, from November 2026, has 117 entries.
What do Adopt, Trial, Assess and Caution mean in the Radar?
Adopt means Thoughtworks believes the industry should adopt it now. Trial, that it is worth trying on a project that can handle the risk. Assess, that it is worth exploring to understand how it affects you. Caution, that you should proceed with care because it has significant problems.
What is the harness of a coding agent?
It is everything the team builds around the agent so that it works well: the context and instructions, the memory, the checks that feed its mistakes back to it and the limits on what it can touch. Radar 35 treats it as a living asset, with an owner and ongoing maintenance.
Can you leave a coding agent working all night?
Radar 35 puts it in Trial for teams that already have the foundations: the agent isolated in a restricted environment, the work specified up front, checks that let it correct its own mistakes and a tested harness that validates the result without relying on reading every line.
What does Radar 35 say about Spec-Driven Development?
It moves OpenSpec to Trial because its teams use it successfully, including on existing code, and asks that the specification be kept as a living reference. At the same time it puts mass-generated documentation that nobody prunes in Caution, and names Spec Kit and BMAD as tools where this happens.
What is human-in-the-loop theater?
It is keeping a person in an agent's loop as an empty approval step: they approve actions or changes they cannot realistically evaluate. Radar 35 puts it in Caution and proposes grading the review by the risk of each change.
Sources
- Thoughtworks, Technology Radar, vol. 35, November 2026 (PDF).
- Entries cited: Unattended overnight agentic builds, OpenSpec, AI-driven documentation sprawl, Progressive context disclosure, Agent instruction bloat, Risk-tiered human oversight, Human-in-the-loop theater, Mutation testing, Path-to-production mapping, Feedback flywheel, Agent sandboxing, Toxic flow analysis for AI and Coding harness for general-purpose agents.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →