Técnicas

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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