Revisão de PR não é gargalo. É aula

Recentemente peguei pra revisar um PR que ficou dois dias na minha fila.

Não porque eu estivesse ocupado. Eu ia abrir todo dia, ler um pedaço, e voltar pra outra coisa. Mas eram 240 linhas de uma vez, e cada bloco que eu abria tinha um problema diferente — não de sintaxe, não de lint. De sentido.

Em dois dias, deixei mais de 40 comentários.

Tinha regra de negócio ignorada. Tinha teste sem asserção de verdade — só expect(true).toBe(true) disfarçado de teste sério. Tinha emoji no meio do código. Esse último eu olhei três vezes pra ter certeza de que estava vendo o que estava vendo.

Naquela mesma semana, tive uma calibragem com um LT de outro time que eu respeito muito. É uma conversa que eu costumo ter de tempos em tempos — atualizar como o projeto na franquia está andando, o que está funcionando, o que não está. Quando contei do emoji no código, ele parou, riu e respondeu:

"Aqui também. Tivemos PR com comentário de IA em cima de teste, e no fim do arquivo, um emoji."

A gente riu. Mas a risada durou pouco. Porque não era piada — era o jeito de digerir o que estava virando rotina: códigos sendo pushados sem a mínima revisão ou cuidado por parte do dev.

O que revisão de PR nunca foi

O framework mental que a gente vem carregando trata revisão de PR como gargalo de produtividade. Algo entre o "código pronto" e o "código em produção". Quanto mais rápido passa, melhor.

Mas isso nunca foi o que revisão de PR é.

Revisar um PR não é descobrir se o código "está certo". É entender por que aquele código existe, se ele deveria existir daquela forma e qual impacto ele pode causar no restante do produto.

É, ao mesmo tempo, uma checagem técnica (lint, padrão, vulnerabilidade, complexidade), uma leitura de regra de negócio (essa validação faz sentido no fluxo X? E quando o cliente Y está nesse estado?), uma leitura arquitetural (isso respeita o que a gente decidiu naquele ADR que ninguém leu?), e, em produto complexo, uma leitura de história (esse mesmo caminho foi tentado em 2022 e quebrou por esse motivo — lembra?).

Tem uma porção desse trabalho que a IA faz bem. Lint, estilo, padrões, vulnerabilidades conhecidas, complexidade ciclomática fora do padrão. Isso é mecânico. Um experimento controlado da USI Lugano (Suíça) e da Florida State University com 29 devs profissionais mostrou que revisores com apoio de IA não aumentaram a detecção de bugs de alta severidade e ainda reduziram o tempo dedicado a procurar fora das linhas apontadas pela ferramenta. A IA ajuda no mecânico — e estreita o olhar no resto.

Mas tem uma porção que não é mecânica. E essa porção é a que mais importa.

O problema do contexto

Aqui é onde a tese começa a ficar específica.

Um estudo recente (SGCR, dez/2025) colocou isso em número: LLMs treinados em código aberto não captam lógica de negócio específica de cada empresa. Quando os pesquisadores injetaram no prompt as especificações de negócio do produto, a taxa de adoção dos comentários da IA subiu de 22% pra 42%. Praticamente dobrou.

O que esses 20 pontos percentuais medem? Medem a distância entre "comentário plausível" e "comentário correto". Sem contexto de negócio, a IA produz comentários que parecem certos — formato impecável, argumentação coerente, citação de boas práticas. Mas não são. São inferências. E a diferença entre inferência e verificação é exatamente o que estamos terceirizando.

Tem um segundo estudo que deixa isso concreto. Uma análise de 278 mil conversas reais de code review em projetos open-source (mar/2026) mediu a taxa com que cada sugestão era adotada pelo autor do PR. Sugestões de revisores humanos foram adotadas em 56,5% dos casos. Sugestões de agentes de IA, em 16,6%. E mais da metade das sugestões de IA não adotadas estavam incorretas ou foram resolvidas por correções alternativas — não era questão de estilo ou preferência.

IA não erra por ser burra. Erra porque o material que ela tem no momento da revisão não é o material que a decisão exige.

