Técnicas

A engenharia de contexto evoluiu de uma tática de otimização para uma preocupação arquitetural fundamental nos sistemas de IA modernos. Diferentemente da engenharia de prompt, que foca na formulação das palavras, a engenharia de contexto trata a janela de contexto como uma superfície de design e constrói intencionalmente o ambiente de informação da IA. À medida que os agentes lidam com tarefas mais complexas, despejar dados brutos em grandes janelas de contexto leva à "degradação de contexto" e a um raciocínio degradado. Para combater isso, os times estão mudando de prompts estáticos e monolíticos para a divulgação progressiva de contexto. Em vez de carregar antecipadamente todas as instruções e referências de que um agente possa precisar, esses sistemas começam com um índice leve do que está disponível. O agente determina quais prompts ou contextos são relevantes e puxa apenas o que é necessário, mantendo a relação sinal-ruído afiada a cada passo. Estamos vendo várias técnicas amadurecerem neste espaço: A configuração de contexto aproveita o cache de prompt para carregar instruções estáticas antecipadamente, reduzindo custos e melhorando o tempo até o primeiro token. A recuperação dinâmica vai além do RAG básico ao selecionar ferramentas e carregar apenas os servidores MCP necessários, evitando a expansão desnecessária do contexto. Os grafos de contexto modelam o raciocínio institucional — como políticas, exceções e precedentes — como dados estruturados e consultáveis. As técnicas de gerenciamento de contexto usam compressão stateful e subagentes para sumarizar saídas intermediárias em workflows de longa duração. Tratar o contexto da IA como uma caixa de texto estática é um caminho rápido para alucinações. Para construir agentes corporativos resilientes, os times devem projetar a engenharia de contexto como um pipeline dinâmico e gerenciado com precisão.

À medida que os times amadurecem no uso da IA, depender de pessoas desenvolvedoras individuais para escrever prompts do zero está surgindo como um antipadrão. Defendemos as instruções compartilhadas com curadoria para times de software, tratando as orientações da IA como um ativo colaborativo de engenharia em vez de um workflow pessoal. Inicialmente, essa prática focava em manter bibliotecas de prompts de uso geral para tarefas comuns. Agora estamos vendo uma evolução mais eficaz especificamente para ambientes de programação: ancorar essas instruções diretamente nos templates de serviços. Ao colocar arquivos de instrução como CLAUDE.md, AGENTS.md ou .cursorrules no repositório base usado para estruturar novos serviços, o template se torna um poderoso mecanismo de distribuição para a orientação da IA. Durante nossas discussões do Radar, também exploramos uma prática relacionada: ancorar agentes de programação a uma aplicação de referência. Aqui, uma base de código ativa e compilável serve como fonte de verdade. À medida que a arquitetura e os padrões de código evoluem, tanto a aplicação de referência quanto as instruções embutidas podem ser atualizadas. Novos repositórios herdam, então, os workflows e regras mais recentes dos agentes por padrão. Essa abordagem garante que uma assistência de IA consistente e de alta qualidade seja incorporada a cada projeto desde o primeiro dia, enquanto separa as bibliotecas de prompts gerais da configuração de IA específica do repositório.

As métricas definidas pelo programa de pesquisa DORA têm sido amplamente adotadas e provaram ser fortes indicadores de desempenho de uma organização de entrega. Essas métricas incluem lead time para mudanças, frequência de implantação, tempo médio de recuperação (MTTR), taxa de falha em mudanças e a mais nova quinta métrica, a taxa de retrabalho. A taxa de retrabalho é uma métrica de estabilidade que mede quanto do pipeline de entrega de um time é consumido por retrabalho não planejado para corrigir um trabalho considerado concluído anteriormente, como bugs ou defeitos voltados para a pessoa usuária. Na era do desenvolvimento de software assistido por IA, as métricas DORA são mais importantes do que nunca. Medir a produtividade por linhas de código geradas por IA é enganoso; a melhoria real deve ser refletida no fluxo de entrega e na estabilidade. Se os lead times não diminuírem e a frequência de implantação não aumentar, a geração de código mais rápida não se traduzirá em melhores resultados. Por outro lado, a degradação nas métricas de estabilidade — particularmente a taxa de retrabalho — serve como um sinal de alerta precoce sobre pontos cegos, dívida técnica e os riscos do desenvolvimento assistido por IA sem supervisão. Como sempre, recomendamos usar essas métricas para reflexão e aprendizado do time, em vez de apenas construir dashboards complexos. Mecanismos simples, como check-ins durante retrospectivas, costumam ser mais eficazes para melhorar as capacidades do que ferramentas de rastreamento excessivamente detalhadas.

