Techniques 

Context engineering has evolved from an optimization tactic into a foundational architectural concern for modern AI systems. Unlike prompt engineering, which focuses on wording, context engineering treats the context window as a design surface and intentionally constructs the AI’s information environment.

As agents tackle more complex tasks, dumping raw data into large context windows leads to "context rot" and degraded reasoning. To combat this, teams are shifting from static, monolithic prompts to progressive context disclosure. Instead of front-loading every instruction and reference an agent might need, these systems start with a lightweight index of what's available. The agent determines what prompts or contexts are relevant and pulls in only what’s needed, keeping the signal-to-noise ratio sharp at every step.

We’re seeing several techniques mature in this space: Context setup leverages prompt caching to front-load static instructions, reducing costs and improving time to first token. Dynamic retrieval goes beyond basic RAG by selecting tools and loading only the necessary MCP servers, avoiding unnecessary context expansion. Context graphs model institutional reasoning — such as policies, exceptions and precedents — as structured, queryable data. Context management techniques use stateful compression and sub-agents to summarize intermediate outputs in long-running workflows.

Treating AI context as a static text box is a fast track to hallucinations. To build resilient enterprise agents, teams must engineer context as a dynamic, precisely managed pipeline.

As teams mature in their use of AI, relying on individual developers to write prompts from scratch is emerging as an anti-pattern. We advocate for curated shared instructions for software teams, treating AI guidance as a collaborative engineering asset rather than a personal workflow.

Initially, this practice focused on maintaining general-purpose prompt libraries for common tasks. We’re now seeing a more effective evolution specifically for coding environments: anchoring these instructions directly into service templates. By placing instruction files such as CLAUDE.md, AGENTS.md or .cursorrules into the baseline repository used to scaffold new services, the template becomes a powerful distribution mechanism for AI guidance.

During our Radar discussions, we also explored a related practice: anchoring coding agents to a reference application. Here, a live, compilable codebase serves as the source of truth. As architecture and coding standards evolve, both the reference application and embedded instructions can be updated. New repositories then inherit the latest agent workflows and rules by default. This approach ensures consistent, high-quality AI assistance is built into every project from day one, while separating general prompt libraries from repository-specific AI configuration.

The metrics defined by the DORA research program have been widely adopted and have proven to be strong leading indicators of how a delivery organization is performing. These include change lead time, deployment frequency, mean time to restore (MTTR), change failure rate and a newer fifth metric, rework rate. Rework rate is a stability metric that measures how much of a team's delivery pipeline is consumed by unplanned rework to fix work previously considered complete, such as user-facing bugs or defects.

In the era of AI-assisted software development, the DORA metrics are more important than ever. Measuring productivity by lines of code generated by AI is misleading; real improvement must be reflected in delivery flow and stability. If lead times don’t decrease and deployment frequency doesn't increase, faster code generation doesn’t translate into better outcomes. Conversely, degradation in stability metrics — particularly rework rate — provides an early warning sign of blind spots, technical debt and the risks of unchecked AI-assisted development.

As always, we recommend using these metrics for team reflection and learning rather than just building complex dashboards. Simple mechanisms, such as check-ins during retrospectives, are often more effective than overly detailed tracking tools at improving capabilities.

Shepherded by the FIDO Alliance and backed by Apple, Google and Microsoft, passkeys have matured into Adopt. They are FIDO2 credentials that can replace passwords using asymmetric public-key cryptography. The private key is stored in a hardware-backed secure enclave on the user's device, protected by biometrics or a PIN, and never leaves it. Each credential is origin-bound to its relying-party domain, making passkeys structurally phishing-resistant: a lookalike site receives nothing, unlike SMS OTP or TOTP codes that a phishing proxy can intercept.

With phishing responsible for more than one third of all data breaches, this structural resistance is increasingly important. The FIDO Alliance Passkey Index 2025 reports there are over 15 billion eligible accounts globally, Google reports a 30% improvement in sign-in success rates across 800 million users and Amazon has seen sign-ins six times faster than using traditional methods. NIST SP 800-63-4 (July 2025) now classifies synced passkeys as AAL2-compliant, reversing earlier guidance, and regulators in the UAE, India and US federal agencies mandate phishing-resistant authentication for financial services and government systems.

The FIDO Credential Exchange Protocol enables secure portability of passkeys between credential managers, addressing earlier vendor lock-in concerns. Major identity providers including Auth0, Okta and Azure AD now support passkeys as a first-class feature, and implementation has been simplified from a multi-month effort to a two-sprint project. We’ve adopted passkeys internally and treat them as the default starting point for new authentication implementations. Teams should design account recovery carefully and avoid phishable fallback paths such as SMS OTP, which reintroduce the vulnerabilities passkeys eliminate. Device-bound credentials on hardware security keys remain necessary for AAL3 scenarios such as privileged access.

Structured output from LLMs is the practice of constraining models to produce responses in a predefined format, such as JSON or a specific programming language class. We continue to see this technique deliver reliable results in production, and we now consider it a sensible default for applications that consume LLM responses programmatically. All major model providers now offer native structured output modes, but implementations differ in the JSON Schema subsets they support, and these APIs continue to evolve rapidly. We recommend using a library such as Instructor or a framework like Pydantic AI to provide a stable abstraction across providers with validation and automatic retries, or Outlines for constrained generation on self-hosted models.

As we enter the age of agents, many enterprises are grappling with how to build them while addressing the security risks of granting autonomy to unpredictable systems. Zero trust architecture (ZTA) remains a sensible default for securely building and operating agents. Principles such as "never trust, always verify," along with identity-based security and least-privilege access, should be treated as foundational for any agent deployment. Our teams are applying standards like SPIFFE to agents, establishing strong identity foundations and enabling fine-grained authentication in dynamic environments. Continuous monitoring and verification of agent behavior are also critical for proactively managing threats. Beyond agent deployments, our teams are adopting practices such as OIDC impersonation in GCP for different applications, including CI/CD pipelines, replacing long-lived static keys with short-lived tokens issued after identity verification. We recommend teams treat ZTA principles as non-negotiable defaults, regardless of the system being built.

