Técnicas

Anteriormente, recomendamos a execução em sandbox para agentes de programação. À medida que os agentes de IA se tornam cada vez mais autônomos e capazes de atuar não apenas em ambientes de código, mas também em sistemas de negócios, restringir seu escopo operacional tornou-se fundamental. Agora consideramos o sandboxing de agentes um padrão sensato para todos os agentes. Executar agentes em ambientes isolados, com privilégios restritos e acesso controlado a sistemas externos, reduz o risco e limita o impacto de comportamentos inesperados, ações não intencionais ou exploração maliciosa.

Recomendamos que as equipes apliquem uma abordagem baseada em riscos ao sandboxing, fundamentada pela modelagem de ameaças de seus agentes e sistemas. Embora não exista uma solução única para todos os casos, manchetes recentes sobre segurança reforçam a importância de aplicar práticas de segurança consolidadas, como o princípio do menor privilégio, ao construir e executar agentes.

Os testes de mutação avaliam a qualidade da suíte de testes introduzindo automaticamente pequenos bugs artificiais no código da aplicação e verificando se pelo menos um teste falha. Se os testes passarem apesar da alteração no código, a mutação sobrevive, revelando lacunas na cobertura de testes ou na qualidade das asserções. À medida que as equipes adotam assistentes de programação por IA, o volume de código e testes gerados por IA aumenta rapidamente, tornando as métricas tradicionais de cobertura de código mais fáceis de serem infladas com testes superficiais que carecem de validação significativa.

Essa técnica atua como uma proteção (guardrail), ajudando a garantir que os testes gerados não passem simplesmente sem capturar alterações de lógica. Além de frameworks dedicados, os agentes de IA agora podem executar testes de mutação de forma autônoma durante a execução, modificando diretamente o código, executando testes e avaliando asserções em seu próprio ciclo. Como as execuções automatizadas de mutação consomem tempo, pessoas desenvolvedoras devem focar em pacotes internos específicos ou recorrer a verificações incrementais para executar testes apenas no código alterado recentemente.

O mapeamento do caminho para produção é uma prática padrão na Thoughtworks que ganhou nova relevância com o advento da programação agêntica. O aumento na vazão de código pode expor ou amplificar gargalos em outras partes do caminho para a produção, tornando essencial que as equipes otimizem o fluxo ponta a ponta do software em vez de focar apenas na velocidade de programação. A atividade é realizada com mais frequência em um workshop que inclui todas as pessoas envolvidas no design, desenvolvimento, liberação e operação do software. Primeiro, as participantes listam as etapas do processo em um quadro branco, desde a estação de trabalho da desenvolvedora até a produção. Em uma segunda passagem, elas registram os pontos de dor. A atividade é frequentemente reveladora, pois as participantes identificam atrasos, riscos e inconsistências dos quais não tinham conhecimento prévio. Enfrentar esses gargalos é fundamental para melhorar a produtividade geral da entrega.

A criptografia pós-quântica (PQC) refere-se a algoritmos criptográficos projetados para proteger dados digitais contra ataques de futuros computadores quânticos. Com o avanço da computação quântica, a ameaça à criptografia convencional torna-se cada vez mais real: dados criptografados hoje podem ser coletados agora e descriptografados mais tarde, tornando a troca de chaves a área mais urgente para migração. Com os padrões do NIST agora finalizados (ML-KEM, ML-DSA e SLH-DSA), governos de todo o mundo estabelecem a migração entre 2030 e 2035.

Infraestruturas modernas, linguagens (por exemplo, o Java a partir do JDK 24) e frameworks estão oferecendo cada vez mais suporte nativo a PQC em suas versões mais recentes. Habilitá-lo, no entanto, exige a atualização de versões mais antigas ou o ajuste de configurações. As organizações devem exigir a criptografia resiliente a quântica para projetos novos (greenfield), enquanto aceleram os roteiros de migração para sistemas legados.

A revelação progressiva de contexto é uma técnica de engenharia de contexto para fornecer informações a LLMs sob demanda. O sistema inicializa a LLM com o contexto essencial e permite que as respostas da LLM ou as entradas do usuário acionem o carregamento de dados adicionais. Estamos movendo a revelação progressiva de contexto para “Adote” porque a prática é quase universal em aplicações sérias, embora assuma muitas formas.

Na programação, um exemplo é manter seu AGENTS.md enxuto e fornecer links para documentações que o agente possa consultar quando necessário. Harnesses de programação também usam essa abordagem para adiar o custo total de contexto de ferramentas MCP e agent skills até que sejam utilizadas. Aplicações de negócios podem usar RAG vetorial ou GraphRAG para recuperar informações adicionais com base na entrada do usuário. Em cada caso, a revelação progressiva de contexto pode reduzir o consumo e os custos de tokens, além de ajudar a combater o context rot.

A modelagem de ameaças é um exercício para identificar ameaças potenciais aos seus sistemas. É uma prática de segurança fundamental para todo desenvolvimento de software, especialmente para aplicações de IA generativa, cujos riscos de segurança distintos, como injeção de prompt e ação autônoma, podem ser ignorados por verificações e varreduras baseadas em regras. A modelagem de ameaças deve ser uma parte regular e liderada por humanos no ciclo de vida de desenvolvimento de software, com o apoio de agentes. A discussão ajuda a trazer à tona comportamentos não documentados e a construir o entendimento das partes interessadas.

Recomendamos começar com ameaças conhecidas e mapeá-las para o seu contexto. Recursos úteis incluem o catálogo de ameaças de IA MITRE ATLAS, o MAESTRO como complemento para frameworks como o STRIDE, e a análise de fluxo tóxico para IA para raciocinar sobre onde a injeção de prompt pode entrar. Uma sessão deve terminar com decisões explícitas sobre onde o comportamento não determinístico do modelo é aceitável, onde não é e onde guardrails determinísticos são necessários para limitar riscos e danos.