Guiadas pela FIDO Alliance e apoiadas por Apple, Google e Microsoft, as passkeys amadureceram para Adotar (Adopt). Elas são credenciais FIDO2 que podem substituir senhas usando criptografia de chave pública assimétrica. A chave privada é armazenada em um enclave seguro apoiado por hardware no dispositivo da pessoa usuária, protegida por biometria ou um PIN, e nunca sai de lá. Cada credencial é vinculada à origem do seu domínio na parte confiante (relying-party), tornando as chaves de acesso estruturalmente resistentes a phishing: um site sósia não recebe nada, diferente dos códigos OTP por SMS ou TOTP que um proxy de phishing pode interceptar. Com o phishing sendo responsável por mais de um terço de todas as violações de dados, essa resistência estrutural é cada vez mais importante. O FIDO Alliance Passkey Index 2025 relata que existem mais de 15 bilhões de contas elegíveis globalmente, o Google relata uma melhoria de 30% nas taxas de sucesso de login em 800 milhões de pessoas usuárias e a Amazon registrou logins seis vezes mais rápidos do que usando métodos tradicionais. A NIST SP 800-63-4 (julho de 2025) agora classifica as chaves de acesso sincronizadas como em conformidade com AAL2, revertendo orientações anteriores, e reguladores nos Emirados Árabes Unidos, Índia e agências federais dos EUA exigem autenticação resistente a phishing para serviços financeiros e sistemas governamentais. O FIDO Credential Exchange Protocol permite a portabilidade segura de chaves de acesso entre gerenciadores de credenciais, resolvendo preocupações anteriores de vendor lock-in. Os principais provedores de identidade, incluindo Auth0, Okta e Azure AD, agora suportam chaves de acesso como um recurso de primeira classe, e a implementação foi simplificada de um esforço de vários meses para um projeto de duas sprints. Nós adotamos chaves de acesso internamente e as tratamos como o ponto de partida padrão para novas implementações de autenticação. Os times devem projetar a recuperação de contas com cuidado e evitar caminhos de fallback sujeitos a phishing, como SMS OTP, que reintroduz as vulnerabilidades que as chaves de acesso eliminam. Credenciais vinculadas ao dispositivo em chaves de segurança de hardware continuam sendo necessárias para cenários AAL3, como acesso privilegiado.

Saída estruturada de LLMs é a prática de restringir modelos para produzir respostas em um formato pré-definido, como JSON ou uma classe de linguagem de programação específica. Continuamos a ver essa técnica entregar resultados confiáveis em produção e agora nós a consideramos um padrão sensato para aplicações que consomem respostas de LLM de forma programática. Todos os principais provedores de modelos de IA agora oferecem modos nativos para saídas estruturadas, mas as implementações diferem nos subconjuntos de esquemas JSON que suportam, e essas APIs continuam a evoluir rapidamente. Recomendamos o uso de bibliotecas como Instructor ou frameworks como Pydantic AI para fornecer abstrações estável entre provedores, com validação e novas tentativas automáticas, ou Outlines para geração restrita em modelos auto-hospedados.

À medida que entramos na era dos agentes, muitas empresas estão lidando com o desafio de como construí-los e, ao mesmo tempo, endereçar os riscos de segurança que surgem ao conceder autonomia a sistemas imprevisíveis. A arquitetura de confiança zero (zero trust architecture - ZTA) continua sendo um padrão recomendado para construir e operar agentes com segurança. Princípios como "nunca confie, sempre verifique", junto com segurança baseada em identidade e acesso de privilégio mínimo, devem ser tratados como fundamentais para qualquer implantação de agentes. Nossos times estão aplicando padrões como o SPIFFE a agentes, estabelecendo bases sólidas de identidade e permitindo autenticação refinada em ambientes dinâmicos. O monitoramento contínuo e a verificação do comportamento dos agentes também são essenciais para o gerenciamento proativo de ameaças. Além das implantações de agentes, nossos times estão adotando práticas como OIDC impersonation no GCP para diferentes aplicações, incluindo pipelines de CI/CD, substituindo chaves estáticas de longa duração por tokens de curta duração emitidos após a verificação de identidade. Recomendamos que os times tratem os princípios da ZTA como padrões inegociáveis, independentemente do sistema que esteja sendo construído.

À medida que os agentes de IA evoluem de simples interfaces de chat para a execução autônoma de tarefas, a engenharia de contexto se tornou um desafio crítico. As Skills de agentes fornecem um padrão aberto para modularizar o contexto ao empacotar instruções, scripts executáveis e recursos associados, como documentação. Os agentes carregam as Skills apenas quando necessário, com base em suas descrições, o que reduz o consumo de tokens e mitiga o esgotamento da janela de contexto e problemas como o inchaço de instruções de agentes. As Skills foram adotadas muito rapidamente, não apenas em agentes de programação, mas também em assistentes pessoais como o OpenClaw. Elas também são um dos motivos pelos quais os times estão se tornando mais cautelosos em relação a usar o MCP por padrão, já que muitos casos de uso podem ser resolvidos com a mesma eficácia apontando um agente para uma CLI ou script local. À medida que as Skills de agentes cresceram em popularidade, o ecossistema ao redor também se expandiu. Os marketplaces de plugins estão surgindo como uma maneira de versionar e compartilhar Skills, e múltiplos esforços estão explorando como avaliar a eficácia das skills. Nós, no entanto, alertamos contra o reuso não revisado e não verificado de Skills de terceiros, pois elas introduzem sérios riscos de segurança na cadeia de suprimentos.

No passado, ao discutir testes de componentes, nós geralmente desaconselhávamos ferramentas baseadas em navegador. Elas eram difíceis de configurar, lentas para rodar e frequentemente instáveis. Isso melhorou significativamente. Hoje, os testes de componentes baseados em navegador, usando ferramentas como o Playwright, são uma abordagem viável e muitas vezes preferível. Rodar testes em um navegador real fornece mais consistência, já que o teste equivale ao ambiente onde o código realmente é executado. O impacto na performance agora é pequeno o suficiente para que a contrapartida valha a pena. A instabilidade também diminuiu, e estamos vendo mais valor do que em ambientes emulados como o jsdom.