As AI agents evolve from simple chat interfaces toward autonomous task execution, context engineering has become a critical challenge. Agent Skills provide an open standard for modularizing context by packaging instructions, executable scripts and associated resources such as documentation. Agents load skills only when needed based on their descriptions, which reduces token consumption and mitigates context window exhaustion and problems such as agent instruction bloat.

Skills have been adopted very quickly, not only in coding agents but also in personal assistants such as OpenClaw. They’re also one reason teams are becoming more cautious about defaulting to MCP, as many use cases can be addressed just as effectively by pointing an agent at a local CLI or script.

As their popularity has grown, the surrounding ecosystem has expanded as well. Plugin marketplaces are emerging as a way to version and share skills, and multiple efforts are exploring how to evaluate skill effectiveness. We do, however, caution against unreviewed reuse of third-party skills, as they introduce serious supply chain security risks.

In the past, when discussing component testing, we’ve generally advised against browser-based tools. They were difficult to set up, slow to run and often flaky. This has improved significantly. Today, browser-based component testing, using tools such as Playwright, is a viable and often preferable approach. Running tests in a real browser provides more consistency, as the test matches the environment where the code actually executes. The performance hit is now small enough that the trade-off is worthwhile. Flakiness has also decreased, and we’re seeing more value than from emulated environments such as jsdom.

To make coding agents more effective and reduce the load on human reviewers, teams need feedback loops that agents can directly access. These feedback sensors for coding agents act as a form of feedback backpressure, increasing trust in generated results. Developers have long relied on deterministic quality gates such as compilers, linters, structural tests and test suites; here, they’re wired into agentic workflows so that failures trigger timely self-correction.

These checks reduce routine steering work for the human in the loop. Teams can implement them in different ways, such as introducing a reviewer agent responsible for running checks and triggering corrections, or by exposing the checks through a companion process that runs in parallel that agents can query efficiently. Coding agents also make it cheaper to build custom linters and structural tests, further strengthening these feedback loops. Whenever possible, these sensors should run during the coding session and report clean results before a commit is made, rather than relying on post-commit checks.

Mapping code smells to refactoring techniques means instructing an agent to handle specific issues with a defined approach. The first layer typically points the agent to a generic reference, such as Refactoring, for common cases. For more specialized issues, teams can map unique smells to specific techniques using Agent Skills, slash commands or AGENTS.md. When integrated with linting tools, this creates deterministic feedback by triggering the appropriate refactoring approach whenever a smell is detected.

This is particularly effective for legacy stacks like .NET Framework 2.0 or Java 8, where generic training data often falls short. It’s also useful for teams with distinctive engineering standards. Without these targeted instructions, an agent will tend to default to generic patterns rather than follow specific requirements.

Mutation testing remains the most honest signal for evaluating the real fault-detection capability of a test suite. Unlike traditional code coverage, which only tracks line execution, this technique introduces deliberate bugs, or mutations, into source code to verify that tests fail when behavior breaks. If a mutation goes undetected, it reveals a gap in validation rather than just a lack of coverage. This distinction is critical in an era of AI-assisted development, where high coverage percentages can mask logically hollow tests or generated code that has never been meaningfully asserted.

With AI-generated test cases now commonplace, mutation testing acts as a reinforcement layer for catching "perpetually green" tests — those that pass regardless of logic changes due to missing assertions or decoupled mocks. By using tools such as Stryker, Pitest or cargo-mutants, we shift the focus from how much code is executed to how much code is actually verified, particularly in core domain logic. The goal is to ensure that a passing test suite is a reliable signal of functional correctness, rather than simply a report of which lines were executed.

Progressive context disclosure is a technique within the practice of context engineering. Instead of overwhelming an agent with instructions upfront, you give it a lightweight discovery phase in which it selects what it needs based on the user’s prompt, loading detailed information into the context window only when it becomes relevant.

This works great for RAG scenarios, where an agent first identifies the relevant domain from user queries and then retrieves specific instructions and data accordingly. It’s also how many agentic coding tools handle Agent Skills by first determining which skills are relevant to a task before loading detailed instructions, rather than providing a single, monolithic instruction set filled with conditions and caveats. When building agentic systems, it’s easy to fall into the trap of bloating instructions with endless "DO" and "DO NOT" rules in an attempt to control behavior, which can ultimately degrade performance. Progressive context disclosure avoids this by ensuring the agent receives the right guidance at the right moment, keeping the context window lean and preventing context rot.

Sandboxed execution for coding agents is the practice of running agents inside isolated environments with restricted file system access, controlled network connectivity and bounded resource usage. As coding agents gain autonomy to execute code, run builds and interact with the file system, giving agents unrestricted access to a development environment introduces real risks, from accidental damage to credential exposure. We see sandboxing as a sensible default rather than an optional enhancement.

The landscape of sandboxing options now spans a broad spectrum. At one end, many coding agents offer built-in sandbox modes, and Dev Containers provide familiar container-based isolation. At the other, purpose-built tools take different positions on the ephemeral versus persistent trade-off. Shuru boots disposable microVMs that reset on every run, while Sprites(/radar/platforms/sprites) provides stateful environments with checkpoint and restore. For Linux-native isolation, Bubblewrap offers lightweight namespace-based sandboxing, and on macOS, sandbox-exec provides similar protection.

Beyond basic isolation, teams should consider the practical requirements of a productive sandbox. This includes everything needed for building and testing, as well as secure, straightforward authentication with services like GitHub and model providers. Developers need port forwarding and sufficient CPU and memory for agent workloads. Whether the sandbox should be ephemeral by default or persistent for session recovery is a design decision that will depend on a team's priorities for security, cost and workflow continuity.