Um marketplace de plugins para agentes é um meio de distribuir ativos de harness em toda a organização. A necessidade surge quando várias equipes adotam agentes de programação e desejam compartilhar skills, instruções, servidores MCP, definições de subagentes e outros ativos. Copiar esses elementos entre repositórios não oferece uma maneira fácil de publicá-los, descobri-los ou atualizá-los. Implementamos um marketplace de plugins para agentes usando repositórios Git documentados, com plugins no formato Agent Plugins que os agentes de programação consomem diretamente ou que são gerenciados como dependências com o Agent Package Manager. A Anthropic popularizou o padrão com seu Claude Code plugin marketplace, e registros hospedados como o da Tessl e coleções da comunidade como wshobson/agents adotaram a ideia. Vemos os marketplace de plugins para agentes como uma forma prática de disponibilizar seu enterprise harness para toda a organização.

Com bases de conhecimento mantidas por agentes, uma equipe mantém seu conhecimento compartilhado em arquivos de texto simples vinculados entre si, muitas vezes em um cofre (vault) do Obsidian, e usa um agente de programação para mantê-los. O LLM Wiki de Andrej Karpathy descreve o padrão: fontes brutas que o agente lê, mas nunca altera, uma wiki que ele mantém e um esquema que orienta como ele faz isso. O OpenWiki aplica uma versão mais restrita da ideia à documentação de um único repositório de código. A técnica é prática hoje porque agentes de programação de uso geral já conseguem ler e editar arquivos de forma eficaz, enquanto o Git fornece controle de versão.

Várias de nossas equipes usam variações dessa abordagem, com gerentes de produto, designers, pessoas desenvolvedoras e seus agentes consultando a mesma base de conhecimento. Essas equipes acham suas informações mais conectadas e acessíveis.

Muitas pessoas começam com um "segundo cérebro" pessoal. Recomendamos dar o próximo passo e compartilhar um com toda a equipe, embora expandi-lo para uma base de conhecimento em toda a organização exija mais do que simplesmente apontar um agente de programação para uma pasta de arquivos. O conhecimento gerado pode se distanciar da realidade e, sem o esforço humano regular para mantê-lo preciso, a base de conhecimento corre o risco de criar proliferação de documentação gerada por IA.

Ancorar agentes de programação a uma aplicação de referência aborda o desafio da degradação de templates separando templates de scaffolding estruturais e enxutos das regras de configuração de plataforma em constante evolução. Anteriormente, focamos no uso de aplicações de referência dinâmicas e compiláveis para manter o código gerado em sintonia com as práticas atuais. Agora, estamos vendo equipes estenderem esse padrão com sucesso para o scaffolding direcionado por IA.

Geradores de código tradicionais e ferramentas de CLI para scaffolding rapidamente ficam desatualizados à medida que as diretrizes da plataforma, dependências e melhores práticas arquitetônicas mudam. Em vez de codificar essas regras rigidamente em templates estáticos, os agentes de programação consultam fontes de informação centralizadas e atualizadas — como um OpenWiki ou Agent-maintained knowledge bases estruturadas — em tempo de execução para recuperar convenções e configurações atuais. Consolidar regras de plataforma em evolução em repositórios unificados e acessíveis por agentes ajuda os agentes a gerar código que segue os padrões atuais, sem exigir atualizações contínuas nas ferramentas de scaffolding subjacentes.

Equipes que constroem agentes para trabalhos que não envolvem código, como processamento de documentos, suporte de operações ou planejamento de migração, normalmente começavam com um framework de agentes e montavam o loop do agente por conta própria. Cada vez mais, vemos equipes construírem em cima de um harness de código para agentes de propósito geral, reutilizando o ambiente de execução (runtime) de um agente de código maduro. Agentes de código populares agora expõem seu runtime de forma programática através do Claude Agent SDK, do Codex SDK e app-server, do servidor e SDK do OpenCode ou do SDK e modo RPC do Pi. Esses harnesses já lidam com aspectos complexos do loop do agente, incluindo a compactação de contexto em tarefas de longa duração, a persistência de sessões e a execução headless com as mesmas habilidades de agente, subagentes e instruções usados em sessões interativas de agentes de código. Em comparação com frameworks de agentes, a compensação (trade-off) é ter menos controle em troca de um runtime que já foi exaustivamente testado. Usamos essa abordagem para construir um acelerador interno para migrações de aplicações .NET.

No entanto, esses harnesses diferem em suas capacidades. O Codex e o Claude Agent SDK oferecem sandboxing e políticas de aprovação, enquanto o Pi deixa as proteções (guardrails) deliberadamente para extensões, facilitando a adaptação, mas exigindo mais trabalho das equipes. Como esses runtimes foram projetados para o desenvolvimento de software, seus prompts do sistema e ferramentas integradas tendem a direcionar os agentes a escrever e executar código. As equipes devem revisar esses padrões para o seu domínio pretendido. Elas também devem monitorar custos, já que os loops de agentes de código podem consumir um número substancial de tokens, e prompts integrados grandes somam a cada turno. Essa é uma das razões pelas quais harnesses mínimos como o Pi são atraentes.

No Radar anterior, descrevemos o flywheel de feedback como uma forma de melhorar a estrutura (harness) de um agente de programação a partir de sessões anteriores. A maioria das pessoas desenvolvedoras atualiza arquivos AGENTS.md e habilidades de agentes quando um agente erra algo, mas o que uma desenvolvedora aprende pode não ser compartilhado com o restante da equipe. O flywheel de feedback adiciona uma pergunta ao final de cada sessão, questionando se algo deve mudar em um artefato compartilhado, junto com um item de retrospectiva onde a equipe decide o que atualizar. Sensores de feedback mostram quais verificações continuam falhando, uma caixa de sugestões dos agentes coleta problemas relatados pelos agentes e ferramentas como o Backpass propõem edições com base em sessões passadas para um humano aceitar ou rejeitar. Estamos movendo o flywheel de feedback para “Experimente” porque as edições de estrutura agora são rotineiras.

O flywheel precisa remover tanto quanto adicionar. Regras que apenas se acumulam se tornam sobrecarga de instruções para os agentes, e um sensor que gera apenas ruído deve ser eliminado. Recomendamos verificar continuamente quais artefatos ainda estão em uso e atualizados. O Context profiling mostra se as edições estão aumentando o que cada sessão carrega. Onde o autoaperfeiçoamento de agentes faz com que um agente execute o loop, o flywheel de feedback o torna um hábito da equipe, com os agentes propondo alterações e as pessoas escolhendo quais alterações fazer.