Para tornar os agentes de programação mais eficazes e reduzir a carga sobre os revisores humanos, os times precisam de ciclos de feedback que os agentes possam acessar diretamente. Esses sensores de feedback para agentes de programação agem como uma forma de backpressure, aumentando a confiança nos resultados gerados. As pessoas desenvolvedoras há muito tempo dependem de quality gates determinísticos, como compiladores, linters, testes estruturais e suítes de testes; aqui, eles são integrados aos workflows baseados em agentes de modo que as falhas acionem uma autocorreção oportuna. Essas verificações reduzem o trabalho de direcionamento rotineiro para a pessoa no loop. Os times podem implementá-los de maneiras diferentes, como introduzindo um agente revisor responsável por executar verificações e acionar correções, ou expondo as verificações por meio de um processo complementar em execução paralela que os agentes podem consultar com eficiência. Agentes de programação também tornam mais barato construir linters personalizados e testes estruturais, fortalecendo ainda mais esses ciclos de feedback. Sempre que possível, esses sensores devem ser executados durante a sessão de programação e relatar resultados limpos antes que um commit seja criado, em vez de depender de verificações pós-commit.

Mapear code smells para técnicas de refatoração significa instruir um agente a lidar com problemas específicos com uma abordagem definida. A primeira camada tipicamente aponta o agente para uma referência genérica, como o livro Refactoring, para casos comuns. Para problemas mais especializados, os times podem mapear smells únicos para técnicas específicas usando Skills de agentes, comandos com barra (/) ou o AGENTS.md. Quando integrado com ferramentas de linting, isso cria um feedback determinístico, acionando a abordagem de refatoração apropriada sempre que um smell é detectado. Isso é particularmente eficaz para stacks legadas como .NET Framework 2.0 ou Java 8, onde os dados de treinamento genéricos frequentemente deixam a desejar. Também é útil para times com padrões de engenharia distintos. Sem essas instruções direcionadas, um agente tenderá a adotar padrões genéricos por padrão, em vez de seguir requisitos específicos.

Os testes de mutação continuam sendo o sinal mais honesto para avaliar a real capacidade de detecção de falhas de um conjunto de testes. Diferente da cobertura de código tradicional, que rastreia apenas a execução das linhas do código, essa técnica introduz bugs deliberados, ou mutações, no código-fonte para verificar se os testes falham quando o comportamento quebra. Se uma mutação passa despercebida, isso revela uma lacuna na validação em vez de apenas uma falta de cobertura. Essa distinção é crítica em uma era de desenvolvimento assistido por IA, onde altas porcentagens de cobertura podem mascarar testes logicamente vazios ou códigos gerados que nunca foram validados de forma significativa. Com os casos de teste gerados por IA sendo comuns atualmente, os testes de mutação agem como uma camada de reforço para capturar testes "perpetuamente verdes" — aqueles que passam nos testes independentemente de mudanças lógicas devido à falta de verificações (asserts) ou uso de mocks desacoplados. Ao usar ferramentas como o Stryker, Pitest ou cargo-mutants, mudamos o foco de quanto código é executado para quanto código é realmente verificado, particularmente na lógica central do domínio. O objetivo é garantir que um conjunto de testes passando (passing test suite) seja um sinal confiável da parte funcional estar correta, em vez de simplesmente um relatório de quais linhas foram executadas.

A revelação progressiva de contexto é uma técnica dentro da prática de engenharia de contexto. Em vez de sobrecarregar um agente com instruções logo de cara, você fornece a ele uma fase leve de descoberta na qual ele seleciona o que precisa com base no prompt da pessoa usuária, carregando informações detalhadas na janela de contexto apenas quando elas se tornam relevantes. Isso funciona muito bem para cenários de RAG, onde um agente primeiro identifica o domínio relevante a partir das consultas das pessoas usuárias e, em seguida, recupera instruções e dados específicos de acordo. É também assim que muitas ferramentas de programação baseadas em agentes lidam com as Skills de agentes, determinando primeiro quais skills são relevantes para uma tarefa antes de carregar instruções detalhadas, em vez de fornecer um conjunto de instruções monolítico e único, cheio de condições e ressalvas. Ao construir sistemas baseados em agentes, é fácil cair na armadilha do inchaço de instruções com infinitas regras do que fazer e não fazer na tentativa de controlar o comportamento, o que pode, em última análise, degradar o desempenho. A divulgação progressiva de contexto evita isso ao garantir que o agente receba a orientação certa no momento certo, mantendo a janela de contexto enxuta e prevenindo a degradação de contexto.

Execução em sandbox para agentes de programação é a prática de executar agentes dentro de ambientes isolados com acesso restrito ao sistema de arquivos, conectividade de rede controlada e uso de recursos limitado. À medida que agentes de programação ganham autonomia para executar código, rodar builds e interagir com o sistema de arquivos, conceder acesso irrestrito a um ambiente de desenvolvimento introduz riscos reais, desde danos acidentais até exposição de credenciais. Enxergamos o sandboxing como um padrão sensato por padrão, e não como um aprimoramento opcional.