Semantic layer is a data architecture technique that introduces a shared business logic layer between raw data stores and consuming applications, including business intelligence (BI) tools, AI agents and APIs. It centralizes metric definitions, joins, access rules and business terminology so consumers have shared definitions. The concept predates the modern data stack but has seen renewed interest with code-first approaches such as metrics stores.

Without a semantic layer, business logic scatters across ad-hoc warehouse tables, dashboards, and downstream applications, while metric definitions quietly diverge—particularly problematic when used to support business decisions. Our teams have seen this become more acute with agentic AI: using LLMs to perform naive text-to-SQL translations will frequently produce incorrect results, especially when business rules, such as revenue recognition, live outside the schema. Cloud platforms are now embedding semantic layers directly: Snowflake calls it Semantic Views and Databricks calls it Metric Views. Standalone tools such as dbt MetricFlow and Cube provide a portable layer across systems. The recent release of Open Semantic Interchange (OSI) v1.0, backed by multiple vendors, signals growing standardization and interoperability across analytics, AI, and BI platforms.

The main cost is upfront data modeling investment. Teams should start with a single domain rather than attempting an enterprise-wide rollout, as broad deployments often leave legacy reports running in parallel with the new layer, reintroducing inconsistent definitions.

Server-driven UI is returning to the Trial ring as we see more teams successfully shortening their path to production. By separating rendering into a generic container while providing structure and data via the server, mobile teams can bypass lengthy app store review cycles for every iteration. We’ve seen this significantly improve time to market, with JSON-based formats enabling real-time updates. While we previously cautioned against the "horrendous, overly configurable messes" that proprietary frameworks can create, the emergence of more stable patterns from companies such as Airbnb and Lyft has helped reduce complexity.

Our experience shows that the substantial investment required for a proprietary framework is now easier to justify for large-scale applications. However, it still requires a strong business case and disciplined engineering to avoid creating a "god-protocol" that becomes difficult to maintain. For teams looking to reduce client-side complexity, this approach provides a powerful way to scale across teams and synchronize logic across platforms. We recommend applying it to highly dynamic areas of an application rather than as a blanket replacement for all UI development.

Os ambientes de aprendizado por reforço baseados em agentes fornecem um campo de treinamento para agentes baseados em LLM, combinando o contexto, as ferramentas e o feedback para concluir tarefas de múltiplas etapas. Essa abordagem reformula o pós-treinamento de LLMs, passando de saídas simples de turno único (single-turn) para comportamentos baseados em agentes, como raciocínio e uso de ferramentas, com recompensas ou penalidades atribuídas a cada ação. Técnicas como o RLVR ajudam a garantir que essas recompensas sejam verificáveis e resistentes a manipulações. Laboratórios de pesquisa em IA estão atualmente impulsionando o desenvolvimento desses ambientes, particularmente para agentes de programação e de uso de computador. Um exemplo fora dos laboratórios de fronteira é o Cursor's Composer, um modelo de programação especializado treinado dentro do ambiente de seu produto. As organizações que constroem sistemas baseados em agentes devem considerar se a criação de ambientes de aprendizado por reforço poderia ajudar a treinar modelos mais capazes e específicos para o seu domínio. Configurar a infraestrutura necessária pode ser complexo. No entanto, frameworks e plataformas estão surgindo para simplificar o processo, incluindo o environments hub da Prime Intellect, o Agent Lightning e o NVIDIA NeMo Gym. Recomendamos explorar essa abordagem onde ela possa entregar modelos mais capazes e com melhor custo-benefício para o seu domínio.