À medida que fluxos de trabalho com alto consumo de contexto se tornam mais comuns, o envio de arquivos-fonte completos ou texto não estruturado para LLMs aumenta os custos com tokens. O raciocínio sobre base de código ancorado em grafos aborda isso representando código, documentação e relacionamentos como um grafo estruturado, permitindo que agentes recuperem subgrafos relevantes como contexto. Ferramentas como o Graphify capturam dependências estruturais, ajudando os agentes a identificar relacionamentos que a recuperação baseada em texto pode perder.

No entanto, o grounding baseado em grafos traz ponderações. Pesquisas recentes sugerem que agentes às vezes podem ter um desempenho pior com contexto baseado em grafos do que com ferramentas mais simples, como find e grep. Colocamos essa técnica em “Experimente” para explorar quando o contexto baseado em grafos melhora a eficiência e a precisão, construindo sobre nosso blip anterior sobre inteligência de código como ferramenta para agentes.

Grilling é uma técnica na qual um agente de programação entrevista você sobre um plano antes de agir para resolver potenciais áreas de ambiguidade. O exemplo mais conhecido vem de mattpocock/skills, mas outras bibliotecas de skills têm suas próprias versões. Um benefício é que o grilling desestimula os agentes de programação a adivinhar quando sua intenção não está clara. Ele traz à tona suposições que o agente de programação poderia, de outra forma, fazer por conta própria. Outra vantagem é que ajuda a combater a dívida cognitiva da base de código. O processo de grilling também força você a examinar suas próprias suposições, deixando você com uma compreensão melhor do plano de implementação que pode ser registrada em registros de decisão. Nossas equipes consideram o grilling uma adição útil à sua prática de programação com agentes.

Planos visuais interativos com agentes são planos autossuficientes em HTML ou MDX com diagramas, fluxos de usuário e wireframes que as equipes podem explorar antes da implementação. Nossas equipes acham que percorrer esses artefatos facilita a verificação da intenção e a revisão de alterações complexas do que ler longos planos em texto. Nossas equipes alertam contra o uso dessa técnica para "big upfront designs" e favorecem uma abordagem mais iterativa, dividindo o trabalho em etapas menores e verificáveis para construir o entendimento ao longo do caminho. A mesma abordagem pode fornecer um resumo visual do trabalho concluído, mas nossas equipes consideram os resumos mais úteis quando a implementação se desvia do plano original. Recomendamos o uso de planos visuais interativos com agentes para construir um entendimento compartilhado e estabelecer um ponto de revisão humana antes que os agentes implementem as alterações.

Managed agents runtime é a prática de executar agentes de entrega de software em uma plataforma que gerencia sua execução, infraestrutura e necessidades operacionais, em vez de depender da estação de trabalho de uma pessoa desenvolvedora. O runtime hospeda o loop do agente e fornece computação em sandbox, gatilhos, manipulação de credenciais, estado da sessão e observabilidade, deixando para as equipes a definição do modelo, prompt, ferramentas e habilidades. Trabalhos assíncronos e de longa duração são bem adequados para agentes em segundo plano que coletam tarefas a partir de issues, pipelines ou agendamentos e enviam pull requests para revisão.

As ferramentas de código estão convergindo para essa abordagem, com os agentes em nuvem do Cursor, o agente de código do GitHub Copilot e as tarefas em nuvem do OpenAI Codex executando todos em sandboxes remotas. O Claude Managed Agents oferece um equivalente de uso geral. Nossa equipe de segurança interna executa um agente diário que faz a triagem de falsos positivos de detecção de endpoint e propõe alterações de regras. "Gerenciado" não significa necessariamente a nuvem de terceiros. Em um cliente, executamos agentes personalizados em um runtime auto-hospedado em um loop contínuo através de múltiplos repositórios, corrigindo code smells sinalizados por scanners e atualizando dependências junto com qualquer alteração de código necessária.

Um serviço hospedado é frequentemente o lugar mais fácil para começar, mas organizações com restrições de residência de dados, segurança ou integração podem precisar de sua própria plataforma. De qualquer forma, recomendamos tratar o runtime como infraestrutura de produção, com sandboxing de agentes e definições de agentes controladas por versão.

Os modelos open-weight, nos quais os pesos do modelo, arquiteturas e código de inferência são lançados publicamente, atingiram um ponto de inflexão significativo. Atraídos por seu menor custo total de propriedade, temos avaliado os modelos mais recentes de famílias como DeepSeek, GLM e Kimi para trabalhos de entrega em produção que exigem raciocínio complexo e geração de código de alta qualidade, e estamos vendo bons resultados.

Além da eficiência de custos, os modelos open-weight oferecem flexibilidade de implantação, liberdade de vendor lock-in e uma soberania de dados mais forte. Equipes de engenharia podem dimensionar adequadamente suas implantações — desde modelos flash leves até modelos Mixture of Experts (MoE) de centenas de bilhões ou trilhões de parâmetros — e realizar fine-tuning privado usando dados do domínio. Embora a auto-hospedagem (self-hosting) exija um esforço operacional maior, os principais provedores de nuvem agora oferecem modelos open-weight gerenciados que reduzem a barreira para adoção. Em vez de tratá-los apenas como opções econômicas, as organizações devem avaliar os modelos open-weight para uma ampla variedade de cargas de trabalho corporativas, indo muito além da programação.

A supervisão humana baseada no nível de risco alinha a profundidade da revisão com o impacto que uma alteração poderia causar. Revisar tudo com a mesma intensidade resulta em um teatro de supervisão humana. Sugerimos triar sistematicamente as alterações. As alterações mais arriscadas ou mais difíceis de reverter são reservadas para aplicação por humanos. Alterações de risco intermediário passam por pull requests revisados por humanos. Alterações de baixo risco podem ser mescladas automaticamente por agentes de programação por meio de uma esteira de integração contínua. Duas estratégias decidem quais alterações precisam de mais revisão: zonas na base de código exigem revisão elevada para arquivos ou diretórios específicos, enquanto a classificação de alterações baseada em LLM analisa o impacto das alterações, mas é falível. O processo publicado da Meta combina essas duas estratégias. Nossas equipes consideram a supervisão humana baseada no nível de risco uma forma eficaz de aproveitar ao máximo a escassa atenção humana.