O leque de opções de sandboxing agora abrange um amplo espectro. Num extremo, muitos agentes de programação oferecem modos sandbox integrados, e Dev Containers fornecem isolamento familiar baseado em contêiner. No outro, ferramentas dedicadas assumem posições diferentes no trade-off entre efêmero e persistente. Shuru sobe microVMs descartáveis que reiniciam a cada execução, enquanto Sprites oferece ambientes com estado com checkpoint e restore. Para isolamento nativo em Linux, Bubblewrap oferece sandboxing leve baseado em namespaces e, no macOS, sandbox-exec oferece proteção semelhante.

Além do isolamento básico, os times devem considerar os requisitos práticos de um sandbox produtivo. Isso inclui tudo o que é necessário para build e testes, bem como autenticação segura e simples com serviços como GitHub e provedores de modelo. Pessoas desenvolvedoras precisam de encaminhamento de portas e CPU e memória suficientes para cargas de trabalho de agentes. Se o sandbox deve ser efêmero por padrão ou persistente para recuperação de sessão é uma decisão de projeto que dependerá das prioridades do time em segurança, custo e continuidade do fluxo de trabalho.

A camada semântica é uma técnica de arquitetura de dados que introduz uma camada de lógica de negócios compartilhada entre os armazenamentos de dados e as aplicações consumidoras, incluindo ferramentas de inteligência de negócios (BI), agentes de IA e APIs. Ela centraliza definições de métricas, joins, regras de acesso e terminologia de negócios para que os consumidores tenham definições compartilhadas. O conceito é anterior à stack de dados moderna, mas tem visto um interesse renovado com abordagens focadas em código, como as lojas de métricas. Sem uma camada semântica comum, a lógica de negócios se dispersa em tabelas ad-hoc de data warehouse, dashboards e aplicações downstream, enquanto as definições de métricas silenciosamente se divergem - o que é particularmente problemático quando usadas para apoiar decisões de negócio. Nossos times viram isso se tornar mais agudo com a IA baseada em agentes: usando LLMs para realizar traduções ingênuas de texto para SQL irá frequentemente produzir resultados incorretos, especialmente quando regras de negócio, como o reconhecimento de receita, existem fora do esquema. As plataformas de nuvem agora estão incorporando camadas semânticas diretamente: o Snowflake chama isso de Semantic Views e o Databricks chama de Metric Views. Ferramentas independentes, como o dbt MetricFlow e o Cube, fornecem uma camada portátil entre sistemas. O recente lançamento do Open Semantic Interchange (OSI) v1.0, apoiado por vários fornecedores, sinaliza uma crescente padronização e interoperabilidade entre plataformas de análise de dados, IA e inteligência de negócios (BI). O custo principal é o investimento inicial em modelagem de dados. Os times devem começar com um único domínio em vez de tentar um rollout em toda a empresa, pois implantações amplas frequentemente deixam relatórios legados rodando em paralelo com a nova camada, reintroduzindo definições inconsistentes.

A UI orientada a servidor está retornando ao anel Trial, pois vemos mais times encurtando com sucesso o caminho para produção. Ao separar a renderização em um contêiner genérico enquanto fornece estrutura e dados por meio do servidor, os times de mobile podem contornar os longos ciclos de revisão das lojas de aplicativos para cada iteração. Vimos que isso melhora significativamente o time to market, com formatos baseados em JSON permitindo atualizações em tempo real. Embora tenhamos alertado anteriormente contra as "bagunças horrendas e excessivamente configuráveis" que frameworks proprietários podem criar, o surgimento de padrões mais estáveis de empresas como Airbnb e Lyft tem ajudado a reduzir a complexidade. Nossa experiência mostra que o investimento substancial exigido para um framework proprietário agora é mais fácil de justificar para aplicações de grande escala. No entanto, isso ainda exige um forte caso de negócios e engenharia disciplinada para evitar a criação de um "protocolo deus" que se torna difícil de manter. Para times que buscam reduzir a complexidade no lado do cliente, essa abordagem fornece uma maneira poderosa de escalar entre os times e sincronizar a lógica em múltiplas plataformas. Recomendamos aplicá-la a áreas altamente dinâmicas de uma aplicação, em vez de usá-la como um substituto geral para todo o desenvolvimento de UI.

Agentic reinforcement learning environments provide a training ground for LLM-based agents, combining the context, tools and feedback to complete multi-step tasks. This approach reframes post-training of LLMs from simple single-turn outputs to agentic behaviors such as reasoning and tool use, with rewards or penalties assigned to each action. Techniques such as RLVR help ensure these rewards are verifiable and resistant to gaming.

AI research labs are currently driving the development of these environments, particularly for coding and computer-use agents. One example outside of the frontier labs is Cursor's Composer, a specialized coding model trained within their product environment. Organizations building agentic systems should consider whether creating reinforcement learning environments could help train more capable and domain-specific models.

Setting up the required infrastructure can be complex. However, frameworks and platforms are emerging to simplify the process, including Prime Intellect's environments hub, Agent Lightning and NVIDIA NeMo Gym. We recommend exploring this approach where it can deliver more capable and cost-effective models for your domain.