O uso crescente de agentes de programação de IA pode acelerar a deriva da base de código e dos designs de arquitetura planejadas. Se não for controlado, esse desvio se acumula à medida que agentes e humanos replicam padrões existentes, inclusive os já degradados, criando um ciclo de feedback onde código ruim gera código ainda pior. Alguns de nossos times agora estão abordando a redução de desvio de arquitetura com LLMs. Essa abordagem combina ferramentas de análise determinística (como Spectral, ArchUnit ou Spring Modulith com avaliação baseada em LLMs para detectar violações estruturais e semânticas. Os LLMs são então usados para ajudar a corrigir esses problemas. Nossos times aplicaram essa abordagem para impor diretrizes de qualidade de API nos serviços e para definir zonas arquiteturais que orientam as melhorias geradas por agentes. Algumas lições aprendidas: assim como no linting tradicional, as varreduras iniciais podem trazer à tona um grande número de violações que exigem triagem e priorização, e os LLMs podem ajudar nesse processo. Manter pequenas e pontuais correções geradas por agentes facilita a revisão, e um ciclo de verificação adicional é essencial para confirmar que as mudanças melhoram o sistema em vez de introduzir regressões. Essa técnica estende a ideia de mecanismos de feedback para agentes de programação para os estágios finais do ciclo de vida de entrega. Como um time da OpenAI descreve, a redução de desvio funciona como uma espécie de "garbage collection", refletindo a realidade de que entropia e deterioração surgem até mesmo em sistemas com fortes ciclos de feedback iniciais.

Os LLMs processam código como um fluxo de tokens; eles não têm compreensão nativa de diagramas de chamada (call graphs), hierarquias de tipo ou relacionamentos de símbolos. Para a navegação de código, a maioria dos agentes de programação de hoje adotam por padrão a busca baseada em texto, o denominador comum mais poderoso entre todas as linguagens. Para refatorações que são um atalho rápido em uma IDE, os agentes precisam gerar múltiplos diffs textuais. Como resultado, os agentes acabam gastando tokens significativos reconstruindo informações que já existem na árvore sintática abstrata (abstract syntax tree - AST). A inteligência de código como ferramenta para agentes dão aos agentes acesso a ferramentas que estão cientes da AST, por exemplo, via Language Server Protocol (LSP). Por meio dessas integrações, os agentes podem executar operações como "encontrar todas as referências a este símbolo" ou "renomear este tipo em todos os lugares" como ações de primeira classe, em vez de depender de substituições de texto frágeis. Outra integração poderosa de inteligência de código são as ferramentas de “codemod” como o OpenRewrite, que opera na representação ainda mais rica de Lossless Semantic Tree (LST) do código. O resultado são menos edições com alucinações e menor consumo de tokens ao delegar tarefas apropriadas a ferramentas determinísticas. Claude Code, OpenCode e outros se integram a servidores LSP rodando localmente; a JetBrains fornece um servidor MCP que expõe capacidades de navegação e refatoração da IDE para agentes externos, enquanto o servidor MCP Serena oferece recuperação semântica de código e edição.

O Context Graph é uma técnica de representação de conhecimento onde decisões, políticas, exceções, precedentes, evidências e resultados são modelados como nós conectados de primeira classe em um grafo, estruturados para consumo por IA. Enquanto os sistemas de registro capturam o que aconteceu, um grafo de contexto captura o porquê, transformando o raciocínio institucional enterrado em threads do Slack, cadeias de aprovação e na cabeça das pessoas em uma estrutura consultável e legível por máquina. Isso é vital para a eficácia dos agentes; um agente lidando com uma exceção de desconto, por exemplo, não consegue determinar se isso reflete uma política vigente ou uma exceção pontual, e pode raciocinar incorretamente. Um grafo de contexto pode expor diretamente essa procedência, permitindo que os agentes percorram rastros de decisão, apliquem precedentes relevantes e raciocinem através de cadeias causais multi-hop. Diferentemente do GraphRAG, que é construído a partir de corpora de documentos estáticos, um grafo de contexto mantém a validade temporal em cada aresta, de modo que fatos superados são invalidados em vez de sobrescritos. Vale a pena avaliar os grafos de contextos para aplicações baseadas em agentes que exigem memória persistente entre sessões ou raciocínio de decisão rastreável.

Equipes que trabalham com agentes de programação estão adotando cada vez mais fluxos de trabalho de desenvolvimento orientado a especificações. Quer utilizem um framework leve ou mais diretivo, esses fluxos geralmente seguem uma sequência semelhante de especificação → planejamento → implementação. O flywheel de feedback estende esse fluxo com uma etapa adicional focada em melhorar continuamente a estrutura (harness) do agente de programação. A abordagem é semelhante às retrospectivas: as equipes capturam sucessos e falhas durante uma sessão do agente de programação e os usam para melhorar a previsibilidade de sessões futuras, o que gera ganhos cumulativos ao longo do tempo. É uma metatécnica na qual um humano na supervisão (human-on-the-loop) se concentra em melhorar os controles proativos (feedforward), como instruções compartilhadas com curadoria, bem como sensores de feedback para agentes de programação. Nossas equipes consideram essa prática eficaz, pois é análoga à refatoração de código. O próximo nível se parece mais com um flywheel de feedback baseado em agentes, onde, com base no feedback acumulado, o próprio agente decide quais melhorias são necessárias. Por enquanto, no entanto, as equipes ainda precisam de um humano no circuito (human-in-the-loop) para evitar a degradação de contexto e um feedback ruidoso que poderia desviar o agente do seu objetivo. Sugerimos utilizar essa abordagem para avaliar toda a estrutura (harness) do agente de programação à medida que seu ambiente evolui, especialmente ao adotar novos modelos; o que funcionou com um modelo pode não ser necessário com o próximo.

Como as ferramentas agênticas facilitam a construção de pequenos utilitários específicos para tarefas, o principal desafio costuma ser como implantá-los e compartilhá-los. HTML Tools é uma abordagem em que um script ou utilitário compartilhável é empacotado como um único arquivo HTML. Você pode rodá-los diretamente em um navegador, hospedá-los em qualquer lugar ou simplesmente compartilhar o arquivo. Essa abordagem evita o overhead de distribuir ferramentas de CLI, o que exige o compartilhamento de binários ou o uso de gerenciadores de pacotes. Também é mais simples do que construir uma aplicação web completa com hospedagem dedicada. De uma perspectiva de segurança, rodar arquivos não confiáveis ainda traz riscos, mas o sandbox do navegador e a capacidade de inspecionar o código-fonte fornecem alguma mitigação. Para utilitários leves, um único arquivo HTML oferece uma maneira altamente acessível e portátil de compartilhar ferramentas.

A confabulação, uma forma de alucinação em aplicações de perguntas e respostas (QA) com LLMs, é difícil de abordar com métodos de avaliação tradicionais. Uma abordagem usa a entropia da informação como uma medida de incerteza, analisando a variação lexical nas respostas geradas para a mesma entrada. A avaliação de LLMs usando entropia semântica estende essa ideia focando nas diferenças de significado em vez da variação superficial. Essa abordagem avalia o significado em vez de sequências de palavras, tornando-a aplicável a diversos conjuntos de dados e tarefas sem exigir conhecimento prévio. Ela se generaliza bem para tarefas não vistas, ajudando a identificar prompts com maior probabilidade de gerar confabulações e indicando quando é preciso ter cautela. Os resultados mostram que a entropia simples frequentemente falha em detectar confabulações, enquanto a entropia semântica é mais eficaz para filtrar afirmações falsas.

Estamos vendo ganhos reais de produtividade ao usar agentes de programação, mas a maioria das métricas de avaliação ainda foca excessivamente na taxa de transferência de programação, como o tempo até o primeiro output, linhas de código geradas e tarefas concluídas. Medir a qualidade da colaboração com agentes de programação ajuda os times a evitar cair na "armadilha da velocidade", mudando o foco para quão bem humanos e agentes trabalham juntos. Métricas como a taxa de aceitação na primeira tentativa, ciclos de iteração por tarefa, retrabalho pós-merge, builds que falharam e a carga de revisão fornecem sinais mais significativos do que apenas a velocidade. Times que usam o Claude Code podem usar o comando /insights para gerar relatórios que mostram os acertos e gargalos das sessões com agentes. Nossos times também têm feito testes para acompanhar a taxa de aprovação na primeira tentativa ao usar um comando /review customizado. Na prática, ciclos de feedback mais curtos e menos builds quebrados indicam uma interação mais eficaz com os agentes de programação. Quando os times se encontram em repetidas idas e vindas com seus agentes, essas métricas destacam oportunidades para melhorar o flywheel de feedback. Recomendamos rastrear a qualidade da colaboração no nível do time, em vez do nível individual, juntamente com as Métricas DORA para ter uma visão mais completa da adoção de agentes de programação.

Sistemas baseados em agentes e ferramentas de programação introduzem novas arquiteturas e ameaças de segurança emergentes. O MITRE ATLAS é uma base de conhecimento de táticas e técnicas adversariais direcionadas a sistemas de IA e ML. Mais focado do que o amplo framework MITRE ATT&CK e projetado para complementá-lo, o ATLAS fornece uma taxonomia de ameaças para pipelines de ML, aplicações de LLM e sistemas baseados em agentes. Descobrimos que, sem um vocabulário compartilhado, os riscos de segurança são frequentemente negligenciados ou reduzidos a um checklist. É aqui que o ATLAS pode ajudar. Como o framework é fundamentado em pesquisas sobre incidentes reais e padrões de tecnologia, a equipe pode usá-lo para apoiar a modelagem de ameaças. Os times também podem considerá-lo um complemento natural para frameworks de controle como o SAIF, ajudando a descrever o cenário de ameaças em constante evolução para sistemas de IA.

O Ralph Loop (também chamado às vezes de Wiggum loop) é uma técnica de agente de programação autônomo onde um prompt fixo é fornecido a um agente em um loop infinito. Cada iteração começa com uma nova janela de contexto: o agente seleciona uma tarefa de uma especificação ou plano, implementa-a e o loop recomeça. O insight central é a simplicidade. Em vez de orquestrar times de agentes de programação ou enxames de agentes de programação, um único agente trabalha autonomamente em relação a uma especificação, com a expectativa de que a base de código convergirá para a especificação ao longo de iterações repetidas. Usar uma janela de contexto nova a cada iteração evita a degradação de qualidade que vem do contexto acumulado, embora com um custo significativo de tokens. Ferramentas como o goose implementaram o padrão, em alguns casos estendendo-o com revisão entre modelos entre as iterações.

As organizações frequentemente lutam com interfaces legadas fragmentadas onde o "padrão de design" existe apenas como uma coleção frouxa de páginas web desconexas, materiais de marketing e screenshots. Historicamente, auditar esses artefatos para estabelecer uma base unificada tem sido um processo manual e demorado. Com LLMs multimodais, essa extração agora pode ser automatizada, efetivamente fazendo a engenharia reversa de design systems a partir de assets visuais existentes. Ao alimentar sites, screenshots e fragmentos de UI em ferramentas especializadas ou modelos de IA com capacidade de visão, os times podem extrair tokens de design essenciais — como paletas de cores, escalas de tipografia e regras de espaçamento — e identificar padrões de componentes recorrentes. A IA então sintetiza esses dados visuais não estruturados em uma representação semântica e estruturada de um design system. Quando integrada a ferramentas como o Figma, essa saída pode acelerar significativamente a criação de uma biblioteca de componentes formalizada e de fácil manutenção. Além de reduzir o esforço em auditorias visuais, essa técnica pode servir como um trampolim para a construção de design systems prontos para IA. Para empresas sobrecarregadas pela dívida de design brownfield, o uso de IA para estabelecer um design system base é um ponto de partida prático antes de um redesign completo ou padronização do frontend.

O isolamento contextual baseado em papéis no RAG é uma técnica arquitetural que move o controle de acesso da camada de aplicação para a camada de recuperação. Cada fragmento de dados, é tagueado com permissões baseadas em papéis no momento da indexação. No momento da consulta, o motor de recuperação restringe o espaço de busca com base na identidade autenticada da pessoa usuária, que é correspondida com os metadados em cada fragmento. Isso garante que o modelo de IA não possa acessar contexto não autorizado porque ele é filtrado na etapa de recuperação. Isso fornece uma base de "confiança zero" para bases de conhecimento internas. Como muitos bancos de dados vetoriais agora suportam filtragem de metadados de alto desempenho, como o Milvus ou serviços construídos no Amazon S3, tornou-se mais prático adotar essa técnica, mesmo para grandes bases de conhecimento.

Skills de agentes, instruções compartilhadas com curadoria e muitas outras técnicas de engenharia de contexto aparecem ao longo desta edição do Radar. Um caso de uso que queremos destacar no contexto da programação é o uso de skills como documentação executável de onboarding. Essa técnica se aplica a vários níveis. Dentro de uma base de código, uma skill /_setup pode assumir o papel conjunto de um script go.sh e de um arquivo README, combinando scripts com semântica executada por LLM para etapas que não podem ser roteirizadas. Ela também pode ir além do que um script pode fazer, levando em consideração dinamicamente o estado atual da base de código e do ambiente. Em segundo lugar, pessoas criadoras de bibliotecas e APIs podem fornecer skills para seus consumidores como parte de sua documentação por meio de registros de skills internos ou externos, como o Tessl. E, em terceiro lugar, descobrimos que isso é útil para o onboarding de times em plataformas internas, a fim de diminuir a barreira para o uso de uma tecnologia-chave ou reduzir o atrito na adoção de um design system. Até agora, nossa experiência com isso dependeu fortemente de servidores MCP, mas agora está mudando para skills. Assim como em outras formas de documentação, o desafio de manter isso atualizado não desaparece. No entanto, diferente da documentação estática, a documentação executável pode ajudar você a notar a desatualização muito mais cedo.

Os modelos de linguagem de pequeno porte (SLMs) continuam a melhorar e estão começando a oferecer melhor inteligência por dólar do que os LLMs para certos casos de uso. Temos visto times avaliarem os SLMs para reduzir custos de inferência e acelerar workflows baseados em agentes. Progressos recentes mostram ganhos constantes na densidade de inteligência, tornando os SLMs competitivos com LLMs mais antigos para tarefas como sumarização e programação básica. Essa mudança reflete um afastamento do "maior é melhor" em direção a dados de maior qualidade, destilação de modelo e quantização. Modelos como Phi-4-mini e Ministral 3 3B demonstram como modelos destilados podem reter muitas capacidades de modelos professores maiores. Mesmo modelos ultracompactos, como Qwen3-0.6B e Gemma-3-270M, estão se tornando viáveis para a execução de modelos em dispositivos de borda. Para casos de uso baseados em agentes onde LLMs mais antigos têm sido suficientes, os times devem considerar os SLMs como uma alternativa de menor custo e menor latência com requisitos de recursos reduzidos.

No Radar anterior, descrevemos um time de agentes de programação como uma técnica onde uma pessoa desenvolvedora orquestra um pequeno conjunto de agentes com funções específicas para colaborar em uma tarefa de programação. Desde então, a barreira de adoção diminuiu. O suporte a subagentes tornou-se um requisito básico entre as ferramentas de agentes de programação consolidadas, e o Claude Code agora inclui um recurso de equipes de agentes que oferece orquestração integrada. Em um time de agentes, um orquestrador principal tipicamente coordena o sequenciamento de tarefas e a paralelização. Os agentes devem ser capazes de se comunicar não apenas com o orquestrador, mas também entre si. Casos de uso comuns incluem times de agentes revisores ou grupos de agentes implementadores responsáveis por diferentes partes da aplicação, como backend e frontend. Embora algumas pessoas na indústria estejam usando os termos "times de agentes" e "enxames de agentes" de forma intercambiável (por exemplo, o Claude Code descreve seu recurso de times de agentes como "nossa implementação de enxames"), vemos valor em distingui-los. Um time pequeno e intencional de agentes colaborando em uma tarefa difere significativamente de um grande enxame em termos de barreiras de entrada, complexidade e casos de uso.

Os fakes temporais estendem a ideia de simular sistemas do mundo real para desenvolvimento e testes, uma prática usada há muito tempo em plataformas industriais e de IoT. Com os agentes de programação de IA reduzindo o esforço necessário para construir tais simuladores, os times agora podem criar réplicas de alta fidelidade de dependências externas com muito mais facilidade. Diferentemente dos mocks tradicionais que retornam pares estáticos de solicitação-resposta, os fakes temporais mantêm máquinas de estados internas e modelam a evolução temporal de sistemas reais. Um de nossos times usou essa técnica ao desenvolver uma stack de observabilidade para grandes data centers de GPU, evitando a necessidade de adquirir hardware físico. Testar regras de alerta, dashboards e detecção de anomalias contra sistemas reais pode ser impraticável — por exemplo, superaquecer intencionalmente uma GPU para validar um alerta de estrangulamento térmico (thermal throttle). Em vez disso, o time construiu fakes para domínios de hardware como NVIDIA DCGM e fabric InfiniBand usando Go. Esses simuladores permitiram cenários de falha como estrangulamento térmico, tempestades de erros XID, instabilidade de link e falhas de fonte de alimentação (PSU) com intensidade e duração configuráveis, orquestrados por meio de uma stack process-compose. Um registro central definia os cenários de falha válidos, enquanto um servidor MCP expunha a injeção de cenários ao agente. O agente podia acionar falhas — por exemplo, injetando um estrangulamento térmico em uma GPU específica — e verificar se as métricas mudaram, os alertas dispararam e os dashboards foram atualizados conforme o esperado. Essa fidelidade temporal torna a técnica valiosa para testar sistemas complexos onde as falhas ocorrem em cascata. No entanto, os times devem garantir que os fakes permaneçam fiéis ao comportamento do mundo real; caso contrário, correm o risco de criar uma falsa confiança em pipelines automatizados.

As capacidades dos agentes estão superando as práticas de segurança. Com o surgimento de agentes ávidos por permissões como o OpenClaw, os times estão cada vez mais implantando agentes em ambientes que os expõem à tríade letal: acesso a dados privados, exposição a conteúdo não confiável e a capacidade de se comunicar externamente. À medida que as capacidades crescem, a superfície de ataque se expande, expondo os sistemas a riscos como injeção de prompt e envenenamento de ferramentas. Continuamos a ver a análise de fluxo tóxico como a principal técnica para examinar sistemas agênticos e identificar caminhos de dados inseguros e potenciais vetores de ataque. Esses riscos não se limitam mais às integrações MCP; nossos times observaram padrões semelhantes em Agent Skills, onde um ator malicioso pode empacotar uma skill aparentemente útil que incorpora instruções ocultas para exfiltrar dados sensíveis. Recomendamos fortemente que os times que trabalham com agentes realizem a análise de fluxo tóxico e que usem ferramentas como o Agent Scan para identificar caminhos de dados inseguros antes que eles sejam explorados.

O parsing de documentos frequentemente depende de pipelines de múltiplos estágios que combinam detecção de layout, OCR tradicional e scripts de pós-processamento. Essas abordagens costumam ter dificuldades com layouts complexos e fórmulas matemáticas. Os modelos de linguagem visual (VLMs) para parsing de documentos de ponta a ponta simplificam essa arquitetura tratando a imagem do documento como uma modalidade de entrada única, preservando a ordem natural de leitura e o conteúdo estruturado. Modelos de código aberto treinados especificamente para esse fim — como o olmOCR-2, o eficiente em tokens DeepSeek-OCR (3B) e o ultracompacto PaddleOCR-VL — têm gerado resultados altamente eficientes. Embora os VLMs reduzam a complexidade arquitetural ao substituir pipelines de múltiplos estágios, sua natureza generativa os torna propensos a alucinações. Casos de uso com baixa tolerância a erros ainda podem exigir uma abordagem híbrida ou OCR determinístico. Times que lidam com ingestão de grandes volumes de documentos devem avaliar essas abordagens unificadas para determinar se elas podem substituir pipelines legados complexos, mantendo a precisão e reduzindo o overhead de manutenção a longo prazo.

Arquivos de contexto como o AGENTS.md e CLAUDE.md tendem a se acumular ao longo do tempo à medida que os times adicionam visões gerais da base de código, explicações arquiteturais, convenções e regras. Embora cada adição seja útil isoladamente, isso frequentemente leva ao inchaço de instruções para agentes. As instruções se tornam longas e às vezes conflitam entre si. Os modelos tendem a prestar menos atenção ao conteúdo enterrado no meio de contextos longos, então orientações profundas em um longo histórico de conversas podem ser perdidas. À medida que as instruções crescem, aumenta a probabilidade de que regras importantes sejam ignoradas. Também vemos muitos times usando IA para gerar arquivos AGENTS.md, mas pesquisas sugerem que versões escritas à mão são frequentemente mais eficazes do que as geradas por LLMs. Ao usar ferramentas baseadas em agentes, seja intencional e seletivo com as instruções. Adicione-as conforme a necessidade e refine-as continuamente em direção a um conjunto mínimo e coerente.

A IA continua a diminuir as barreiras para que pessoas que não programam construam sistemas complexos. Embora isso permita a experimentação e a validação antecipada de requisitos, também introduz o risco da shadow IT acelerada por IA. Além de plataformas de workflow no-code que integram APIs de IA (por exemplo, OpenAI ou Anthropic), mais ferramentas agênticas estão se tornando acessíveis a não programadores, como o Claude Cowork. Quando a planilha que silenciosamente administra o negócio evolui para workflows agênticos customizados que carecem de governança, isso introduz riscos de segurança significativos e uma proliferação de soluções concorrentes para problemas semelhantes. Distinguir entre workflows descartáveis e pontuais e processos críticos que exigem uma implementação durável e pronta para produção é fundamental para equilibrar a experimentação com o controle. As organizações devem priorizar a governança como parte de sua estratégia de adoção de IA, facilitando a experimentação dentro de ambientes controlados. Sandboxes internas adequadamente instrumentadas oferecem às pessoas não programadoras um espaço para implantar protótipos com rastreamento de uso. Combiná-las com um catálogo compartilhado de workflows existentes ajuda as equipes a descobrir o que já foi construído antes de duplicar esforços. Os workflows que ganharem tração podem então sinalizar onde investir em aplicações mais robustas e em nível de produção.

A dívida cognitiva da base de código é a lacuna crescente entre a implementação de um sistema e o entendimento compartilhado de um time sobre como e por que ele funciona. À medida que a IA aumenta a velocidade das mudanças, especialmente com múltiplos contribuidores ou enxames de agentes de programação, os times podem perder o controle da intenção de design e do acoplamento oculto. Isso, combinado com a crescente dívida técnica, cria um ciclo de retroalimentação que torna os sistemas progressivamente mais difíceis de compreender. Um entendimento mais fraco do sistema também reduz a capacidade das pessoas desenvolvedoras de orientar a IA de forma eficaz, tornando mais difícil antecipar edge cases e afastar os agentes de armadilhas arquiteturais. Se não for gerenciado, os times chegam a um ponto de inflexão onde pequenas mudanças desencadeiam falhas inesperadas, correções introduzem regressões e esforços de refatoração aumentam o risco em vez de reduzi-lo. Os times devem evitar a complacência com código gerado por IA e adotar contramedidas explícitas: sensores de feedback para agentes de programação, rastreamento da carga cognitiva do time e funções de aptidão arquitetural para garantir continuamente o cumprimento de restrições essenciais à medida que a IA acelera a produção.

Enquanto um time de agentes de programação é um grupo pequeno e intencional, um enxame de agentes de programação aplica dezenas a centenas de agentes a um problema, com a IA determinando a composição e o tamanho dinamicamente. Projetos como Gas Town e Ruflo (anteriormente Claude Flow) são bons exemplos dessa abordagem. Padrões emergentes para implementações de enxames estão surgindo: separação hierárquica de papéis (orquestradores, supervisores e trabalhadores efêmeros), um registro de trabalho durável que ajuda os agentes a dividir e coordenar o trabalho (o Gas Town usa beads para isso) e um mecanismo de integração para lidar com conflitos de trabalhos paralelos. Dois experimentos com enxames chamaram atenção especial: a geração de compilador C da Anthropic e o experimento de escalonamento de agentes do Cursor, que criou um navegador em uma semana. Vale notar que ambos os times escolheram casos de uso que podiam depender de especificações detalhadas existentes e, no caso do compilador C, de suítes de testes abrangentes que fornecem feedback claro e mensurável. Essas condições não são representativas do desenvolvimento típico de produtos, onde os requisitos são menos definidos e a verificação é mais difícil. No entanto, esses experimentos contribuem para padrões emergentes que tornam enxames de longa duração tecnicamente viáveis. Eles continuam caros e ainda estão longe de serem maduros, e é por isso que aconselhamos cautela ao adotar essa técnica.

Assistentes de programação baseados em IA estão entregando ganhos reais de produtividade e tornando-se rapidamente ferramentas padrão no desenvolvimento. No entanto, estamos vendo cada vez mais organizações medirem o sucesso usando indicadores superficiais, como linhas de código geradas ou o número de pull requests (PRs). Quando essas métricas de vazão de código (coding throughput) são usadas isoladamente, elas podem moldar negativamente o comportamento das equipes. O resultado é frequentemente uma enxurrada de código desalinhado que atrasa revisões, prejudica o fluxo de entrega e introduz riscos de segurança. Os tempos de ciclo aumentam à medida que engenheiros abrem PRs repletos de sugestões da IA sem a devida revisão, gerando um vaivém constante com os revisores. Essas métricas falham em capturar o esforço residual necessário para adaptar o código gerado por IA à arquitetura, às convenções e aos padrões de cada equipe. Existem indicadores mais significativos, como a taxa de aceitação de primeira passagem — a frequência com que a saída da IA pode ser utilizada com o mínimo de retrabalho. Medir isso expõe o esforço oculto e torna a melhoria acionável: os times podem refinar prompts, melhorar os documentos de contexto e fortalecer as discussões de design para aumentar progressivamente a aceitação. Isso cria um ciclo virtuoso no qual a IA exige menos correções. A aceitação de primeira passagem também se conecta naturalmente às Métricas DORA: baixas taxas de aceitação tendem a elevar a taxa de falha em mudanças, enquanto ciclos de iteração repetidos estendem o lead time. À medida que assistentes de IA se tornam onipresentes, as organizações devem mudar o foco da vazão de código bruta para métricas que reflitam o impacto real e os resultados da entrega.

Ignorar a durabilidade em fluxos de trabalho de agentes é um antipadrão que temos visto em muitas equipes, resultando em sistemas que funcionam no desenvolvimento, mas falham em produção. Os desafios enfrentados por sistemas distribuídos são ainda mais pronunciados ao construir soluções com agentes. Uma mentalidade que espera falhas e se recupera com resiliência supera uma abordagem reativa. Chamadas de LLM e de ferramentas podem falhar devido a interrupções de rede e travamentos de servidor, interrompendo o progresso de um agente e levando a uma experiência ruim para a pessoa usuária e ao aumento dos custos operacionais. Alguns sistemas podem tolerar isso quando as tarefas são de curta duração, mas workflows complexos que rodam por dias ou semanas exigem durabilidade. Felizmente, a execução durável está sendo integrada a frameworks de agentes, como LangGraph e Pydantic AI. Ela fornece persistência stateful do progresso e das chamadas de ferramentas, permitindo que os agentes retomem as tarefas após falhas. Para workflows que envolvem um humano na supervisão, a execução durável pode suspender o progresso enquanto aguarda a entrada de dados. Plataformas de computação durável como Temporal, Restate e Golem também fornecem suporte para agentes. A observabilidade integrada da execução de ferramentas e o rastreamento de decisões facilitam o debugging e melhoram o entendimento dos sistemas em produção. Os times devem começar com o suporte nativo à execução durável em seu framework de agentes e recorrer a plataformas independentes à medida que os workflows se tornam mais críticos ou complexos.

À medida que o Model Context Protocol (MCP) ganha adoção, estamos vendo times e fornecedores recorrerem a ele como a camada de integração padrão entre agentes de IA e sistemas externos, mesmo quando existem alternativas mais simples. Nós alertamos contra o uso do MCP por padrão. O MCP agrega valor real para contratos de ferramentas estruturados, fronteiras de autenticação baseadas em OAuth e acesso governado em ambientes multitenant. Ele também introduz o que Justin Poehnelt chama de "custo de abstração": cada camada de protocolo entre um agente e uma API perde fidelidade e, para APIs complexas, essas perdas se acumulam. Na prática, uma CLI bem projetada com um --help bem estruturado, respostas JSON estruturadas e tratamento de erros previsível frequentemente dá aos agentes tudo o que eles precisam sem a sobrecarga do protocolo. Como Simon Willison observa, "quase tudo o que eu conseguiria fazer com MCP pode ser resolvido por uma ferramenta de CLI." Isso não significa rejeitar o MCP. Os times devem evitar adotá-lo por padrão e primeiro se perguntar se o sistema realmente exige interoperabilidade em nível de protocolo. O MCP faz sentido quando seus benefícios de governança e integração superam a complexidade adicional e a potencial perda de fidelidade.

Os ambientes de desenvolvimento com streaming de pixels usam desktops remotos ou workstations no estilo VDI para o desenvolvimento de software, com edição, compilações e debugging realizados por meio de um desktop transmitido via streaming, em vez de uma máquina local ou um ambiente remoto centrado em código. Continuamos a ver organizações adotando-os para atender a metas de segurança, padronização e onboarding, especialmente para times offshore e programas de lift-and-shift para a nuvem. Na prática, no entanto, o trade-off costuma ser ruim: latência, input lag e responsividade inconsistente da tela criam um atrito cognitivo constante que atrasa a entrega e torna o trabalho diário de desenvolvimento mais cansativo. Diferente dos ambientes de desenvolvimento na nuvem, como o Google Cloud Workstations ou ferramentas como o Coder e o VS Code Remote Development, que aproximam o processamento do código sem transmitir todo o desktop, os ambientes com streaming de pixels priorizam o controle centralizado em detrimento do fluxo da pessoa desenvolvedora e frequentemente são impostas com pouca participação das pessoas engenheiras que as utilizam. Desaconselhamos ambientes de desenvolvimento com streaming de pixels como uma escolha padrão para a entrega de software, a menos que uma exigência regulatória ou de segurança muito forte supere claramente o custo de produtividade.