Um harness que se autoaperfeiçoa usa agentes para analisar traces de execução e feedback de avaliação para, então, propor ou implementar melhorias no sistema que envolve o modelo, incluindo prompts, estratégias de contexto, fluxos de trabalho, habilidades, ferramentas, memória e middleware. A ideia não é nova: técnicas como o flywheel de feedback usam acertos e falhas de sessões de agentes de programação para melhorar o harness, mas ainda dependem de pessoas para interpretar o feedback, decidir o que alterar e atualizar o sistema. Pesquisas recentes exploram uma abordagem mais autodirigida. O Meta-Harness e o VERSE usam traces de execução e resultados de avaliação para melhorar o código do harness; o VERSE também evolui as próprias ferramentas e procedimentos do otimizador. A visão geral de Lilian Weng traça essa progressão desde a otimização de prompts até a evolução do harness.

A observabilidade e a programabilidade são essenciais para essa transição. A observabilidade ajuda os agentes a diagnosticar falhas a partir de traces de execução e a conectar mudanças a resultados mensuráveis. A programabilidade oferece aos agentes acesso a componentes que eles podem inspecionar, modificar e testar, expandindo o escopo para o autoaperfeiçoamento. As extensões do Pi, os Claude Code Mods e o DeepSeek Harness (DSH) ilustram essa direção por meio de contexto, fluxos de trabalho, ferramentas e componentes de harness extensíveis. Uma maior abertura cria mais oportunidades de melhoria, mas os ganhos ainda exigem validação. Recomendamos experimentos delimitados com testes de regressão, enquanto pessoas definem objetivos, estabelecem limites de modificação e avaliam se as melhorias se generalizam para novas tarefas.

Continuamos a ver uma mudança na indústria, afastando-se da mentalidade de que "quanto maior, melhor" em direção ao aprimoramento da inteligência artificial por meio de dados de treinamento de alta qualidade, destilação de modelos e quantização. Modelos de linguagem de pequeno porte (SLMs) tornaram-se cada vez mais úteis para tarefas específicas que não exigem os recursos computacionais de modelos maiores. À medida que as organizações enfrentam custos crescentes com a execução de LLMs, as equipes estão reconhecendo o valor de escolher o modelo certo para a tarefa. Modelos compactos também são viáveis para edge computing, como o Apple Core AI demonstra ao executar pequenos modelos fundamentais diretamente nos dispositivos.

Nossas equipes constataram que os SLMs são eficazes para tarefas específicas e de alta frequência que não exigem conhecimento extenso ou raciocínio complexo, como sumarização, extração de dados estruturados, classificação de intenção para roteamento de requisições e programação básica. A menos que um caso de uso de agente exija raciocínio em múltiplas etapas ou chamada confiável de ferramentas (tool calling), as equipes devem considerar um SLM como uma alternativa de menor custo e menor latência.

Guardrails com estado estendem os guardrails de LLM de mensagens individuais para conversas inteiras. Em vez de verificar apenas a mensagem atual do usuário ou a resposta final do modelo, eles avaliam um histórico compacto de turnos recentes em relação a verificações específicas de políticas e mantêm um estado de penalidades (strikes) ou bloqueios (bans) ao longo da sessão. Isso é importante porque intenções inseguras podem surgir gradualmente: cada mensagem pode parecer aceitável isoladamente, enquanto a conversa como um todo revela tentativas de evasão de políticas, jailbreaking ou extração de prompts. Na prática, as verificações com estado (stateful) são executadas como um ponto de controle (gate) em tempo de execução antes que o agente atue, juntamente com os guardrails convencionais de entrada e saída para turno único.

Avaliar o histórico da conversa a cada turno adiciona latência e custo, e os limites de penalidade ou bloqueio precisam de ajustes para evitar que falsos positivos bloqueiem usuários legítimos. Nossas equipes usaram essa técnica em um assistente conversacional em produção para fluxos de trabalho sensíveis, rastreando as decisões dos guardrails no Langfuse. Recomendamos que as equipes que executam assistentes multiturno em produção experimentem stateful guardrails em vez de confiar apenas em verificações por mensagem.

Subagentes para melhor gestão de contexto é a prática de delegar trabalho a subagentes para mantê-lo fora do contexto do agente orquestrador. Exploração, saída de ferramentas, tentativas de repetição e raciocínio intermediário permanecem no sub-agente, e a sessão principal recebe um resumo curto. A maioria das pessoas começa usando sub-agentes para executar tarefas em paralelo ou formar times de agentes de programação baseadas em papéis. Proteger o contexto do orquestrador é outro motivo para utilizá-los. O que quer que permaneça no contexto do orquestrador compete por sua atenção nas interações subsequentes. Trazer a transcrição completa de um subagente para a thread principal para verificar seu progresso anula esse benefício. Algumas diretrizes úteis incluem executar de dois a quatro subagentes por vez e manter tarefas que exijam a mesma compreensão do código dentro de um único agente, para que múltiplos agentes não precisem reconstruir essa mesma compreensão.

Tratar subagentes deliberadamente como um limite para a engenharia de contexto é fácil de experimentar porque a maioria dos agentes de codificação suporta subagentes e a mudança está basicamente nas instruções. Usamos modelos mais baratos para subagentes encarregados de tarefas específicas, como pesquisas, reduzindo potencialmente os custos em comparação ao uso indiscriminado de modelos de ponta. Estamos colocando a técnica em “Avalie” porque seu benefício ainda não foi medido sistematicamente. As evidências até agora vêm de relatos de profissionais sobre suas próprias sessões, sem uma contabilidade detalhada de tokens. Também observamos que o mesmo modelo com o mesmo prompt usa subagentes de forma diferente dependendo do harness. Equipes que experimentarem essa abordagem devem usar perfilamento de contexto para verificar se o contexto do orquestrador realmente diminui.

À medida que as capacidades dos agentes de IA se expandem, as equipes estão cada vez mais implantando sistemas que enfrentam uma combinação letal de três riscos de segurança: acesso a dados privados, exposição a conteúdos não confiáveis e a capacidade de se comunicar externamente. Essa combinação cria oportunidades para ataques como prompt injection e tool poisoning. Para lidar com esses riscos, movemos a análise de fluxo tóxico para IA para “Experimente”.

