Techniques 

We've previously recommended sandboxed execution for coding agents. As AI agents become increasingly autonomous and capable of acting not only in coding environments but also in business systems, restricting their operational scope has become critical. We now consider agent sandboxing a sensible default for all agents. Running agents in isolated environments with restricted privileges and access to external systems reduces the risk and limits the impact of unexpected behavior, unintended actions or malicious exploitation.

We recommend teams apply a risk-based approach to sandboxing, informed by threat modeling of their agents and systems. Although there is no one-size-fits-all solution, recent security headlines reinforce the importance of applying established security practices, such as the principle of least privilege, when building and running agents.

Mutation testing evaluates test suite quality by automatically introducing small, artificial bugs into application code and verifying that at least one test fails. If tests pass despite the code change, the mutation survives, revealing gaps in test coverage or assertion quality. As teams adopt AI coding assistants, the volume of AI-generated code and tests increases rapidly, making traditional code coverage metrics easier to inflate with superficial tests that lack meaningful validation.

This technique acts as a guardrail, helping ensure generated tests don’t simply pass without catching logic changes.

Beyond dedicated frameworks, AI agents can now perform mutation testing autonomously during execution by directly modifying code, running tests and evaluating assertions in their loop. Because automated mutation runs are time-consuming, developers should target specific internal packages or rely on incremental checks to run tests only on recently changed code.

Path-to-production mapping is a standard practice at Thoughtworks that has become newly relevant with the advent of agentic coding. Increased code throughput can expose or amplify bottlenecks elsewhere in the path-to-production, making it essential for teams to optimize the end-to-end flow of software rather than coding speed alone. The activity is most often done in a workshop that includes everyone involved in designing, developing, releasing and operating the software. First, participants list the steps in the process on a whiteboard, from the developer workstation all the way to production. In a second pass, they capture pain points. The activity is often eye-opening, as participants identify delays, risks and inconsistencies they weren’t previously aware of. Tackling those bottlenecks is key to improving overall delivery productivity.

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to protect digital data against attacks by future quantum computers. As quantum computing advances, the threat to conventional encryption becomes increasingly real: data encrypted today can be harvested now and decrypted later, making key exchange the most urgent area to migrate. With NIST's standards now finalized (ML-KEM, ML-DSA and SLH-DSA), governments worldwide target migration between 2030 and 2035.

Modern infrastructure, languages (for example, Java since JDK 24) and frameworks are increasingly providing native PQC support in their latest versions. Enabling it, though, requires upgrading from older releases or adjusting configurations. Organizations should mandate quantum-resilient cryptography for greenfield projects while accelerating migration roadmaps for legacy systems.

Progressive context disclosure is a context engineering technique for providing information to LLMs on demand. The system bootstraps the LLM with essential context and allows the LLM's responses or user input to trigger the loading of additional data. We're moving progressive context disclosure to Adopt because the practice is nearly universal in serious applications, although it takes many forms.

In coding, one example is to keep your AGENTS.md lean and provide links to documentation that the agent can look up when needed. Coding harnesses also use this approach to defer the full context cost of MCP tools and agent skills until they're used. Business applications might use vector RAG or GraphRAG to retrieve additional information based on user input. In each case, progressive context disclosure can reduce token consumption and costs and help counter context rot.

Threat modeling is an exercise for identifying potential threats to your systems. It’s a core security practice for all software development, especially for generative AI applications, whose distinctive security risks, such as prompt injection and autonomous action, may be missed by rule-based checks and scans. Threat modeling should be a regular, human-led part of the software development lifecycle, with support from agents. The discussion helps surface undocumented behaviors and build stakeholder understanding.

We recommend starting with known threats and mapping them to your context. Useful resources include the MITRE ATLAS catalog of AI threats, MAESTRO as a companion to frameworks such as STRIDE and toxic flow analysis for reasoning about where prompt injection might enter. A session should end with explicit decisions about where nondeterministic model behavior is acceptable, where it isn’t and where deterministic guardrails are needed to limit risk and harm.