Increased use of AI coding agents can accelerate drift from the intended codebase and architecture designs. Left unchecked, this drift compounds as agents and humans replicate existing patterns, including degraded ones, creating a feedback loop where poor code begets poorer code. Some of our teams are now addressing architecture drift reduction with LLMs.

This approach combines deterministic analysis tools (such as Spectral, ArchUnit or Spring Modulith) with LLM-powered evaluation to detect both structural and semantic violations. LLMs are then used to help fix these issues. Our teams have applied this to enforce API quality guidelines across services and to define architectural zones that guide agent-generated improvements.

A few lessons learned: like with traditional linting, initial scans can surface a large number of violations that require triage and prioritization, and LLMs can assist with this process. Keeping agent-produced fixes small and focused makes review easier, and an additional verification loop is essential to confirm changes improve the system rather than introduce regressions.

This technique extends the idea of feedback sensors for coding agents into the later stages of the delivery lifecycle. As one team at OpenAI describes it, drift reduction acts as a form of "garbage collection," reflecting the reality that entropy and decay emerge even in systems with strong early feedback loops.

LLMs process code as a stream of tokens; they have no native understanding of call graphs, type hierarchies or symbol relationships. For code navigation, most coding agents today default to text-based search, the most powerful common denominator across all languages. For refactorings that are a quick shortcut in an IDE, agents need to generate multiple textual diffs. As a result, agents end up spending significant tokens reconstructing information that already exists in the abstract syntax tree (AST).

Code intelligence as agentic tooling gives agents access to tools that are aware of the AST, e.g. via the Language Server Protocol (LSP). Through these integrations, agents can perform operations such as "find all references to this symbol" or "rename this type everywhere" as first-class actions rather than relying on fragile text substitutions. Another powerful code intelligence integration are codemod tools like OpenRewrite, which operates on the even richer Lossless Semantic Tree (LST) representation of the code. The result is fewer hallucinated edits and lower token consumption by delegating appropriate tasks to deterministic tools.

Claude Code, OpenCode and others integrate with locally running LSP servers; JetBrains provides an MCP server that exposes IDE navigation and refactoring capabilities to external agents, while the Serena MCP server offers semantic code retrieval and editing.

A context graph is a knowledge representation technique where decisions, policies, exceptions, precedents, evidence and outcomes are modeled as first-class connected nodes in a graph, structured for AI consumption. Where systems of record capture what happened, a context graph captures why, turning institutional reasoning buried in Slack threads, approval chains and people's heads into a queryable, machine-readable structure. This is vital for agent effectiveness; an agent handling a discount exception, for example, cannot determine whether it reflects standing policy or a one-time override and may reason incorrectly. A context graph can directly surface that provenance, enabling agents to traverse decision traces, apply relevant precedents and reason across multi-hop causal chains.

Unlike GraphRAG, which builds from static document corpora, a context graph maintains temporal validity on every edge, so superseded facts are invalidated rather than overwritten. Context graphs are worth assessing for agentic applications that require persistent memory across sessions or traceable decision reasoning.

Teams working with coding agents are increasingly adopting spec-driven development workflows. Whether they use a lightweight or opinionated framework, these workflows typically follow a similar flow of spec → plan → implement. The feedback flywheel extends this flow with an additional step focused on continuously improving the coding agent harness.

The approach is similar to retrospectives: teams capture successes and failures during a coding agent session and use them to improve the predictability of future sessions, which compounds over time. It’s a meta-technique where a human on the loop focuses on improving the feedforward controls such as curated shared instructions as well as feedback sensors for coding agents. Our teams have found this effective, as it is analogous to code refactoring. The next level looks more like an agentic feedback flywheel, where, based on accumulated feedback, the agent decides what improvements are necessary. For now, however, teams still need a human-in-the-loop to avoid context rot and noisy feedback that could lead the agent astray.

We suggest using this approach to evaluate the entire coding agent harness as your environment evolves, especially when adopting new models; what worked with one model may not be necessary with the next.

Since agentic tools make it easy to build small, task-specific utilities, the main challenge is often how to deploy and share them. HTML Tools is an approach where a shareable script or utility is packaged as a single HTML file. You can run these directly in a browser, host them anywhere, or simply share the file. This approach avoids the overhead of distributing CLI tools, which require sharing binaries or using package managers. It’s also simpler than building a full web application with dedicated hosting. From a security perspective, running untrusted files still carries risk, but the browser sandbox and the ability to inspect source code provide some mitigation. For lightweight utilities, a single HTML file offers a highly accessible and portable way to share tools.

Confabulation, a form of hallucination in LLM QA applications, is difficult to address with traditional evaluation methods. One approach uses information entropy as a measure of uncertainty by analyzing lexical variation in outputs for a given input. LLM evaluation using semantic entropy extends this idea by focusing on differences in meaning rather than surface-level variation.

This approach evaluates meaning rather than word sequences, making it applicable across datasets and tasks without requiring prior knowledge. It generalizes well to unseen tasks, helping identify prompts likely to cause confabulations and encouraging caution when needed. Results show that naive entropy often fails to detect confabulations, while semantic entropy is more effective at filtering false claims.