Embora a modelagem de ameaças geral forneça uma base de segurança abrangente, a análise de fluxo tóxico se concentra em identificar caminhos de dados não seguros em sistemas baseados em agentes. Esses riscos não se limitam às integrações padrão. Eles também podem surgir de skills de agentes maliciosas que parecem úteis, mas contêm instruções ocultas para exfiltrar dados sensíveis. Usamos com sucesso ferramentas como o Agent Scan para realizar essa análise, ajudando as equipes a identificar e mitigar caminhos de dados não seguros antes que sejam explorados.

Execuções agênticas autônomas noturnas consistem em atribuir a um agente de programação uma tarefa com escopo de feature no fim do expediente e revisar o que foi produzido na manhã seguinte. Fizemos isso com funcionalidades no nível de épicos e tarefas de infraestrutura que podem levar horas. Um único agente é suficiente, sem a necessidade de um enxame de agentes de programação, embora ele possa utilizar subagentes. Uma das equipes da Thoughtworks passa o dia colaborando em planos e especificações e deixa a programação para os agentes durante a noite. O termo “noturnas” está no nome porque é algo difícil de fingir. Uma equipe capaz de fazer isso também executará tarefas semelhantes durante o dia. Já uma equipe que não deixa um agente programando sem supervisão à noite, provavelmente também não está executando trabalhos de forma totalmente autônoma durante o dia.

Assim como os pré-requisitos para microserviços, essa prática possui pré-requisitos de entrada, e incentivar as equipes a cumpri-los é uma grande parte do seu valor. Os agentes precisam de execução em sandbox, trabalho especificado antecipadamente como em desenvolvimento orientado a especificações e sensores de feedback para que possam corrigir seus próprios erros. O trabalho de uma noite pode ser um lote grande demais para ser revisado efetivamente linha por linha, de modo que as equipes precisam de um harness que tenham testado para validar as alterações em vez de depender exclusivamente da revisão humana de código. Técnicas complementares incluem executar o agente em um managed agent runtime e permitir que os agentes mantenham o build verde corrigindo falhas no pipeline por conta própria. Posicionamos essa prática em “Experimente” para equipes que possuem essas bases; para outras equipes, é um objetivo que justifica desenvolvê-las.

A responsabilidade de agentes no pipeline incorpora os agentes de programação à responsabilidade da equipe em manter a build verde. Um agente que não consegue ver o status da build não pode respeitar um acordo de equipe para não fazer push quando ela estiver vermelha, enquanto um humano que repassa logs de falha em uma janela de chat se torna um ponte humana.

Recomendamos tornar o estado da build parte do contexto do agente. Exponha o status da pipeline e os logs por meio das ferramentas do agente para que ele possa ver o que deu errado e ajudar a corrigir. Aplique regras importantes mecanicamente com travas (gates) de pre-push e no lado do servidor para evitar que os agentes façam push de alterações quebradas. A maior taxa de commits originada por agentes de programação está levando as equipes a repensar suposições sobre a disciplina de build, inclusive por meio de técnicas como supervisão humana baseada no nível de risco. Inclua o papel dos agentes em sua política de build ao realizar o mapeamento do caminho para produção.

Uma agent suggestion box dá a um agente em execução um local para reportar os problemas que ele encontra, como um bug em uma ferramenta ou uma dependência ausente em seu ambiente. Quando a única saída de um agente é um pull request ou um veredito estruturado, ele pode contornar o problema sem que ninguém saiba. A sessão seguinte, então, encontra o mesmo problema novamente. A caixa pode ser um canal do Slack, um repositório de memória ou um rastreador de problemas (issue tracker). A Lovable chama sua versão de "vent tool" e o agents-feedback oferece uma para agentes de programação. A memória pode ajudar um agente a evitar uma ferramenta com defeito, mas uma caixa de sugestões faz com que a ferramenta seja corrigida. A técnica funciona tanto para agentes de negócios em produção quanto para agentes de programação.

Usamos uma agent suggestion box com um agente que inicia uma nova sessão a cada dia para rascunhar regras de detecção para engenharia. Um segundo agente desduplica os relatórios. O mesmo relatório vindo de várias sessões é um sinal claro, embora alguns relatórios sejam subjetivos ou transitórios. Com a box instalada, as execuções fluíram melhor e tivemos uma lista de melhorias a fazer. As sugestões ainda precisam ser revisadas e trabalhadas, por exemplo, por meio do agent self-improvement. Estamos colocando a agent suggestion box em “Avalie” porque nossa experiência vem de um único agente. A Lovable realiza a mesclagem (merge) de cerca de dez correções por dia a partir de suas "vents", mas relata que aproximadamente metade das correções propostas pelo seu agente de triagem são falsos positivos.

À medida que os custos de tokens aumentaram e a indústria deixou para trás a modinha do tokenmaxxing, as pessoas desenvolvedoras estão buscando maneiras de gerenciar o uso de tokens. O antigo conselho de que você deve sempre medir antes de otimizar ainda se aplica — o perfilamento de contexto significa analisar para onde está indo o seu gasto com tokens, por exemplo, em leituras de arquivos ou chamadas de ferramentas MCP. A intuição é um péssimo guia para identificar quais otimizações valem a pena, especialmente quando se leva em conta o armazenamento em cache, os níveis de modelos e os preços promocionais.

Em nossa experiência, as maiores economias geralmente vêm de mudanças simples, como limpar sessões no momento certo, ajustar parâmetros de cache ou silenciar scripts de build muito falantes. No entanto, frequentemente vemos pessoas desenvolvedoras recorrendo a soluções complexas, como proxies de compressão, sem medir seu impacto. Ferramentas maduras ainda não surgiram, mas você pode se virar analisando suas sessões de agente ou dados de ferramentas como o Entire CLI e o AgentsView.

