Um artigo industrial sobre revisão de código com agentes na Ericsson [1][2] chegou a um número que naturalmente vira manchete: aproximadamente 96% de acerto. A pergunta responsável não é se o número impressiona. É o que exatamente foi contado, quem avaliou, qual problema o sistema tentou resolver e quanto dessa evidência pode viajar para outra empresa.
O valor está na arquitetura do trabalho, não apenas no modelo
A solução separa a revisão em quatro perspectivas — legibilidade, manutenibilidade, confiabilidade e desempenho — e coordena agentes especializados. Um construtor de contexto busca diff, arquivos, metadados do repositório, dependências e estrutura do sistema por integrações com GitLab e um grafo de conhecimento de código. Cada agente recebe um recorte contextual compatível com sua função, e um orquestrador agrega o relatório [2].
Essa escolha importa porque revisão de código não é somente reconhecer padrões no trecho alterado. Ela depende de intenção, arquitetura, convenções, dependências e impacto fora do diff. O estudo oferece um sinal prático de que contexto específico e separação de perspectivas podem reduzir comentários desconectados. Como não houve ablação nem comparação controlada com outras arquiteturas, porém, ele não prova qual componente causou o resultado.
O denominador dos 96% é 206 apontamentos
A avaliação aplicou a solução a sete commits de quatro projetos proprietários da Ericsson, todos em Python. Cinco desenvolvedores sêniores, autores dos commits avaliados, classificaram 206 apontamentos. Desses, 197 foram considerados corretos e nove incorretos: 197/206, ou aproximadamente 96% [2].
Essa métrica responde quantos apontamentos produzidos foram considerados válidos. Ela não mede quantos problemas existentes ficaram invisíveis ao sistema, porque o estudo não construiu um conjunto completo de defeitos conhecidos. Portanto, não é recall, cobertura total de defeitos ou taxa de prevenção de incidentes. Também não mede economia de tempo, custo por revisão, mudança de qualidade em produção nem comparação com revisores humanos trabalhando sem o sistema.
Entre os corretos, 135 foram classificados como médios ou altos
Dos 197 apontamentos corretos, 65 foram classificados como alta importância, 70 como média e 62 como menor. Assim, 135/197 — aproximadamente 69% — foram considerados itens que deveriam ou precisavam ser corrigidos [2]. Esse recorte é útil porque separa validade de prioridade. Ainda assim, a importância foi julgada pelas mesmas pessoas que escreveram o código e conheciam o contexto, o que pode introduzir maior rigor ou maior tolerância.
Por que o radar classificou o paper como observar
- A amostra contém apenas sete commits, quatro projetos, uma empresa e uma linguagem.
- Foi usado um único runtime, o Kiro CLI com seu modelo padrão; outros modelos e configurações podem produzir resultados diferentes.
- Não houve grupo de comparação, ablação ou baseline equivalente para isolar o efeito do contexto, dos agentes especializados ou da orquestração.
- Os commits e relatórios são proprietários e não foram publicados, limitando replicação independente.
- Os próprios autores dos commits avaliaram correção e importância; o estudo reconhece o possível viés.
- Duas das cinco autorias têm afiliação com a Ericsson; os autores declaram não conhecer interesses financeiros ou relações pessoais concorrentes.
- O trabalho recebeu apoio parcial da Knowledge Foundation no projeto InScale, informação que precisa acompanhar a leitura.
A classificação ‘observar’ não significa ‘irrelevante’ nem ‘falso’. Significa que a evidência é suficientemente interessante para orientar uma hipótese e suficientemente limitada para impedir uma conclusão universal. O artigo foi aceito no PROFES 2026, mas a cópia disponível é a versão 1 no arXiv, publicada em 14 de setembro de 2026 [1][2].
Como transformar o sinal em um piloto que produz decisão
- Defina uma amostra estratificada por linguagem, domínio, tamanho do diff, criticidade e familiaridade do revisor.
- Monte um conjunto de problemas conhecidos para medir precisão e também cobertura; apontamento correto sem detectar falhas relevantes é insuficiente.
- Compare diff isolado, contexto do repositório e arquitetura multifacetada para descobrir qual componente agrega valor.
- Registre falsos positivos, problemas não encontrados, severidade, tempo do revisor, custo de modelo e taxa de correções aceitas.
- Mantenha controles determinísticos, testes, análise estática, proteção de branch e responsabilidade humana pela aprovação.
- Repita execuções para medir variabilidade e preserve modelo, versão, configuração, prompts, contexto e artefatos de avaliação.
O sinal reforça uma tese de arquitetura séria
O estudo não mostra que basta adicionar mais agentes. Ele mostra uma direção: dividir responsabilidade, fornecer contexto governado, restringir saídas, agregar evidências e manter julgamento humano. O NIST SSDF [4] continua relevante porque revisão generativa não substitui práticas seguras do ciclo de desenvolvimento. E pesquisas complementares sobre IA revisando pull requests [3] ajudam a construir comparação, mas não replicam o case Ericsson.
O que vamos acompanhar nas próximas versões
- Replicações fora da Ericsson, em outras linguagens, equipes e categorias de mudança.
- Publicação de dados anonimizados, instrumentos, configurações ou conjuntos reproduzíveis.
- Comparações entre modelos, abordagens de contexto, agentes especializados e revisores humanos.
- Métricas de cobertura, tempo, custo, segurança, qualidade pós-merge e incidência de defeitos.
- Correções, novas versões do preprint e a publicação definitiva nos anais do PROFES 2026.
Promissor o bastante para testar; limitado demais para prometer
O melhor uso do case não é repetir ‘96% de acerto’. É entender que revisão de código com IA fica mais plausível quando o sistema conhece o contexto e distribui perspectivas — e, em seguida, exigir evidência local antes de ampliar autoridade. Uma empresa madura consegue sustentar as duas ideias ao mesmo tempo: o resultado merece atenção e ainda não merece generalização.
Nota editorial e de responsabilidade
Fatos e números estão atribuídos às fontes diretas. Interpretações, desenho de piloto e implicações para arquitetura são pontos de vista pessoais e profissionais do autor, não fatos universais. O recorte é pequeno, proprietário, concentrado em uma organização, uma linguagem e um modelo, sem comparação controlada ou replicação independente disponível. A marca Ericsson é citada porque identifica o contexto declarado pelo próprio paper; não há patrocínio, parceria ou endosso. Este conteúdo é informativo e não substitui avaliação técnica, jurídica ou de segurança. Tech Human e Trustyu atuam comercialmente em temas relacionados. Pesquisa, estrutura e redação tiveram assistência de IA; a publicação foi autorizada por Fernando Parreiras em 16/09/2026, sem revisão humana independente adicional.