An agent plugin marketplace is a means of distributing harness assets across an organization. The need arises when multiple teams adopt coding agents and want to share skills, instructions, MCP servers, subagent definitions and other assets. Copying these between repos provides no easy way to publish, discover or update them. We've implemented an agent plugin marketplace using documented Git repositories, with plugins in the Agent Plugins format that coding agents consume directly or that are managed as dependencies with Agent Package Manager. Anthropic popularized the pattern with its Claude Code plugin marketplace, and hosted registries such as Tessl's and community collections like wshobson/agents have adopted the idea. We see agent plugin marketplaces as a practical way to make your enterprise harness available across the organization.

With agent-maintained knowledge bases, a team keeps its shared knowledge in linked plain-text files, often in an Obsidian vault, and uses a coding agent to maintain them. Andrej Karpathy's LLM Wiki describes the pattern: raw sources the agent reads but never changes, a wiki it maintains and a schema that guides how it does it. OpenWiki applies a narrower version of the idea to a single code repository's documentation. The technique is practical today because general-purpose coding agents can already read and edit files effectively, while Git provides version control.

Many people start with a personal "second brain." We recommend taking the next step and sharing one across a team, although expanding it into an organization-wide knowledge base takes more than pointing a coding agent at a folder of files. Generated knowledge can drift from reality, and without regular human effort to keep it accurate, the knowledge base risks creating AI-driven documentation sprawl.

Several of our teams use variations of this approach, with product managers, designers, developers and their agents all querying the same knowledge base. These teams find their information more connected and accessible.

Anchoring coding agents to a reference application addresses the challenge of application template decay by separating lean, structural scaffolding templates from evolving platform configuration rules. Previously, we focused on using live, compilable reference applications to keep generated code in sync with current practices. We’re now seeing teams successfully extend this pattern to AI-driven scaffolding.

Traditional code generators and scaffolding CLI tools quickly fall behind as platform guidelines, dependencies and architectural best practices change. Instead of hardcoding these rules into static templates, coding agents query centralized, up-to-date information sources, such as an OpenWiki or structured agent-maintained knowledge bases, at runtime to retrieve current conventions and settings. Consolidating evolving platform rules into unified, agent-accessible repositories helps agents generate code that follows current standards without requiring continuous updates to the underlying scaffolding tools.

Teams building agents for non-coding work, such as document processing, operations support or migration planning, have typically started with an agent framework and assembled the agent loop themselves. Increasingly, we see teams instead build on a coding harness for general-purpose agents, reusing the runtime of a mature coding agent. Popular coding agents now expose their runtime programmatically through the Claude Agent SDK, the Codex SDK and app-server, OpenCode's server and SDK or Pi's SDK and RPC mode. These harnesses already handle complex aspects of the agent loop, including compacting context on long-running tasks, persisting sessions and running headlessly with the same agent skills, subagents and instructions used in interactive coding-agent sessions. Compared with agent frameworks, the trade-off is less control in exchange for a runtime that's already been tested extensively. We’ve used this approach to build an internal accelerator for .NET application migrations.

However, these harnesses differ in their capabilities. Codex and the Claude Agent SDK provide sandboxing and approval policies, while Pi deliberately leaves guardrails to extensions, making it easier to adapt but requiring more work. Because these runtimes are designed for software development, their system prompts and built-in tools tend to steer agents toward writing and running code. Teams should review these defaults for their intended domain. They should also monitor costs, since coding-agent loops can consume substantial numbers of tokens, and large built-in prompts add to every turn. That's one reason minimal harnesses such as Pi are attractive.

In the previous Radar, we described the feedback flywheel as a way to improve a coding agent's harness from earlier sessions. Most developers update AGENTS.md files and agent skills when an agent gets something wrong, but what one developer learns may not be shared with the rest of the team. The feedback flywheel adds a question at the end of each session, asking whether anything should change in a shared artifact, along with a retrospective item where the team decides what to update. Feedback sensors show which checks keep failing, an agent suggestion box collects problems agents report and tools such as Backpass propose edits based on past sessions for a human to accept or reject. We're moving feedback flywheel to Trial because harness edits are now routine.

The flywheel needs to remove as well as add. Rules that only accumulate become agent instruction bloat, and a sensor that produces only noise should go. We recommend continuously checking which artifacts are still used and up to date. Context profiling shows whether edits are increasing what each session loads. Where a self-improving harness has an agent run the loop, the feedback flywheel makes it a team habit, with agents proposing changes and people choosing which changes to make.