Um enterprise harness é a camada organizacional daquilo que os agentes de programação consomem — habilidades, ferramentas, conectores para contexto interno, tecnologias aprovadas, registros de decisões de arquitetura, orientações sobre o caminho para a produção, hooks e políticas de segurança — gerenciados coletivamente. Observamos que, à medida que várias equipes em uma organização adotam agentes de programação, elas precisam de um contexto comum para complementar as instruções compartilhadas curadas de cada equipe. É como uma plataforma de experiência da desenvolvedora, mas para a experiência do agente. Vimos organizações irem além, construindo um agente de programação personalizado sobre o OpenCode, mas recomendamos o compartilhamento de ativos por meio de padrões abertos e sua distribuição via um marketplace de plugins para agentes. Ainda não há consenso sobre como fazer isso bem, portanto, mantenha o enterprise harness enxuto e federado, deixe espaço para experimentação e colha o que funciona.

A IA corporativa tem se concentrado fortemente em texto e visão, enquanto grande parte dos dados de negócios permanece presa em bancos de dados relacionais. Os modelos fundacionais adaptam transformers para dados estruturados, realizando o pré-treinamento nas sequências de eventos e logs de transações de uma organização para aprender representações reutilizáveis do comportamento do negócio.

Ao contrário dos modelos tradicionais baseados em gradient boosting, que exigem ampla engenharia de recursos e retreinamento, esses modelos podem suportar múltiplas tarefas downstream com um ajuste fino leve. Ferramentas como TabPFN e TabFM podem melhorar a avaliação de riscos, a análise preditiva e a retenção de clientes diretamente a partir de dados tabulares ou relacionais. Dado o seu potencial para desbloquear insights de negócios sem pipelines complexos de engenharia de recursos, sugerimos avaliar essa técnica.

Atualmente, organizações e equipes criam harnesses customizados e adaptados aos seus projetos, incluindo skills de agentes, plugins, AGENTS.md e guardrails determinísticos. A avaliação da qualidade do harness tornou-se uma técnica importante, avaliando a qualidade do próprio harness. Guardrails e harnesses ajudam um agente de programação a corrigir o rumo e a melhorar a qualidade geral, mas apenas se realmente funcionarem.

Um harness geralmente inclui componentes determinísticos e não determinísticos. Para harnesses não determinísticos, nossas equipes usam PluginEval para avaliar plugins ou skills de agente de programação. Para harnesses determinísticos, podemos introduzir uma suíte de testes para permitir o desenvolvimento desses guardrails no estilo TDD, garantindo que cada um funcione de fato e forneça evidências tangíveis para provar sua eficácia. Recomendamos executar a avaliação de qualidade (evals) de forma agendada (como diariamente à noite ou junto com o CI).

Nas edições anteriores do Radar, colocamos os assistentes de programação locais em “Cautela” porque os modelos disponíveis eram muito limitados para contextos complexos de engenharia de software e não representavam uma solução convincente para as preocupações que deveriam resolver. Com os agentes de programação sendo adotados de forma muito mais ampla do que há 18 meses e os modelos open-weight amadurecendo rapidamente, nossas equipes perceberam que os modelos de programação locais são eficazes para lidar com a preguiça na seleção de camadas de modelo.

Modelos que podem ser executados localmente, como o Qwen3.8-27B, provaram ser particularmente úteis para cargas de trabalho que não exigem um modelo de ponta, incluindo indexação de codebase, parsing e sumarização de logs estruturados, tarefas iniciais de programação e revisões automatizadas de diffs e commits do Git. Executar essas tarefas localmente pode evitar custos incrementais de tokens em nuvem, ao mesmo tempo em que permite o processamento em segundo plano de longa duração e oferece um recurso de fallback offline.

Sistemas agênticos e ferramentas de codificação introduzem novas arquiteturas e ameaças emergentes de segurança. 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 framework mais amplo 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 agênticos.

Percebemos que, sem um vocabulário compartilhado, os riscos de segurança são frequentemente ignorados ou reduzidos a um mero exercício de marcar caixas. É aqui que o ATLAS pode ajudar. Com base em pesquisas sobre incidentes reais e padrões tecnológicos, as equipes podem usar o framework para apoiar a modelagem de ameaças. As equipes também podem achá-lo um complemento natural para frameworks de controle, como o SAIF, ajudando a descrever o cenário de ameaças em evolução para sistemas de IA.

Há muito tempo dizemos que estar consciente da produção ajuda pessoas desenvolvedoras a escreverem códigos melhores, e estamos descobrindo que o mesmo se aplica aos agentes de programação. Recomendamos agentes de programação com contexto de produção, o que significa dar aos agentes de programação acesso apropriado a dados e ferramentas de observabilidade de produção. Esse contexto os ajuda a planejar alterações eficazes, revisar o impacto das alterações implantadas e auxiliar na investigação de problemas de produção. Uma categoria crescente de ferramentas está tornando esse acesso prático. Esta recomendação é semelhante à responsabilidade de agentes no pipeline, estendendo os sensores de feedback que mantêm os agentes em autocorreção durante uma sessão de programação para além de verificações de pre-commit, alcançando a produção. Acreditamos que o desenvolvimento bem-sucedido possui múltiplas camadas de feedback, e uma engenharia agêntica bem-sucedida concede aos agentes acesso a todas elas.

A chamada programática de ferramentas é um padrão de uso de ferramentas no qual o modelo escreve código em vez de emitir uma chamada de ferramenta por vez. Em vez de fazer um ciclo de ida e volta (round-trip) pelo modelo para cada operação, ele combina chamadas de ferramentas em um programa que é executado em um ambiente de execução, realizando loops, filtragens e a formatação dos resultados. Apenas os resultados selecionados ou a saída final são retornados ao contexto do modelo.

O conceito é compartilhado por várias implementações, embora a nomenclatura ainda não esteja padronizada. A Cloudflare e o Pi o chamam de Code Mode; a Anthropic o chama de Programmatic Tool Calling; e um artigo de engenharia anterior da Anthropic descreve a execução de código com MCP. O DeepSeek Harness (DSH) também oferece um PTC Mode intimamente relacionado.

As implementações diferem principalmente em relação ao local onde o ambiente de execução roda: em um contêiner do provedor do modelo, no harness do agente ou, mais recentemente, por meio de um servidor MCP em Code Mode. Este último permite que clientes MCP usem chamadas programáticas de ferramentas sem implementar seu ambiente de execução próprio. No entanto, isso pode reduzir a granularidade das aprovações do lado do cliente, de modo que a autorização e a aprovação para operações individuais ainda devem ser impostas pelo servidor e seus manipuladores de ferramentas.