O atalho que vira cegueira

Aqui entra o pedaço que mais me preocupa.

Um experimento randomizado de 2026 (Shen & Tamkin) colocou devs aprendendo uma biblioteca nova em duas trilhas — com IA e sem IA — e mediu compreensão conceitual, leitura de código e capacidade de debug no final. O grupo com IA teve Cohen's d de 0.738 a menos nessas três dimensões. Effect size grande, com queda real e mensurável de habilidade. Sem ganho médio de tempo.

Outro experimento, da TU Darmstadt, com 85 devs, foi mais fundo no mecanismo: quando o código entregue pela IA é de maior qualidade, o dev aprende menos. O cognitive load cai porque a entrega é boa — e o conhecimento procedural do dev cai junto.

Em outras palavras: o "atalho" de hoje está custando a capacidade de revisar amanhã.

É aqui que o emoji no código começa a fazer sentido. Não como anedota — como sintoma. O dev que mandou aquele PR provavelmente leu cinco linhas geradas, viu que tinham formato certo, deu commit. Não testou. Não rodou. Não entendeu por que existia. Não viu o emoji, porque a IA não tinha motivo pra achar que aquilo era estranho.

O mesmo vale pro colega de outro time. Comentário de IA em cima de teste. Teste que a IA escreveu, revisado pela IA, e ninguém do time percebeu que era um teste circular.

A gente está terceirizando não só a revisão. Está terceirizando a capacidade de revisar.

O que a IA faz bem — e onde isso muda

Eu não quero que a IA pare de revisar PR. Quero que ela continue.

Que revise. Aponte problemas óbvios. Encontre inconsistências. Sugira melhorias. Procure bugs. Questione padrões. Faça tudo aquilo que ela é muito boa em fazer. Se ela conseguir tirar 30, 40 ou 50% do trabalho mecânico da revisão, melhor ainda.

O que eu não quero é que isso faça a gente esquecer por que ainda precisamos de gente revisando código.

O DORA Report 2024 trouxe um número que desmonta a fantasia do "resolver o gargalo". Cada 25% de aumento na adoção de IA em times de desenvolvimento associou-se a uma queda de 7,2% na estabilidade de entrega. A IA acelera a fila de review — e piora o que vem depois. O relatório 2025 confirmou o padrão com quase 5 mil profissionais: 30% relatam pouca ou nenhuma confiança no código gerado por IA. Stack Overflow Developer Survey 2025, na mesma linha: 66% dos devs citaram como maior frustração "soluções quase certas, mas não quite", e 45% disseram que debugar código gerado por IA é mais demorado.

O gargalo não sumiu. Ele só mudou de lugar. Saiu da fila de review e entrou no plantão de produção.

Quando até a Amazon precisou de gente

Existe um caso público recente que resume tudo isso com datas, fontes e números. É grande, é real, e é difícil de ignorar.

Em agosto de 2024, Andy Jassy publicou que a Amazon tinha migrado mais de 30 mil aplicações de Java 8 e 11 pra Java 17 com o Q Developer, e que 79% dos code reviews gerados automaticamente pela ferramenta tinham ido pra produção sem mudanças. Foi o tipo de número que faz qualquer líder técnico olhar pra planilha de revisão e pensar: tá, a máquina resolve.

Dezesseis meses depois, em dezembro de 2025, o Financial Times reportou que um agente interno da Amazon chamado Kiro tinha deletado e recriado um environment de produção no Cost Explorer durante uma tarefa de manutenção, derrubando o serviço por 13 horas numa região da China. A Amazon respondeu que o problema tinha sido erro humano — controle de acesso mal configurado — e não a IA. Ao mesmo tempo, adicionou peer review obrigatório pra qualquer mudança em ambiente de produção.