As context-heavy workflows become more common, sending full source files or unstructured text to LLMs increases token costs. Graph-grounded codebase reasoning addresses this by representing code, documentation and relationships as a structured graph, allowing agents to retrieve relevant subgraphs as context. Tools such as ⁠Graphify capture structural dependencies, helping agents identify relationships that text-based retrieval may miss.

However, graph grounding comes with trade-offs. Recent research suggests agents can sometimes perform worse with graph-based context than with simpler tools such as find and grep. We’ve placed the technique in Trial to encourage readers to explore when graph-based context improves efficiency and accuracy, building on our previous blip on code intelligence as agentic tooling.

Grilling is a technique in which a coding agent interviews you about a plan before acting to resolve potential areas of ambiguity. The best-known example comes from mattpocock/skills, but other skills libraries have their own versions. One benefit is that grilling discourages coding agents from guessing where your intent is unclear. It surfaces assumptions the coding agent might otherwise make on its own. Another advantage is that it helps counter codebase cognitive debt. The grilling process forces you to examine your own assumptions, leaving you with a better understanding of the implementation plan that can be captured in decision records. Our teams have found grilling a useful addition to their agentic coding practice.

Interactive visual plans with agents are self-contained HTML or MDX plans with diagrams, user flows and wireframes that teams can explore before implementation. Our teams find that stepping through these artifacts makes it easier to verify intent and review complex changes than reading long text plans. Our teams warn against using this technique for "big upfront designs" and favor a more iterative approach, breaking work into smaller, verifiable steps to build understanding along the way. The same approach can provide a visual recap of completed work, but our teams find recaps most useful when the implementation deviates from the original plan. We recommend using interactive visual plans with agents to build shared understanding and establish a human review point before agents implement changes.

Managed agents runtime is the practice of running software delivery agents on a platform that manages their execution, infrastructure and operational needs rather than relying on a developer's workstation. The runtime hosts the agent loop and provides sandboxed compute, triggers, credential handling, session state and observability, leaving teams to define the model, prompt, tools and skills. Long-running, asynchronous work is well-suited to background agents that pick up tasks from issues, pipelines or schedules and submit pull requests for review.

Coding tools are converging on this approach, with Cursor cloud agents, the GitHub Copilot coding agent and OpenAI Codex cloud tasks all running in remote sandboxes. Claude Managed Agents offers a general-purpose equivalent. Our internal security team runs a daily agent that triages endpoint detection false positives and proposes rule changes. "Managed" doesn't necessarily mean someone else's cloud. At one client, we run custom agents on a self-hosted runtime in a continuous loop across multiple repositories, fixing code smells flagged by scanners and upgrading dependencies along with any required code changes.

A hosted service is often the easiest place to start, but organizations with data residency, security or integration constraints may need their own platform. Either way, we recommend treating the runtime as production infrastructure, with agent sandboxing and version-controlled agent definitions.

Open-weight models, where model weights, architectures and inference code are publicly released, have reached a significant inflection point. Attracted by their lower total cost of ownership, we’ve been evaluating the latest models from families such as DeepSeek, GLM and Kimi for production delivery work requiring complex reasoning and high-quality code generation, and we’re seeing good results.

Beyond cost efficiency, open-weight models provide deployment flexibility, freedom from vendor lock-in and stronger data sovereignty. Engineering teams can right-size their deployments, from lightweight flash models to hundred-billion- or trillion-parameter mixture of experts (MoE) models, and perform private fine-tuning using domain data. Although self-hosting requires greater operational effort, major cloud providers now offer managed open-weight models that lower the barrier to adoption. Rather than treating them merely as budget options, organizations should evaluate open-weight models for a broad range of enterprise workloads, well beyond coding.

Risk-tiered human oversight aligns review depth with what a change could break. Reviewing everything with the same intensity ends in human-in-the-loop theater. We suggest systematically triaging changes. The riskiest or hardest-to-reverse changes are reserved for humans to apply. Intermediate-risk changes go through human review. Low-risk changes can be auto-merged by coding agents through a continuous integration pipeline.

