Techniques 

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.

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.

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.