We’re seeing real productivity gains when using coding agents, but most evaluation metrics still focus too heavily on coding throughput, such as time to first output, lines of code generated and tasks completed. Measuring collaboration quality with coding agents helps teams avoid falling into "the speed trap" by shifting focus toward how effectively humans and agents work together. Metrics such as first-pass acceptance rate, iteration cycles per task, post-merge rework, failed builds and review burden provide more meaningful signals than speed alone. Teams using Claude Code can use the /insights command to generate reports reflecting on successes and challenges from agent sessions. Our teams have also experimented with tracking first-pass acceptance of a customized /review command.

In practice, shorter feedback cycles and fewer failed builds indicate more effective interaction with coding agents. When teams find themselves in repeated back-and-forth with their agents, these metrics highlight opportunities to improve the feedback flywheel. We recommend tracking collaboration quality at the team level, rather than the individual level, alongside DORA metrics to build a more complete picture of coding agent adoption.

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.

The Ralph loop (also sometimes called the Wiggum loop) is an autonomous coding agent technique where a fixed prompt is fed to an agent in an infinite loop. Each iteration starts with a fresh context window: the agent selects a task from a specification or plan, implements it, and the loop restarts with a fresh context. The core insight is simplicity. Rather than orchestrating teams of coding agents or coding agent swarms, a single agent works autonomously against a specification, with the expectation that the codebase will converge toward the spec over repeated iterations. Using a fresh context window on each iteration avoids the quality degradation that comes from accumulated context, though at significant token cost. Tools such as goose have implemented the pattern, in some cases extending it with cross-model review between iterations.

Organizations often struggle with fragmented legacy interfaces where the "design standard" exists only as a loose collection of disjointed webpages, marketing materials and screenshots. Historically, auditing these artifacts to establish a unified foundation has been a manual and time-consuming process. With multimodal LLMs, this extraction can now be automated, effectively reverse-engineering design systems from existing visual assets.

By feeding websites, screenshots and UI fragments into specialized tools or vision-capable AI models, teams can extract core design tokens — such as color palettes, typography scales and spacing rules — and identify recurring component patterns. The AI then synthesizes this unstructured visual data into a structured, semantic representation of a design system. When integrated with tools such as Figma, this output can significantly accelerate the creation of a formalized, maintainable component library.

Beyond reducing effort in visual audits, this technique can serve as a stepping stone toward building "AI-ready" design systems. For enterprises burdened by brownfield design debt, using AI to establish a baseline design system is a practical starting point before a full redesign or front-end standardization.

Role-based contextual isolation in RAG is an architectural technique that moves access control from the application layer down to the retrieval layer. Every data chunk is tagged with role-based permissions at indexing time. At query time, the retrieval engine restricts the search space based on the user's authenticated identity, which is matched against metadata on each chunk. This ensures the AI model cannot access unauthorized context because it’s filtered out at the retrieval stage. This provides a zero trust foundation for internal knowledge bases. As many vector databases now support high-performance metadata filtering, such as Milvus or services built on Amazon S3, this technique has become more practical to adopt, even for large knowledge bases.

Agent Skills, curated shared instructions and many other context engineering techniques appear throughout this edition of the Radar. One use case we want to highlight in the coding context is the use of skills as executable onboarding documentation. This technique applies at multiple levels. Within a codebase, a /_setup skill can take on the role of a go.sh script and a README file, combining scripting with LLM-executed semantics for steps that cannot be scripted. It can also go beyond what a script can do by dynamically taking the current state of the codebase and environment into account. Secondly, library and API creators can provide skills for their consumers as part of their documentation through internal or external skill registries like Tessl. And thirdly, we’ve found this useful for onboarding teams to internal platforms to lower the barrier to using a key technology or reduce friction when adopting a design system. So far, our experience with this has relied heavily on MCP servers but is now shifting toward skills.

As with other forms of documentation, the challenge of keeping this up to date doesn’t go away. However, unlike static documentation, executable documentation can help you notice staleness much earlier.

Small language models (SLMs) continue to improve and are beginning to offer better intelligence per dollar than LLMs for certain use cases. We've seen teams evaluate SLMs to reduce inference costs and speed up agentic workflows. Recent progress shows steady gains in intelligence density, making SLMs competitive with older LLMs for tasks such as summarization and basic coding. This shift reflects a move away from "bigger is better" toward higher-quality data, model distillation and quantization. Models such as Phi-4-mini and Ministral 3 3B demonstrate how distilled models can retain many capabilities of larger teacher models. Even ultra-compact models such as Qwen3-0.6B and Gemma-3-270M are becoming viable for running models on edge devices. For agentic use cases where older LLMs have been sufficient, teams should consider SLMs as a lower-cost, lower-latency alternative with reduced resource requirements.

In the previous Radar, we described a team of coding agents as a technique where a developer orchestrates a small set of role-specific agents to collaborate on a coding task. Since then, the barrier to adoption has dropped. Subagent support has become more of a table stakes feature across established coding agent tools, and Claude Code now includes an agent teams feature that provides built-in orchestration. In a team of agents, a primary orchestrator typically coordinates task sequencing and parallelization. Agents should be able to communicate not only with the orchestrator but also with one another. Common use cases include teams of reviewers or groups of implementers responsible for different parts of the application, such as backend and frontend.