Two strategies can help us decide which changes need more review. Zones in the codebase require elevated review with particular files or directories, while LLM-based change classification analyzes the impact of changes but is fallible. Meta's published process combines these two approaches. Our teams find risk-tiered human oversight an effective way to make the best use of scarce human attention.

A self-improving harness uses agents to analyze execution traces and evaluation feedback, then propose or implement improvements to the system surrounding the model, including prompts, context strategies, workflows, skills, tools, memory and middleware. The idea isn’t new: techniques such as the feedback flywheel use successes and failures from coding-agent sessions to improve the harness but still rely on humans to interpret the feedback, decide what to change and update the system. Recent research explores a more self-directed approach. Meta-Harness and VERSE use execution traces and evaluation results to improve harness code; VERSE also evolves the optimizer’s own tools and procedures. Lilian Weng’s overview traces this progression from prompt optimization to harness evolution.

Observability and programmability are essential to this transition. Observability helps agents diagnose failures from execution traces and connect changes to measurable outcomes, while programmability gives agents access to components they can inspect, modify and test, expanding the scope for self-improvement. Pi’s extensions, Claude Code Mods and DeepSeek Harness (DSH) illustrate this direction through extensible context, workflows, tools and harness components.

Greater openness creates more opportunities for improvement, but gains still require validation. We recommend bounded experiments with regression testing, while humans define objectives, set modification boundaries and assess whether improvements generalize to new tasks.

We continue to see a shift in the industry away from a "bigger is better" mindset toward improving artificial intelligence through high-quality training data, model distillation and quantization. Small language models (SLMs) have become increasingly useful for specific tasks that don't require the computational resources of larger models. As organizations face rising costs from running LLMs, teams are recognizing the value of choosing the right model for the task.

Compact models are also viable for edge computing, as Apple Core AI demonstrates by running small foundation models directly on devices.

Our teams have found SLMs effective for narrow, high-frequency tasks that don’t require extensive knowledge or complex reasoning, such as summarization, structured data extraction, intent classification for request routing and basic coding. Unless an agentic use case requires multi-step reasoning or reliable tool calling, teams should consider an SLM as a lower-cost, lower latency alternative.

Stateful guardrails extend LLM guardrails from single messages to whole conversations. Instead of checking only the current user message or the final model response, they evaluate a compact transcript of recent turns against policy-specific checks and maintain strike or ban state across the session. This matters because unsafe intent can emerge gradually: each message may look acceptable on its own, while the conversation as a whole reveals attempts at policy evasion, jailbreaking or prompt extraction. In practice, stateful checks run as a runtime gate before the agent acts, working alongside conventional single-turn input and output guardrails.

Evaluating conversation history on every turn adds latency and cost, and strike or ban thresholds need tuning to prevent false positives from locking out legitimate users. Our teams have used this technique in a production conversational assistant for sensitive workflows, tracing guardrail decisions in Langfuse. We recommend that teams running multi-turn assistants in production try stateful guardrails rather than relying on per-message checks alone.

Subagents for better context management is the practice of delegating work to subagents to keep it out of the orchestrating agent's context. Exploration, tool output, retries and intermediate reasoning stay in the subagent, and the main session receives a short summary. Most people first use subagents to run tasks in parallel or form a role-based team of coding agents. Protecting the orchestrator's context is another reason to use them. Whatever remains in the orchestrator's context competes for its attention on subsequent turns. Pulling a subagent’s full transcript into the main thread to check its progress undoes this benefit. Useful guidelines include running two to four subagents at a time and keeping tasks that require the same understanding of the code within one agent, so multiple agents don't each have to rebuild that understanding.

Using subagents to protect the orchestrating agent’s context is a form of context engineering that’s easy to try because most coding agents support subagents, and the change is largely in the instructions. We've used cheaper models for subagents handling narrow tasks such as research, potentially reducing costs compared with blanket frontier model usage. We're placing the technique in Trial because its benefit hasn't been measured systematically. The evidence so far comes from practitioners' accounts of their own sessions, without detailed token accounting. We've also observed that the same model with the same prompt uses subagents differently depending on the harness. Teams trying this approach should use context profiling to check whether the orchestrator's context actually shrinks.

As AI agent capabilities expand, teams are increasingly deploying systems that face a lethal trifecta of security risks: access to private data, exposure to untrusted content and the ability to communicate externally. This combination creates opportunities for attacks such as prompt injection and tool poisoning. To address these risks, we've moved toxic flow analysis for AI to Trial.

