# Code review com agentes na prática

Mais código. Menos revisão. O descompasso é antigo.

A Ericsson resolveu testar uma saída diferente. Em vez de tentar revisar mais rápido, colocou agentes especializados para fazer a primeira triagem de code review com contexto real do projeto.

O estudo foi publicado no arXiv em setembro de 2026 (*Using Agentic AI for contextualized and multifaceted code review at Ericsson*). Os números são extremamente reveladores — não por serem exagerados, mas pela sua precisão.

---

### O que eles fizeram

A equipe seguiu a metodologia **Design Science Research**. Isso significa que não montaram um benchmark artificial; pegaram commits reais da empresa e avaliaram a solução em ambiente de produção.

O sistema combina duas bases essenciais:
1. **Skills de agentes:** Carregam antipadrões conhecidos e específicos daquele codebase.
2. **Conhecimento do ambiente:** Fornece as regras específicas do projeto — arquitetura, convenções e restrições que não estão escritas em nenhum repositório público.

A análise ocorre estritamente em quatro eixos distintos: **legibilidade**, **manutenibilidade**, **confiabilidade** e **performance**. Nada de termos genéricos como "qualidade geral" ou "boas práticas".

---

### O que os dados mostram

| Indicador | Resultado |
| :--- | :---: |
| **Issues identificadas** | +200 |
| **Acurácia na detecção** (validada por devs da Ericsson) | **96%** |
| **Issues considerados importantes** | **69%** |
| **Issues severos** (precisam de correção obrigatória) | **33%** |
| **Issues importantes** (deveriam ser corrigidos) | **36%** |

*Fonte: Using Agentic AI for contextualized and multifaceted code review at Ericsson (arXiv:2609.15877, setembro/2026)*

---

### Por que funcionou?

O agente de review não funcionou bem só porque o modelo subjacente é potente. **Funcionou porque recebeu o contexto específico do projeto e skills orientadas aos antipadrões reais daquele código**.

Um agente sem contexto gera apenas comentários genéricos que parecem úteis, mas não agregam valor prático:
* *"Considere dividir este método."*
* *"Talvez extrair esta lógica."*
* *"Avalie a possibilidade de usar injeção de dependência."*

Comentários superficiais que o desenvolvedor lê e pensa: *"isso eu já sei"*. 

O agente da Ericsson evita isso. Como ele conhece os antipadrões do repositório e as decisões arquiteturais vigentes, suas observações são direcionadas e fundamentadas.

---

### O que Fazer vs. O que Não Fazer

#### 🚫 O que NÃO Fazer

1. **Não peça review genérico:** Comandos do tipo "Revise este código" geram sugestões genéricas e ignoram o que realmente precisa de atenção crítica no projeto.
2. **Não use um agente sem contexto do projeto:** Sem conhecer os antipadrões locais, o agente se limita a apontar regras óbvias de estilo e repeating de livros didáticos.
3. **Não confunda volume de comentários com qualidade:** Um agente que gera 50 comentários genéricos cria ruído e trabalho desnecessário; 5 comentários precisos geram valor imediato.
4. **Não trate o agente como substituto do revisor:** A triagem pode ser delegada, mas a decisão sobre o que entra em produção continua sendo responsabilidade humana.

#### ✅ O que FAZER

1. **Forneça contexto específico do projeto:** Inclua documentos de arquitetura, convenções e limites técnicos no prompt/agente.
2. **Defina antipadrões conhecidos:** Utilize *skills* focadas nas falhas e vícios de código que seu time já mapeou.
3. **Separe eixos de análise:** Avalie o código sob perspectivas bem definidas (legibilidade, manutenibilidade, confiabilidade e performance).
4. **Valide com quem conhece o código:** Os indicadores de acurácia só têm valor quando auditados por engenheiros do próprio projeto.
5. **Use o agente para triagem, não para aprovação final:** O agente aponta os problemas; o desenvolvedor decide o merge.

---

### A implicação prática

Revisar código gerado por agentes usando outro agente parece, à primeira vista, uma solução mágica: um gera, o outro revisa e o humano apenas aprova.

Na prática, esse fluxo só funciona quando o agente revisor possui o contexto do ambiente. Sem isso, o resultado é ruído puro. O estudo da Ericsson prova que a verdadeira vantagem não reside no modelo de linguagem escolhido, mas na qualidade do contexto fornecido.

> *"Um agente de review sem contexto gera comentários genéricos. Com contexto, gera comentários úteis. A diferença está no que ele sabe sobre o projeto — não no modelo que ele usa."*

---

### 📚 Fontes da Pesquisa

1. **arXiv (2026):** *Using Agentic AI for contextualized and multifaceted code review at Ericsson* (arXiv:2609.15877, setembro/2026). Estudo focado em Design Science Research com avaliação de commits reais em 4 eixos estruturados.

---

### 📖 Leituras Recomendadas

Quem quiser aprofundar supervisão e auditoria de código gerado por IA encontra o tema tratado de forma estruturada na série *Engenharia de Software Assistida por IA*, em especial no **Volume VI – Supervisão e Auditoria de Código Gerado por IA**.

💡 **Destaques:**
* 🏷️ Cupom de **30% OFF** nos eBooks: `LEIA30`
* 📖 Disponível também no **Kindle Unlimited**!

👉 **Série eBook completa:**  
%[https://link.amazon/B09KdiptI]

📖 **Livros Físicos (capa comum):**
* 📘 [Volume I - A Nova Realidade da Engenharia de Software](https://link.amazon/B0f0lA62q)
* 📙 [Volume II - Fundamentos que a IA Não Substitui](https://link.amazon/B0bOT75io)
* 📗 [Volume III - Engenharia de Requisitos na Era da IA](https://link.amazon/B0ciMaCFt)
* 📕 [Volume IV - Arquitetura e Design de Soluções na Era da IA](https://link.amazon/B0e8Z2sbn)
* 📓 [Volume V - Delegação Técnica para IA](https://link.amazon/B0eBJJBKm)
* 📔 [Volume VI - Supervisão e Auditoria de Código Gerado por IA](https://link.amazon/B0iK7wRo0)
* 📒 [Volume VII - Aplicações Reais](https://link.amazon/B0cPlnWBN)
* 📗 [Volume VIII - Engenharia de Contexto e Governança de IA](https://link.amazon/B0dmK7jno)

🔗 **Página do autor na Amazon:**  
%[https://link.amazon/B0igkvwcK]

---

#EngenhariaDeSoftware #InteligenciaArtificial #IA #SoftwareEngineering #AIAgents #CodeReview