Agentes de programação produzem e revisam artefatos em prosa, como especificações, ADRs e planos, muito mais rápido do que humanos. Diffs de texto escondem a intenção sob reformulações e ruídos de formatação, tornando difícil ver se um plano mudou significativamente. A revisão semântica de textos editados por IA adiciona uma camada sobre o diff de texto: um LLM analisa mudanças no significado, como fatos alterados, declarações conflitantes, critérios de aceitação redefinidos e mudanças de escopo. Semelhante à revisão automatizada de PR, mas para textos em prosa, ela pode ser implementada como uma skill de agente que roda sempre que um agente de programação edita um documento. Vimos equipes da Thoughtworks usarem essa técnica para reduzir a carga cognitiva e a fadiga de revisão, ajudando revisoras a entenderem melhor as alterações no trabalho planejado antes da implementação.

Testes como dados em vez de testes como código significa expressar casos de teste como dados estruturados, tipicamente YAML ou JSON, em vez de código de teste. Um harness de teste específico do projeto lê esses dados e executa o código subjacente: o harness fornece os blocos de construção, enquanto os casos de teste definem como eles são montados. A técnica não é nova; BDD com Gherkin é um excelente exemplo. O que a torna relevante novamente é que os agentes de programação por IA agora escrevem mais código, incluindo testes. Percebemos que um esquema definido restringe melhor o que eles produzem, tornando os testes mais fáceis de gerar e revisar, com menos código de teste gerado por IA. Algumas de nossas equipes também viram um caso de uso atraente na modernização de sistemas legados, em que os mesmos casos de testes expressos como dados podem ser executados tanto no código legado quanto no moderno, apenas trocando o adaptador da estrutura. Isso ajuda as equipes a verificar se o sistema modernizado se comporta como o original, pelo menos para os casos cobertos pelos testes. O uso dessa técnica com IA ainda é relativamente novo para nós, e não a aplicamos de forma ampla. No entanto, os resultados até agora são promissores, e achamos que vale a pena avaliar.

As instruções para agentes de programação, como orientações emAGENTS.md, habilidades de processo e fluxos de trabalho, tendem a crescer ao longo do tempo. Embora cada nova regra possa ser útil isoladamente, esse acúmulo frequentemente resulta no inchaço de instruções para agentes. As instruções se tornam longas, contraditórias e desatualizadas, especialmente se as equipes praticarem rendição cognitiva a skills de agentes e importarem conjuntos inteiros de instruções externas.

Primeiro, converta todas as instruções possíveis em hooks ou verificações determinísticas. Em seguida,reavalie as instruções a cada novo modelo e exclua aquelas das quais ele não precisa mais — testes de progressão, em vez de testes de regressão. A Anthropic removeu mais de 80% do prompt de sistema do Claude Code em seus modelos mais recentes sem perda mensurável, já que os modelos de fronteira agora seguem instruções de forma mais confiável. A revelação progressiva de contexto mantém as instruções restantes fora do caminho até que sejam necessárias.

Há uma tendência crescente de rendição cognitiva a skills de agentes, um antipadrão no qual as equipes adotam grandes bibliotecas de skills selecionadas e mantidas pela comunidade ou frameworks pesados de agentes de IA sem entender completamente o que eles fazem. Da mesma forma que importar cegamente grandes dependências de software, as pessoas desenvolvedoras podem tratar essas skills como funcionalidades prontas para uso e perder de vista como o sistema subjacente funciona. Esse não é um problema novo; exemplos semelhantes incluem copiar e colar código sem entendê-lo ou confiar demais em padrões de projeto genéricos. No entanto, a proliferação de ferramentas de IA tornou o problema muito mais evidente.

Além da perda de compreensão do sistema, abrir mão da avaliação crítica introduz riscos de segurança: instruções em prompts não revisadas podem chegar aos pipelines de execução. Skills de fontes diferentes também podem entrar em conflito quando não tiverem sido projetadas para funcionar juntas. É importante inspecionar e revisar as instruções das skills antes de adaptá-las, em vez de usar indistintamente skills genéricas de agentes. À medida que os modelos subjacentes se tornam mais capazes, skills genéricas mantidas pela comunidade podem se tornar desnecessárias ou obsoletas, tornando mais valioso selecionar e manter skills específicas de domínio adaptadas ao contexto do projeto.

Observamos muitas pessoas não desenvolvedoras migrando de plataformas no-code para agentes de programação como o Claude Code e o OpenAI Codex. Celebramos o fato de as pessoas resolverem seus próprios problemas, mas a shadow IT acelerada por IA, seja criada por não programadoras ou por desenvolvedoras, traz riscos. O primeiro deles é a segurança. O segundo é que softwares oriundos de fora do desenvolvimento tradicional costumam carecer de testes, esteiras de implantação e observabilidade. Isso é especialmente importante quando a ferramenta de produtividade de uma pessoa é adotada por toda a sua equipe ou departamento. As organizações devem priorizar a governança com limites e diretrizes para aplicações geradas por IA. Em nossa experiência, é melhor fornecer às colegas ambientes e enterprise harnesses para uma experimentação segura do que apagar seu entusiasmo. Seja firme em relação à segurança e ofereça às ferramentas úteis um caminho claro para suporte.

A proliferação de documentação gerada por IA ocorre quando as equipes usam agentes de IA e ferramentas de desenvolvimento baseadas em especificações (SDD), como Spec-kit ou BMAD, para gerar grandes volumes de arquivos Markdown e documentação. Como a IA pode produzir documentações polidas e de aparência profissional em segundos, o resultado pode criar uma ilusão de qualidade de software e rápido progresso. Ao contrário do código-fonte, no entanto, a documentação raramente passa por portas de qualidade automatizadas ou testes de CI. À medida que os projetos evoluem, os repositórios acumulam rapidamente especificações verbosas, sem manutenção e contraditórias que as pessoas desenvolvedoras não têm tempo para limpar, resultando em uma caótica "grande bola de lama de documentação".