While general threat modeling provides a broad security foundation, toxic flow analysis focuses on identifying unsafe data paths through agentic systems. These risks aren't limited to standard integrations. They can also arise from malicious agent skills that appear useful but contain hidden instructions to exfiltrate sensitive data. We've successfully used tools such as Agent Scan to perform this analysis, helping teams identify and mitigate unsafe data paths before they're exploited.

Unattended overnight agentic builds refers to the practice of giving a coding agent a feature-sized piece of work when the team leaves for the evening and reviewing what it produced the next morning. We've done this with epic-level features and infrastructure tasks that can take hours. One agent is enough, without a coding agent swarm, although it may use subagents. One Thoughtworks team spends the day collaborating on plans and specifications and leaves the coding to agents overnight. "Overnight" is in the name because it's hard to fake. A team that can do this will likely run similar jobs during the day too. (A team that doesn't leave an agent coding unwatched overnight probably isn't running fully autonomous work during the day either.)

Like microservice prerequisites, this practice has entry requirements, and pushing teams to meet them is a big part of its value. Agents need sandboxed execution, work specified up front as in spec-driven development and feedback sensors so they can correct their own mistakes. A night's work can be too large a batch to review effectively line by line, so teams need a harness they've tested to validate the changes instead of relying on human code review. Complementary techniques include running the agent in a managed agents runtime and letting agents keep the build green by fixing pipeline failures themselves. We've placed this in Trial for teams that have those foundations; for other teams, it's a goal that justifies building them.

Agent pipeline responsibility incorporates coding agents into the team's accountability for keeping the build green. An agent that can’t see the build status can’t respect a team agreement not to push on red, while a human relaying failure logs into a chat window becomes a meat proxy.

We recommend making the build state part of the agent’s context. Expose pipeline status and logs through the agent's tools so it can see what went wrong and help fix it. Enforce important rules mechanically with pre-push and server-side gates to prevent agents from pushing broken changes. The increased commit rate from coding agents is leading teams to rethink assumptions around build discipline through techniques such as risk-tiered human oversight. Include the role of agents in your build policy when conducting path-to-production mapping.

An agent suggestion box gives a running agent somewhere to report the problems it encounters, such as a bug in a tool or a dependency missing from its environment. When an agent's only output is a pull request or a structured verdict, it may work around the problem without anyone hearing about it. The next session then hits the same problem again. The box can be a Slack channel, a memory store or an issue tracker. Lovable calls its version a "vent tool," and agents-feedback offers one for coding agents. Memory can help an agent avoid a broken tool, but a suggestion box gets the tool fixed. The technique works for business agents in production as well as for coding agents.

We've used an agent suggestion box with an agent that starts a fresh session each day to draft detection engineering rules. A second agent deduplicates the reports. The same report from several sessions is a clear signal, although some reports are subjective or transient. With the box in place, runs went more smoothly, and we had a list of improvements to make. The suggestions still need to be reviewed and acted on, for example, through self-improving harness. We're placing agent suggestion box in Assess because our experience comes from one agent. Lovable merges about ten fixes a day from its vents but reports that roughly half the fixes its triage agent proposes are false positives.

As token costs have risen and the industry has left the tokenmaxxing fad behind, developers are looking for ways to manage token usage. The old advice that you should always measure before optimizing still applies. Context profiling means analyzing where your token spend is going (for example, are tokens being spent on file reads or MCP tool calls?). Intuition is a poor guide to identifying which optimizations are worthwhile, especially when you factor in caching, model tiers and promotional pricing. Mature tooling hasn't yet emerged, but you can make do by analyzing your agent sessions or data from tools such as Entire CLI and AgentsView.

In our experience, the biggest savings often come from simple changes, such as clearing sessions at the right time, tuning cache parameters or quietening chatty build scripts. Yet we often see developers reaching for complex solutions such as compression proxies without measuring their impact.