Em março de 2026, dois incidentes em sequência. No dia 2, prazos de entrega errados em marketplaces da Amazon tiraram cerca de 120 mil pedidos do sistema — uma revisão interna citou o Q Developer como um dos principais contribuintes. No dia 5, foi a vez do Amazon.com em si sair do ar por seis horas. No dia 10, a divisão de e-commerce emitiu um briefing interno mencionando "tendência de incidentes" com "alto raio de impacto" e "uso novel de GenAI para o qual melhores práticas e salvaguardas ainda não estão totalmente estabelecidas", e instituiu uma política temporária de 90 dias: mudanças em cerca de 335 sistemas classificados como Tier-1 passam a exigir dois revisores e auditoria formal.

A Amazon não voltou atrás. Não desligou o Q Developer, não abandonou o Kiro, não voltou pro "tradicional". O que ela fez foi adicionar o que o briefing interno chamou de controlled friction — fricção controlada. Mais gente revisando, em mais etapas, com mais processo. O discurso oficial continua sendo "IA acelera". A política oficial agora é "IA acelera, mas com freio de mão".

O papel do líder técnico nisso

Aqui é onde a conversa muda de registro.

Porque se a IA escreve, a IA revisa e a IA decide, sobra pro dev apertar merge. E aí talvez a gente tenha resolvido o problema errado.

O trabalho do líder técnico nesse novo cenário não é acelerar a revisão. Não é medir tempo médio de PR. Não é substituir a fila de revisão humana por uma fila de revisão por IA pra "liberar o time".

É garantir que, mesmo com toda essa automação, os desenvolvedores continuem aprendendo a pensar sobre o código que escrevem. É defender o espaço onde o conhecimento do produto, as decisões arquiteturais e a experiência das pessoas se encontram com o código que está sendo produzido — porque é exatamente esse espaço que forma o próximo sênior do time.

A melhor coisa que aconteceu naquele PR de 240 linhas não foi eu ter pego o bug. Foi o dev que abriu o PR ter voltado, lido cada um dos 40 comentários, e reescrito a feature do começo — agora entendendo o que estava construindo.

Se até a Amazon, dona do CodeWhisperer e do Q Developer, teve que adicionar mais gente revisando — não é falta de sofisticação da ferramenta. É limite estrutural do que ferramenta faz.

O dev manda o código. Quem aprova sou eu. E, quando estoura em produção, a conta não chega pra quem escreveu — chega pra quem assinou.

Isso não é gargalo. É aula. E a gente não pode terceirizar isso sem perder o que vem depois.

Por onde ir

• SGCR: A Specification-Grounded Framework for Trustworthy LLM Code Review (arXiv 2512.17540) — o estudo que mediu 22% → 42% de adoção ao injetar contexto de negócio.
• Human-AI Synergy in Agentic Code Review (arXiv 2603.15911) — 278 mil reviews reais; 56,5% de adoção humana vs 16,6% de IA.
• Deep Learning-based Code Reviews (arXiv 2411.11401) — USI Lugano / Florida State, 29 devs profissionais: IA não aumenta detecção de bug crítico e estreita o olhar.
• How AI Impacts Skill Formation (Shen & Tamkin, 2026, preprint) — RCT com Cohen's d = 0.738 de queda de habilidade.
• The Price of AI Assistance (Diebel et al., TU Darmstadt, 2025) — 85 devs: código de IA de maior qualidade → menor conhecimento procedural via cognitive load reduzido.
• DORA 2024 — Accelerate State of DevOps (dora.dev) — cada +25% de IA = −7,2% de estabilidade.
• DORA 2025 — State of AI-assisted Software Development (Google Cloud blog) — 30% relatam pouca ou nenhuma confiança no código gerado por IA.
• Stack Overflow Developer Survey 2025 — AI (survey.stackoverflow.co/2025/ai) — 66% frustrados com "quase certo, mas não quite".
• Amazon Q Developer — marco de US$ 260M (AWS DevOps Blog, ago/2024) — fonte primária da fase "investiu e deu certo".
• Amazon — resposta oficial sobre o incidente Kiro (aboutamazon.com, fev/2026) — "user error, not AI", com confirmação de "mandatory peer review for production access".
• Amazon — política de 90 dias após incidentes com Q Developer (Business Insider, mar/2026) — "Q was one of the primary contributors" + 2 revisores em sistemas Tier-1.