Durante anos, o gargalo foi escrever código. Os agentes resolveron isso: hoje um pull request sai no tempo que antes levava uma pausa para o café. O problema não sumiu, só se moveu de lugar. Agora o gargalo é outro: decidir o que entra no main.
Um CTO resumiu bem o dilema num fio da comunidade que rodou bastante entre devs: "revisar código é mais difícil que escrever código". E se a IA multiplica por dez o volume de código, a revisão humana se transforma no gargalo fatal. Não é pessimismo: são os dados de 2026.
Os números que mostram que o problema se moveu
Várias medições independentes apontam na mesma direção. O benchmark de LinearB 2026 achou que os PRs feitos por agentes demoram 5,3x mais tempo para serem retomados por um revisor que os PRs sem assistência; os PRs assistidos por IA esperam 2,47x mais. O revisor não ficou lento: simplesmente há muito mais para revisar.
- CircleCI 2026: o throughput das feature branches cresceu 59% de um ano para o outro, mas o da principal caiu ~7% para a equipe mediana, e a taxa de sucesso caiu a 70,8%. Se produz mais código e se mergea peggio de lo que parece.
- GitHub Octoverse 2025: os merges de PRs cresceron 29% de um ano para o outro, impulsionados pelos asistentes de código.
- Faros AI / DORA 2025: 31% mais de PRs fazem merge sem revisão. Quando a cola cresce, o primeiro que se corta é a rigurosidade.
- Qodo (1M de PRs analizados): 17% tinham issues de severidade alta que terian passado uma revisão manual feita sob pressão de tempo.
O análisis de Codacy o diz direto: "o gargalo se moveu de escrever código para decidir se é seguro mergear". Generar código ficou barato. Verificarlo se converteu no produto.
Por qué revisar código de agentes é diferente
Não é o mesmo trabalho de sempre com mais volume. Son três problemas nuevos:
- Volumen: un dev con asistente abre vários PRs no tempo que antes abría um.
- Contexto: el revisor recibe o diff já terminado, sem a travesía de decisões que o produjo. Tiene que reconstruir a intenção só com o ticket, a descrição do PR e o código.
- Confianza: o código de IA parece correto numa leitura casual. É mais difícil de revisar, não mais fácil: há que caçar discrepâncias sutiles entre intenção, arquitetura e comportamento real.
Por isso, os revisores genéricos de diff não alcanzan. Un revisor de IA sem contexto do repo se comporta como "un junior sin memoria del repositorio": comenta coisas que soan razoáveis e ruido que a equipe já decidió há meses. No reporte de Qodo, 44% de quem sente que a IA degrada a qualidade culpa a falta de contexto. Ese é o ponto: o contexto separa a señal do ruido.
O fix real não é más revisores: é cambiar o pipeline
Contratar más revisores humanos não escala. O que escala é mover o trabalho onde corresponde, em três capas:
Capa 1 — Checks deterministas, antes de que chegue um humano. Lint, type check, SAST, detección de secretos, cobertura, complejidad. Se falham, o PR nem entra na cola de review. Son baratos, repetibles e não se cansam. Essa capa sozinha já descongestiona a fila.
Capa 2 — Triaje com IA. Um agente de review que resuma o que cambió, agrupe riscos por severidade e arranque com os pontos quentes. O humano já não começa desde um diff em branco. Há opções de sobra: o PR review de GitHub Copilot, CodeRabbit, PR-Agent ou Qodo — cada uma com seu trade-off entre contexto, ruido e preço. O requisito não negociable: que tenha contexto do repo, não só o diff.
Capa 3 — O humano só em juicios. Alineação com a arquitetura (o código de IA costuma satisfazer o prompt e violar o diseño), lógica de negocio, mantenibilidad e impacto cross-team. Decisións que uma herramienta não pode tomar porque não esteve nas reuniões.
O pipeline completo se ve assim — o propuso un dev no discusión más votada de GitHub Community sobre herramientas de IA em 2026:
análisis estático → revisão de IA → tests → revisão humana → merge
Cada capa atrapa uma clase de erro distinta. Ninguna substituye à seguinte; se empilhan. E um truco barato que suma muito: a revisão cruzada entre modelos — que um agente revise o que escreviu outro — porque os erros que comete um modelo rara vez os detecta ele mesmo (como nos passa com nosso próprio código). Addy Osmani o resume como o passo de "conductores a orquestadores": o humano dirige, os agentes ejecutan e se fiscalizan entre eles.
Checklist prático para esta semana
- Se o CI falha, que o PR nem chegue ao revisor humano. Que a fila só receba diffs que já passaron os checks.
- Faz que o agente documente as decisões no PR: por que escolheu esse caminho, não só o que cambió. Reconstruir intenção é o que más tempo roba.
- O agente de review precisa contexto do repo (convenções, arquitetura, reglas do projeto), não um diff pelado. Se comenta ruido, não é problema do modelo: é falta de contexto.
- Separa por severidade. O humano deveria ver 5 riscos priorizados, não 50 comentarios no mesmo nível.
- Mide o pickup time dos teus PRs, não as líneas generadas. Essa métrica te diz se o teu pipeline de review aguanta.
A boa noticia: não hace falta bajar a barra nem trabalhar más horas. Há que cambiar onde se aplica o esforzo. Escrever se volvió commodity; a vantaxe competitiva agora está em decidir rápido e bem o que se mergea. Quem resolve isso, destrava o único gargalo que le queda a seu equipa.