An enterprise harness An enterprise harness is the organization-wide layer of what coding agents consume managed collectively. It includes skills, tools, connectors to internal context, approved technologies, architecture decision records, path-to-production guidance, hooks and security policies. We observe that as multiple teams in an organization adopt coding agents, they need common context to complement each team's curated shared instructions. It's like a developer experience platform, but for agent experience. We've seen organizations go as far as building a custom coding agent on top of OpenCode, but we recommend sharing assets through open standards and distributing them via an agent plugin marketplace. There's no consensus yet on how to do this well, so keep the enterprise harness thin and federated, leave room for experimentation and harvest what works.

Enterprise AI has focused heavily on text and vision, while much business data remains locked in relational databases. Foundation models adapt transformers to structured data, pretraining on an organization’s event sequences and transaction logs to learn reusable representations of business behavior.

Unlike traditional gradient-boosted models that require extensive feature engineering and retraining, these models can support multiple downstream tasks with lightweight fine-tuning. Tools such as TabPFN and TabFM can improve risk assessment, predictive analytics and customer retention directly from tabular or relational data. Given their potential to unlock business insights without complex feature pipelines, we suggest assessing this technique.

Nowadays, organizations and teams come up with custom harnesses tailored to their projects, including agent skills, plugins, AGENTS.md and deterministic guardrails. Harness quality evaluation has become an important technique. Guardrails and harnesses help a coding agent course-correct and improve overall quality, but only if they actually work.

A harness usually includes both deterministic and non-deterministic components. For non-deterministic harnesses, our teams use PluginEval to evaluate coding agent plugins or skills. For deterministic harnesses, we introduce a test suite to enable TDD-style development of any guardrails, ensuring each one actually works and providing evidence of its effectiveness. We recommend running evaluations on a scheduled basis (such as nightly or alongside CI).

In previous editions of the Radar, we put local coding assistants in Caution because the available models were too limited for complex software engineering contexts and weren’t a compelling solution to the concerns they were intended to address. With coding agents now being adopted much more widely than 18 months ago and local open-weight models maturing rapidly, our teams have found local coding models effective in addressing blanket frontier model usage.

Models that can run locally, such as Qwen3.8-27B, have proved particularly useful for workloads that don’t require a frontier model, including codebase indexing, structured log parsing and summarization, initial coding tasks and automated reviews of Git diffs and commits. Running these tasks locally can avoid incremental cloud token costs while also enabling long-running background processing and providing an offline fallback.

Agentic systems and coding tools introduce new architectures and emergent security threats. MITRE ATLAS is a knowledge base of adversarial tactics and techniques targeting AI and ML systems. More focused than the broader MITRE ATT&CK framework and designed to complement it, ATLAS provides a taxonomy of threats for ML pipelines, LLM applications and agentic systems.

We've found that without a shared vocabulary, security risks are often overlooked or reduced to a checkbox exercise. This is where ATLAS can help. Grounded in research on real incidents and technology patterns, teams can use the framework to support threat modeling. Teams may also find it a natural complement to control frameworks such as SAIF, helping describe the evolving threat landscape for AI systems.

We've long said that being conscious of production helps developers write better code, and we're finding the same applies to coding agents. We recommend production-aware coding agents, which means giving coding agents appropriate access to production observability data and tools. This context helps them plan effective changes, review the impact of deployed changes and assist with investigating production issues. A growing tooling category is making this access practical. This recommendation is similar to agent pipeline responsibility, extending the feedback sensors that keep agents self-correcting during a coding session beyond pre-commit checks and into production. We believe successful development has multiple layers of feedback, and successful agentic engineering gives agents access to all of them.

Programmatic tool calling is a tool-use pattern where the model writes code instead of issuing one tool call at a time. Rather than making a round-trip through the model for each operation, it combines tool calls into a program that runs in an execution environment, looping, filtering and shaping results. Only the selected results or the final output are returned to the model’s context.

The concept appears in several implementations, although the naming is still unsettled. Cloudflare and Pi call it Code Mode; Anthropic calls it programmatic tool calling; and an earlier Anthropic engineering article describes code execution with MCP. DeepSeek Harness (DSH) also provides a closely related PTC Mode.

Implementations differ mainly in where the execution environment runs: in a model provider’s container, the agent harness or, more recently, through a Code Mode MCP server. The latter allows MCP clients to use programmatic tool calling without implementing their own execution runtime. However, it can reduce the granularity of client-side approvals, so authorization and approval for individual operations must still be enforced by the server and its tool handlers.