Essa superabundância de documentação obsoleta é particularmente problemática em fluxos de trabalho de agentes. Quando agentes de programação leem um repositório repleto de registros de decisões arquitetônicas desatualizados ou arquivos de especificação conflitantes, esses documentos redundantes e contraditórios consomem um contexto valioso e fornecem informações não confiáveis. Em vez de ajudar no desenvolvimento, o contexto obsoleto pode desorientar as ferramentas de IA e resultar em uma geração de código ruim. Para manter a eficácia dos agentes, as equipes devem tratar o Markdown como um artefato de primeira classe, dedicando um esforço humano deliberado para podar, refinar e consolidar os arquivos de contexto gerados, garantindo que o contexto do agente permaneça claro, relevante e confiável.

Às vezes nos pegamos definindo por padrão qualquer tarefa que exige um LLM para usar o modelo mais capaz disponível, sem prestar atenção ao custo, à latência ou à capacidade necessária. Chamamos isso de uso indiscriminado de modelos de ponta. Os modelos de ponta podem custar significativamente mais e executar mais lentamente do que seus equivalentes mais ágeis. Trabalhos rotineiros como exploração, edições simples ou resumos são frequentemente melhor atendidos por um modelo menor ou até mesmo modelos open-weight. Mude de nível manualmente, por subagente ou por meio de configurações do harness que alternem automaticamente com base na complexidade ou etapa da tarefa. Cada modelo tem seu próprio cache de prompt, portanto mude em limites naturais — uma nova sessão, um subagente ou na transição do planejamento para a implementação — em vez de por requisição. Um alerta sobre o nosso alerta: modelos mais capazes às vezes concluem tarefas usando menos tokens, então use o perfilamento de contexto para verificar se a sua otimização está funcionando.

Em um Radar anterior, alertamos contra o uso da taxa de transferência de programação como medida de produtividade. À medida que a indústria pressiona pela adoção de IA e busca métricas tangíveis, vemos cada vez mais métricas baseadas em atividade, como a porcentagem de código gerado por IA ou tokens consumidos, sendo tratadas como medalhas de honra. Embora tais métricas possam indicar níveis de adoção, elas são péssimos indicadores para ganhos reais de produtividade.

Para medir a produtividade de forma significativa, continuamos recomendando frameworks consolidados, como as métricas do DORA e qualidade de colaboração, além de vincular as melhorias diretamente aos resultados de negócios. Tratar métricas de atividade como metas, em vez de sinais, aumenta o risco de cair na armadilha da Lei de Goodhart. Já vimos pessoas desenvolvedores gerando trabalho inútil com IA apenas para atingir essas metas.

O teatro de supervisão humana é manter uma pessoa humana no loop de um agente como uma etapa de aprovação vazia, em vez de uma verificação real. O humano aprova ações, prompts ou diffs que não consegue avaliar de forma realista.

A etapa de aprovação funciona como um sumidouro de responsabilidade: ninguém realmente se responsabiliza pela decisão. Em vez disso, nosso conselho é fazer uma triagem. Reserve a revisão humana para alterações que um humano possa julgar genuinamente, usando supervisão humana baseada em níveis de risco. Para o restante, mude o foco da revisão de alterações individuais para o direcionamento do sistema por meio de testes de mutação, testes baseados em propriedades, modelos formais como TLA+ e Quint e revisão semântica assistida por agentes.

Um meat proxy é uma pessoa que repassa sem pensar o resultado não verificado de um LLM para um colega, encaminhando-o sem ler, validar ou adicionar um julgamento substantivo. É uma violação da boa etiqueta de IA e, em nossa infeliz experiência, um problema crescente. Quando você atua como um meat proxy, transfere o fardo da verificação para a pessoa seguinte e se exime de sua própria responsabilidade de garantir um trabalho de qualidade. Isso é semelhante ao teatro de supervisão humana, com a diferença de que se trata de uma autoria falsa em vez de uma aprovação falsa. Em nenhum dos casos o ser humano adiciona valor. O rascunho das diretrizes de IA da KDE resume bem: "Não seja um meat proxy."

À medida que os custos de tokens aumentam, as equipes recorrem cada vez mais a ferramentas como Headroom, RTK e Tamp para encolher seus prompts. No entanto, aconselhamos contra a compressão ingênua de contexto, que pode introduzir vários problemas sutis. Primeiro, ele frequentemente interfere com o prompt caching; reduzir a contagem de tokens enquanto se perdem acertos de cache (cache hits) pode levar a contas finais mais altas. Segundo, uma compressão agressiva causa perda de informação, degradando o desempenho e a precisão dos loops de agentes. Terceiro, algumas ferramentas dependem de um LLM para resumir o contexto durante a compressão, adicionando latência e custos que anulam o objetivo original.

Antes de adotar essas ferramentas, analise o uso de contexto e avalie rigorosamente tanto o custo líquido quanto a precisão das tarefas; a redução de tokens não significa nada se os caches de prompt falharem ou se o desempenho dos agentes degradar. Dê preferência a ferramentas que comprimam as saídas das ferramentas enquanto preservam referências aos dados brutos e que façam a poda (prune) do histórico apenas de uma vez nas fronteiras das tarefas para proteger os prefixos de cache.

Pull requests encadeados dividem uma grande alteração em uma cadeia ordenada de pequenos pull requests (PRs) e dependentes. Em vez de ter como alvo a branch principal do repositório, cada PR subsequente direciona para a branch diretamente abaixo dele na pilha. Vimos um grande aumento no interesse por essa técnica recentemente devido à rápida adoção de ferramentas de programação assistidas por IA. As equipes adotam essa abordagem para reduzir a latência de revisão e o tempo ocioso das pessoas desenvolvedoras. Ao avaliar camadas pequenas e isoladas, as pessoas revisoras enfrentam menor sobrecarga cognitiva. O suporte de ferramentas também melhorou para apoiar esse fluxo de trabalho; o GitHub introduziu recentemente suporte nativo.

Apesar das ferramentas melhores, colocamos essa técnica no anel “Cautela”, pois muitas vezes ela serve como uma solução alternativa para uma decomposição inicial mal feita. O empilhamento não cria problemas de decomposição; ele expõe aqueles que já existiam. O risco não é a técnica em si; é usá-la como substituto para esse planejamento. O empilhamento habitual e indiferenciado pode facilmente se tornar uma desculpa para escrever uma única alteração enorme. Mantemos a posição de que o melhor hábito é especificar, dividir, dimensionar e entregar o trabalho como unidades pequenas e independentes.