Although some in the industry are using the terms "agent teams" and "agent swarms" interchangeably (for example, Claude Code describes its agent teams feature as "our implementation of swarms"), we see value in distinguishing between them. A small, deliberate team of agents collaborating on a task differs significantly from a large swarm in terms of entry barriers, complexity and use cases.

Temporal fakes extend the idea of simulating real-world systems for development and testing, a practice long used in IoT and industrial platforms. With AI coding agents reducing the effort required to build such simulators, teams can now create high-fidelity replicas of external dependencies much more easily. Unlike traditional mocks that return static request–response pairs, temporal fakes maintain internal state machines and model the temporal evolution of real systems.

One of our teams used this technique while developing an observability stack for large GPU data centers, avoiding the need to procure physical hardware. Testing alert rules, dashboards and anomaly detection against real systems can be impractical — for example, intentionally overheating a GPU to validate a thermal throttle alert. Instead, the team built fakes for hardware domains such as NVIDIA DCGM and InfiniBand fabric using Go. These simulators enabled failure scenarios such as thermal throttling, XID error storms, link flaps and PSU failures with configurable intensity and duration, orchestrated via a process-compose stack.

A central registry defined valid failure scenarios, while an MCP server exposed scenario injection to the agent. The agent could trigger faults, for example, injecting a thermal throttle on a specific GPU and verify that metrics changed, alerts fired and dashboards updated as expected. This temporal fidelity makes the technique valuable for testing complex systems where failures cascade. However, teams must ensure the fakes remain faithful to real-world behaviour; otherwise, they risk creating false confidence in automated pipelines.

Agent capabilities are outpacing security practices. With the rise of permission-hungry agents like OpenClaw, teams are increasingly deploying agents in environments that expose them to the lethal trifecta: access to private data, exposure to untrusted content and the ability to communicate externally. As capabilities grow, so too does the attack surface, exposing systems to risks such as prompt injection and tool poisoning. We continue to see toxic flow analysis as a primary technique for examining agentic systems to identify unsafe data paths and potential attack vectors. These risks are no longer limited to MCP integrations; our teams have observed similar patterns in Agent Skills, where a malicious actor can package a seemingly useful skill that embeds hidden instructions to exfiltrate sensitive data. We strongly encourage teams working with agents to perform toxic flow analysis and use tools such as Agent Scan to identify unsafe data paths before they're exploited.

Document parsing often relies on multi-stage pipelines combining layout detection, traditional OCR and post-processing scripts. These approaches often struggle with complex layouts and mathematical formulas. Vision language models (VLMs) for end-to-end document parsing simplify this architecture by treating the document image as a single input modality, preserving natural reading order and structured content. Open-source models specifically trained for this purpose — such as olmOCR-2, the token-efficient DeepSeek-OCR (3B) and the ultra-compact PaddleOCR-VL — have yielded highly efficient results. While VLMs reduce architectural complexity by replacing multi-stage pipelines, their generative nature makes them prone to hallucinations. Use cases with a low tolerance for error may still require a hybrid approach or deterministic OCR. Teams dealing with high-volume document ingestion should evaluate these unified approaches to determine whether they can replace complex legacy pipelines while maintaining accuracy and reducing long-term maintenance overhead.

Context files such as AGENTS.md and CLAUDE.md tend to accumulate over time as teams add codebase overviews, architectural explanations, conventions and rules. While each addition is useful in isolation, this often leads to agent instruction bloat. Instructions become long and sometimes conflict with each other. Models tend to attend less to content buried in the middle of long contexts, so guidance deep in a long conversation history can be missed. As instructions grow, the likelihood increases that important rules are ignored. We also see many teams using AI to generate AGENTS.md files, but research suggests that hand-written versions are often more effective than LLM-generated ones. When using agentic tools, be deliberate and selective with instructions, adding them as needed and continuously refine toward a minimal, coherent set. Consider leveraging progressive context disclosure to surface only the instructions and capabilities an agent needs for its current task.

AI continues to lower the barriers for noncoders to build complex systems. While this enables experimentation and early validation of requirements, it also introduces the risk of AI-accelerated shadow IT. In addition to no-code workflow platforms integrating AI APIs (e.g., OpenAI or Anthropic), more agentic tools are becoming available to noncoders, such as Claude Cowork.

When the spreadsheet that quietly runs the business evolves into customized agentic workflows that lack governance, it introduces significant security risks and a proliferation of competing solutions to similar problems. Distinguishing between disposable, one-off workflows and critical processes that require durable, production-ready implementation is key to balancing experimentation with control.

Organizations should prioritize governance as part of their AI adoption strategy by facilitating experimentation within controlled environments. Appropriately instrumented Internal sandboxes give noncoders a place to deploy prototypes where usage can be tracked. Pairing these with a shared catalogue of existing workflows helps teams discover what's already been built before duplicating effort. Workflows that gain traction can then signal where to invest in more robust, production-grade applications.

Codebase cognitive debt is the growing gap between a system’s implementation and a team’s shared understanding of how and why it works. As AI increases change velocity, especially with multiple contributors or Coding Agent Swarms, teams can lose track of design intent and hidden coupling. This, combined with rising technical debt, creates a reinforcing loop that makes systems progressively harder to reason about.

Weaker system understanding also reduces developers’ ability to guide AI effectively, making it harder to anticipate edge cases and steer agents away from architectural pitfalls. Left unmanaged, teams reach a tipping point where small changes trigger unexpected failures, fixes introduce regressions and cleanup efforts increase risk instead of reducing it.