Coding agents produce and revise prose artifacts such as specifications, ADRs and plans far faster than humans can review them. Text diffs bury intent under rewording and formatting noise, making it hard to see whether a plan has changed significantly. Semantic review of AI-edited prose adds a layer on top of the text diff: an LLM analyzes changes in meaning, such as altered facts, conflicting statements, redefined acceptance criteria and changes in scope. Much like automated PR review but for prose, it can be implemented as an agent skill that runs whenever a coding agent edits a document. We’ve seen Thoughtworks teams use this technique to reduce cognitive load and review fatigue, helping reviewers better understand changes to planned work before implementation.

Tests as data over tests as code means expressing test cases as structured data, typically YAML or JSON, rather than as test code. A project-specific test harness reads that data and executes the underlying code: the harness provides the building blocks, while the test cases define how they’re assembled. The technique isn't new; BDD with Gherkin is a prime example. What makes it relevant again is that AI coding agents now write more code, including tests. We’ve found that a defined schema better constrains what they produce, making tests easier to generate and review, with less AI-generated test code.

A few of our teams have also seen a compelling use case in legacy modernization, where the same test cases expressed as data can run against both legacy and modern code by swapping the harness adapter. This helps teams verify that the modernized system behaves like the original, at least for the cases covered by the tests. Using the technique with AI is still relatively new to us, and we haven't applied it broadly. However, the results so far are promising, and we think it's worth assessing.

Instructions for coding agents, such as AGENTS.md guidance, process skills and workflows, tend to grow longer over time. Although each new rule might be useful in isolation, this accumulation often leads to agent instruction bloat. The instructions become long, contradictory and stale, especially if teams engage in agent skill cognitive surrender and import external instruction sets wholesale.

First, convert any instructions you can into deterministic hooks or checks. Then, reevaluate instructions against each new model and delete those it no longer needs; progression testing, rather than regression testing. Anthropic removed over 80% of Claude Code's system prompt for its latest models with no measurable loss, as frontier models now follow instructions more reliably. Progressive context disclosure keeps the remaining instructions out of the way until they’re needed.

There is a growing trend of agent skill cognitive surrender, an antipattern in which teams adopt large, community-curated skill libraries or heavyweight AI agent frameworks without fully understanding what they do. Much like blindly importing large software dependencies, developers can treat these skills as ready-made capabilities and lose sight of how the underlying system works. This isn't a new problem; similar examples include copy-pasting code without understanding it or over-relying on generic design patterns. However, the proliferation of AI tools has made the issue much more apparent.

Beyond the loss of system understanding, surrendering critical evaluation introduces security risks: unreviewed prompt instructions can make their way into execution pipelines. Skills from different sources may also conflict when they weren't designed to work together. It’s important to inspect and review skill instructions before adapting them rather than using general-purpose agent skills indiscriminately. As underlying models become more capable, generic community skills can become unnecessary or obsolete, making it more valuable to curate domain-specific skills tailored to a project's context.

We observe many noncoders graduating from no-code platforms to coding agents such as Claude Code and OpenAI Codex. We celebrate people solving their own problems, but AI-accelerated shadow IT, whether built by noncoders or developers, comes with risks. First among these is security. Second, software originating from outside traditional development usually lacks testing, deployment pipelines and observability. This particularly matters if one person's productivity tool is adopted by their team or department. Organizations should prioritize governance with limits and guidelines on AI-generated applications. In our experience, it's better to provide colleagues with environments and enterprise harnesses for safe experimentation than to extinguish their enthusiasm. Be firm on security, and give useful tools a clear path to support.

AI-driven documentation sprawl occurs when teams use AI agents and spec-driven development tools such as Spec-kit or BMAD to generate large volumes of Markdown files and documentation. Because AI can produce polished, professional-looking docs in seconds, the result can create an illusion of software quality and rapid progress. Unlike source code, however, documentation rarely passes through automated quality gates or CI tests. As projects evolve, repositories rapidly accumulate verbose, unmaintained and contradictory specs that developers lack the time to clean up, resulting in a chaotic "big ball of documentation mud."

