Como o LinkedIn faz code review com múltiplos agentes de IA em escala

Colar um revisor de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → genérico na frente do GitHub não escala. Foi essa a conclusão dos engenheiros do LinkedIn, que, segundo reportagem da InfoQ, construíram uma plataforma de code review baseada em múltiplos agentes de IA independentes, tratando a revisão de código como infraestrutura de produção, não como um plugin.

O objetivo declarado é gerar revisões que os desenvolvedores achem que vale a pena aplicar: maximizar a relação sinal-ruído e levar em conta os "padrões, convenções e conhecimento tribal que modelos de IA genéricos consistentemente ignoram". Como resume a fonte, gerar comentários de review em escala é trivial. O difícil é tudo o que vem depois.

Por que um revisor de IA genérico não basta

O LinkedIn identificou três limitações estruturais em depender de um revisor pronto de prateleira:

• Pontos cegos de modelo único: um só modelo tende a perder sempre a mesma classe de bugs e a sinalizar sempre os mesmos problemas de baixo valor.
• Customização insuficiente: fica difícil codificar ao mesmo tempo políticas de toda a organização, convenções específicas de cada repositório e orientações direcionadas a cenários de alto risco.
• Falta de controle operacional: sem monitoramento e avaliação, não dá para tratar o revisor como parte da infraestrutura de engenharia.

O ponto central é que os comentários precisam ser factualmente ancorados no diff (e não alucinados), específicos das convenções daquele código (e não boas práticas genéricas) e chegar antes do revisor humano, não depois.

O modelo de múltiplos agentes

A plataforma ataca cada limitação com uma decisão de arquitetura:

• Vários revisores de IA independentes, usando modelos distintos e abordagens de raciocínio diferentes.
• Customização profunda e componível, cobrindo políticas da organização, convenções por repositório e regras específicas de contexto.
• Arquitetura sobre Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps →, com pipeline orientado a eventos, filas duráveis e workers escalados horizontalmente, permitindo monitorar latência, taxas de aceitação e conclusão, além de falhas de provedores.

O uso de vários agentes habilita validação cruzada. Quando múltiplos agentes identificam o mesmo problema de forma independente, o LinkedIn trata essa convergência como evidência forte. Achados únicos não são descartados automaticamente: são verificados separadamente. E sugestões cosméticas, já corrigidas, irrelevantes ou inconsistentes com o repositório são filtradas antes de virarem comentário no PR.

Os números: 63,9% de aceitação

Para medir com que frequência os devs realmente aplicam as sugestões, o LinkedIn montou um pipeline automatizado que compara cada comentário com o código efetivamente mesclado. A avaliação cobriu 5.230 comentários amostrados em 1.727 PRs, dos quais 90,1% puderam ser avaliados com alta confiança a partir do código final.

O resultado agregado foi 63,9% de sugestões aceitas, com variação grande por categoria:

• 100% dos bugs de concorrência
• 80% dos erros de lógica
• 58,1% das correções de bug
• 43,5% das mudanças de refatoração
• 40,6% das correções relacionadas a segurança

A leitura prática desses números é reveladora: a IA acerta muito mais quando aponta problemas objetivos e difíceis de enxergar a olho nu (concorrência, lógica) do que quando opina sobre estilo ou refatoração, onde entra gosto e contexto humano.

LinkedIn não está sozinho

Outras empresas atacaram o mesmo problema por caminhos diferentes. A Cloudflare construiu um sistema de orquestração em torno do agente open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → OpenCode, equilibrando de outra forma seus requisitos e restrições. Já a Databricks lançou componentes como o Unity AI Gateway (gestão centralizada de IA) e o Omnigent (tooling para devs), endereçando o que descreve como o "crescimento exponencial dos custos de coding com IA".

A convergência aqui é o recado: as grandes casas de engenharia pararam de tratar revisor de IA como feature e passaram a tratá-lo como sistema, com pipeline, observabilidade e métricas de aceitação.

O que muda para o dev brasileiro

Poucas empresas no Brasil operam na escala de PRs do LinkedIn, mas o modelo é adaptável para startups e times de tech que já usam agentes de código no dia a dia. Alguns princípios que dá para levar sem montar um cluster Kubernetes dedicado:

• Cruzar mais de um modelo em vez de confiar num único revisor. Rodar duas ferramentas ou dois modelos e priorizar o que os dois concordam já reduz falso positivo, sem grande esforço de infra.
• Codificar as convenções do seu repositório (arquivos de regras, guias de estilo, contexto do projeto) em vez de aceitar boas práticas genéricas que ignoram o "conhecimento tribal" do time.
• Filtrar antes de postar: comentário cosmético ou já resolvido só gera ruído e faz o time começar a ignorar a IA. Menos comentários de mais valor vencem o volume.
• Medir aceitação. O pipeline que compara sugestão com código mesclado é o que separa "a IA fala muito" de "a IA ajuda". Sem métrica de aceitação, não dá para saber se o revisor está ajudando ou atrapalhando.

O desalinhamento entre categorias também é um guia de onde apostar: se seu time vai priorizar a IA em algum lugar, os dados do LinkedIn sugerem começar por detecção de bugs de lógica e concorrência, deixando refatoração e estilo como território ainda majoritariamente humano.

O que fica em aberto

A reportagem da InfoQ resume o desenho da plataforma, mas os detalhes técnicos completos, quais modelos, como as regras são compostas e como o pipeline de avaliação foi implementado, estão no artigo de engenharia original do LinkedIn, para quem quiser reproduzir a abordagem. Também fica em aberto se taxas de aceitação medidas contra o código mesclado capturam qualidade real: um dev pode aceitar uma sugestão ruim ou rejeitar uma boa. A métrica é um proxy útil, não uma verdade absoluta.

Fonte: InfoQ