Teams should avoid complacency with AI-generated code and adopt explicit countermeasures: feedback sensors for coding agents, tracking team cognitive load and architectural fitness functions to continuously enforce key constraints as AI accelerates output.

Where a team of coding agents is a small, deliberate group, a coding agent swarm applies dozens to hundreds of agents to a problem, with AI determining composition and size dynamically. Projects such as Gas Town and Ruflo (formerly Claude Flow) are good examples of this approach. Early patterns for swarm implementations are emerging: hierarchical role separation (orchestrators, supervisors and ephemeral workers), a durable work ledger that helps agents divide and coordinate work (Gas Town uses beads for this) and a merging mechanism to handle conflicts from parallel work.

Two swarm experiments have drawn particular attention: Anthropic's C compiler generation and Cursor's agent scaling experiment that created a browser over a week. It's worth noting that both teams chose use cases that could rely on existing detailed specifications, and in the case of the C compiler, comprehensive test suites that provide clear, measurable feedback. Those conditions are not representative of typical product development, where requirements are less defined and verification is harder. Nevertheless, these experiments contribute to emerging patterns for making long-running swarms technically viable. They remain costly and are still far from mature, which is why we advise caution when adopting this technique.

AI coding assistants are delivering real productivity gains and are rapidly becoming standard developer tooling. However, we’re increasingly seeing organizations measure success using superficial indicators such as lines of code generated or the number of pull requests (PRs). When these coding throughput metrics are used in isolation, they can negatively shape employee behavior. The result is often a flood of poorly aligned code that slows reviews, harms delivery throughput and introduces security risks. Cycle times increase as engineers raise PRs filled with insufficiently reviewed AI output, leading to repeated back-and-forth with reviewers. These metrics fail to capture the residual effort required to adapt AI-generated code to a team's architecture, conventions and patterns.

More meaningful leading indicators exist, such as first-pass acceptance rate — how often AI output can be used with minimal rework. Measuring this exposes hidden effort and makes improvement actionable: teams can refine prompts, improve priming documents and strengthen design conversations to progressively increase acceptance over time. This creates a virtuous cycle in which AI output requires less correction. First-pass acceptance also connects naturally with DORA metrics: lower acceptance rates tend to increase change failure rates, while repeated iteration cycles extend lead time for changes. As AI assistants become ubiquitous, organizations should shift focus away from coding throughput alone toward metrics that reflect real impact and delivery outcomes.

Ignoring durability in agent workflows is an anti-pattern we’ve seen across many teams, resulting in systems that work in development but fail in production. The challenges facing distributed systems are even more pronounced when building with agents. A mindset that expects failures and recovers gracefully outpaces a reactive approach.

LLM and tool calls can fail due to network interruptions and server crashes, halting an agent's progress and leading to poor user experience and increased operational costs. Some systems can tolerate this when tasks are short-lived, but complex workflows that run for days or weeks require durability.

Fortunately, durable execution is being integrated into agent frameworks such as LangGraph and Pydantic AI. It provides stateful persistence of progress and tool calls, enabling agents to resume tasks after failures. For workflows that involve a human in the loop, durable execution can suspend progress while awaiting input. Durable computing platforms such as Temporal, Restate and Golem also provide support for agents. Built-in observability of tool execution and decision tracking makes debugging easier and improves understanding of systems in production. Teams should start with native durable execution support in their agent framework and reach for standalone platforms as workflows become more critical or complex.

As the Model Context Protocol (MCP) gains traction, we're seeing teams and vendors reach for it as the default integration layer between AI agents and external systems, even when simpler alternatives exist. We caution against using MCP by default. MCP adds real value for structured tool contracts, OAuth-based authentication boundaries and governed multi-tenant access. It also introduces what Justin Poehnelt calls an "abstraction tax": every protocol layer between an agent and an API loses fidelity, and for complex APIs those losses compound.

In practice, a well-designed CLI with good --help output, structured JSON responses and predictable error handling often gives agents everything they need without the protocol overhead. As Simon Willison notes, "almost everything I might achieve with an MCP can be handled by a CLI tool instead."

This isn't a rejection of MCP. Teams should avoid adopting it by default and first ask whether their system actually requires protocol-level interoperability. MCP makes sense when its governance and integration benefits outweigh the added complexity and potential fidelity loss.

Pixel-streamed development environments use VDI-style remote desktops or workstations for software development, with editing, builds and debugging performed through a streamed desktop rather than on a local machine or a code-centric remote environment. We continue to see organizations adopt them to meet security, standardization and onboarding goals, especially for offshore teams and lift-and-shift cloud programs. In practice, however, the trade-off is often poor: latency, input lag and inconsistent screen responsiveness create constant cognitive friction that slows delivery and makes everyday development work more tiring. Unlike development environments in the cloud such as Google Cloud Workstations or tools like Coder and VS Code Remote Development, which move compute closer to the code without streaming the entire desktop, pixel-streamed setups prioritize centralized control over developer flow and are often imposed with too little input from the engineers who use them. We advise against pixel-streamed development environments as a default choice for software delivery unless a compelling security or regulatory constraint clearly outweighs the productivity cost.