This overabundance of obsolete documentation is particularly problematic in agentic workflows. When coding agents read through a repository littered with outdated architectural decision records or conflicting specification files, these redundant and contradictory documents consume valuable context and provide unreliable information. Rather than aiding development, obsolete context can lead AI tools astray and result in poor code generation. To maintain agent effectiveness, teams must treat Markdown as a first-class artifact, spending deliberate human effort to prune, refine and consolidate generated context files so the agent’s context remains crisp, relevant and authoritative.

We've sometimes caught ourselves defaulting every task that requires an LLM to the most capable model available, paying no attention to cost, latency or required capability. We call this blanket frontier model usage. Frontier models can cost significantly more and run more slowly than their more nimble counterparts; routine work such as exploration, simple edits or summarizing is often better served by a smaller model or even open-weight models. You can switch tiers manually, per subagent or through harness settings that switch automatically based on task complexity or stage. Each model has its own prompt cache, so you can also switch at natural boundaries, a new session, a subagent or the handoff from planning to implementation, rather than per request. A warning on our warning, though: more capable models sometimes finish tasks using fewer tokens, so use context profiling to check whether your optimization is working.

In a previous Radar, we warned against using coding throughput as a measure of productivity. As the industry pushes for AI adoption and seeks tangible metrics, we increasingly see activity-based metrics such as the percentage of code generated by AI or tokens consumed treated as badges of honor. Although such metrics may indicate adoption levels, they’re poor proxies for real productivity gains.

To measure meaningful productivity, we continue to recommend established frameworks such as DORA metrics and collaboration quality, along with tying improvements directly to business outcomes. Treating activity metrics as targets rather than signals risks falling prey to Goodhart's law. We’ve seen developers generating AI busywork simply to hit these targets.

Human-in-the-loop theater is keeping a human in an agent's loop as an empty approval step rather than a real check. The human approves actions, prompts or diffs they can't realistically evaluate.

The approval step functions as an accountability sink: no one truly owns the decision. Our advice is instead to triage. Reserve human review for changes a human can genuinely judge, using risk-tiered human oversight. For the rest, shift from reviewing individual changes to steering the system with mutation testing, property-based testing, formal models such as TLA+ and Quint and agent-assisted semantic review.

A meat proxy is a person who unthinkingly passes on unverified LLM output to a colleague, forwarding it without reading, validating or adding substantive judgment. It's a violation of good AI etiquette and, in our unfortunate experience, a growing problem. When you act as a meat proxy, you shift the verification burden downstream onto the other person and shirk your own responsibility for assuring quality work. This is similar to human-in-the-loop theater, except that it's fake authorship instead of fake approval. In neither case is the human adding value. KDE's draft AI guidelines put it well: "Don't be a meat proxy."

As token costs rise, teams increasingly turn to tools like Headroom, RTK and Tamp to shrink their prompts. However, we advise against naive context compression, which can introduce several subtle problems. First, it often interferes with prompt caching; reducing token counts while missing cache hits can lead to higher actual bills. Second, aggressive compression causes information loss, degrading the performance and accuracy of agentic loops. Third, some tools rely on an LLM to summarize context during compression, adding latency and costs that defeat the purpose.

Before adopting these tools, profile your context usage and rigorously evaluate both net cost and task accuracy; token reduction means nothing if prompt caches break or agent performance degrades. Opt for tools that compress tool outputs while preserving references to the raw data and that prune history only in one shot at task boundaries, to protect cache prefixes.

Stacked pull requests break a large change into an ordered chain of small, dependent pull requests (PRs). Rather than targeting the main repository branch, each subsequent PR targets the branch directly below it in the stack. We've seen a surge in interest in this technique recently due to the rapid adoption of AI-assisted coding tools. Teams adopt this approach to reduce review latency and developer idle time. By evaluating small, isolated layers, reviewers face lower cognitive overhead. Tooling has also improved to support this workflow; GitHub recently introduced native support.

Despite better tooling, we've placed this technique in the Caution ring because it’s often a workaround for poor upfront decomposition. Stacking doesn't create decomposition problems; it exposes ones that were already there. The risk isn't the technique itself; it's using it as a substitute for that planning. Habitual, undifferentiated stacking can easily become an excuse to write one enormous change. We maintain that the better habit is to specify, split, size and deliver work as small, independent units.