O Gargalo Migrou para o Review — e Ninguém Concorda sobre o Que Vem Depois

Code review nunca foi apenas sobre encontrar bugs. Por vinte anos ele foi o ponto de controle da profissão: o único lugar em que observação, julgamento e imposição por acaso coincidiam — um humano que conseguia ver uma mudança, decidir se ela pertencia ali e barrá-la com um botão. A IA não eliminou esse ponto de controle. Ela o sobrecarregou.

O post anterior desta série terminou com uma regra que imponho a mim mesmo: nunca aceitar tudo de uma vez — todo diff que entra em merge é lido. A objeção mais afiada que ouvi desde então é uma que qualquer engenheiro experiente reconhece como argumento aritmético, não como preguiça: isso não escala. Agentes geram código mais rápido do que qualquer humano lê. Uma disciplina que exige ler tudo é uma disciplina com prazo de validade embutido. A medição confirma a pressão: o Engineering Report 2026 da Faros AI, extraído de telemetria de 22.000 desenvolvedores, encontrou a duração mediana do review 441,5% maior — e, de forma mais silenciosamente alarmante, um aumento de 31,3% nos pull requests mergeados com zero review.

As respostas da indústria — deixar agentes revisarem os agentes, substituir review por verificação, racionar atenção humana por risco — são normalmente debatidas como escolhas de workflow. Não são. Cada uma é uma proposta sobre para onde mover o ponto de controle, e cada relocação abre mão, silenciosamente, de algo que o ponto original oferecia. Essa troca é o assunto deste post.

O que é, de fato, um ponto de controle

Um ponto de controle não é qualquer lugar onde o processo por acaso faz uma pausa. É o lugar onde três coisas coincidem: observação (você consegue ver o que está passando), decisão (você consegue julgar aquilo contra a intenção) e imposição (você consegue barrar). Remova qualquer uma das três e o controle vira teatro — um dashboard sobre o qual você não pode agir, um portão através do qual você não consegue ver, uma opinião que ninguém é obrigado a obedecer.

Antes que a teoria se empilhe, um exemplo concreto. O Agente A gera um PR de 700 linhas durante a noite. O Agente B — um agente de review — lê, deixa dois comentários e aprova. Um humano faz o merge às 8h30 da manhã seguinte, entre a daily e a primeira reunião. Toda parte do ritual aconteceu: algo observou a mudança, algo a julgou, alguém impôs a decisão apertando o botão de merge. Agora pergunte onde estava o ponto de controle. A observação morava no Agente B. A decisão morava no Agente B. A imposição morava em um humano que nunca leu o diff. As três funções executaram — elas só nunca coincidiram em ninguém. E a única parte dessa cadeia que pode ser paginada às 3 da manhã é a que viu menos. Isso não é um ponto de controle. É a silhueta dele.

O review pré-merge conquistou sua antiga posição porque um único ato — um humano lendo um diff com o botão de merge na mão — entregava as três funções ao mesmo tempo. E, porque entregava, ele silenciosamente controlava cinco coisas diferentes simultaneamente: defeitos, conformidade com a intenção, transferência de conhecimento, accountability e coerência arquitetural. Um checkpoint, cinco tipos de controle — o que é precisamente o motivo de ele parecer tão estrutural e de ninguém ter itemizado o que ele carregava.

Um ponto de controle que funciona precisa satisfazer requisitos mais duros do que a maioria das discussões admite, e nomeá-los é o que torna a situação atual legível.

Ele precisa casar com a taxa do fluxo que governa. Esse é o requisito que a era dos agentes quebrou, e a lei de Amdahl explica limpidamente por quê: geração paraleliza — cinco agentes, cinco diffs — enquanto julgamento não. A compreensão de uma pessoa é um recurso single-threaded com clock fixo. Um pipeline de geradores paralelos alimentando um juiz serial converge para o throughput do juiz, não importa quantos geradores você adicione; a frota não te deixa mais rápido, ela deixa a fila na frente do ponto de controle mais longa. Escrevi sobre esse formato em a aritmética do backlog: um consumidor dimensionado para o regime estacionário tem zero capacidade de recuperação. O revisor agora é esse consumidor.

Ele precisa ser independente daquilo que controla. Um checkpoint que compartilha modos de falha com aquilo que checa é um observador correlacionado, não um controle. Esse é o requisito mais em risco na onda de ferramentas, e voltarei a ele.

Suas falhas precisam ser atribuíveis. Controle implica alguém responsável quando o portão deixa passar o que deveria ter pegado. Um ponto de controle que não tem dono é um filtro, não um controle.

E ele precisa ficar onde a intervenção ainda é barata. Posição é alavancagem: o mesmo defeito custa uma frase no momento do briefing, um parágrafo no momento da spec, um comentário de review no momento do merge e uma ponte de incidente às 3 da manhã. Pontos de controle migram para montante em sistemas maduros exatamente por isso — quanto mais cedo o ponto, mais densa a informação e mais barata a correção.

Uma última propriedade importa, e é justamente a que os dados da Faros pegam em flagrante: um ponto de controle saturado não degrada graciosamente — ele é contornado. Qualquer engenheiro de redes sabe o que o tráfego faz quando um checkpoint não consegue acompanhar: ele desvia. É isso que "merges com zero review 31,3% acima" significa. Não é uma política que alguém escreveu; é o fluxo encontrando o caminho ao redor de um checkpoint que parou de casar com a taxa. Esse é o estado mais perigoso em que um ponto de controle pode estar — ainda presente no organograma, ainda nomeado no documento de processo, e já não controlando nada. O risco real do gargalo de review nunca foi lentidão. É que o ponto de controle se torna nominal enquanto todos ainda acreditam que ele existe.

Segure esses requisitos — casamento de taxa, independência, atribuibilidade, posição e o comportamento de contorno sob saturação — e as três respostas da indústria deixam de ser um debate de estilo. Cada uma é uma relocação do ponto de controle, e cada uma sacrifica um requisito diferente para restaurar o casamento de taxa.

Três relocações, três sacrifícios diferentes

Relocação um: para jusante, dentro de outro agente. O review do Copilot passou de sessenta milhões de reviews, um salto de dez vezes em menos de um ano — um número que Addy Osmani destaca em seu ensaio Agentic Code Review. Review em velocidade de máquina para código em velocidade de máquina restaura o casamento de taxa perfeitamente. O que ele abre mão é de independência e atribuição. O revisor é a mesma classe de sistema que escreveu o código, treinado nas mesmas distribuições, cego de maneiras correlacionadas — um observador que compartilha os modos de falha do observado, que é exatamente a única coisa que um observador não pode fazer. E ele não pode ser paginado, então a accountability se transfere silenciosamente para quem clica em merge — que, segundo os dados, é cada vez mais a mesma pessoa que fez o briefing do agente. A manhã das 8h30 acima é essa relocação, e não é uma anedota: um estudo do MSR 2026 sobre 40.214 pull requests descobriu que 77,5% dos PRs agênticos mergeados tiveram o merge feito por quem os submeteu, contra 57,6% dos PRs humanos. Trace o laço de controle aí: uma pessoa faz o briefing, uma IA escreve, uma IA correlacionada aprova, a mesma pessoa faz o merge. Observação, decisão e imposição nunca saem de um laço de um só — o ponto de controle não foi relocado; ele colapsou para dentro.

Relocação dois: para montante, dentro da spec e dos testes. O campo do verificar-em-vez-de-revisar é o mais intelectualmente sério: construa sistemas de verificação — testes que o agente precisa satisfazer, suítes de conformidade, rollouts em sandbox — e deixe-o iterar até que o software demonstravelmente funcione. Paul Dix defende a versão maximalista: dados verificação e direcionamento, um agente pode "continuar a refinar até simplesmente funcionar". Como relocação, isso é coerente: a imposição torna-se automática e em velocidade de máquina, e a decisão migra para montante, para o momento da especificação — a posição com maior alavancagem, exatamente para onde a teoria de controle diz que ela deveria ir.

O que isso abre mão é da largura da observação. O antigo ponto de controle observava o que uma mudança de fato fazia, julgado por uma pessoa que sabia o que ela deveria fazer. O novo observa apenas o que a spec expressa. Verificação é uma propriedade de um artefato — este código atende a esta especificação? — e é checável em velocidade de máquina. Mas se a especificação captura a intenção é uma propriedade que nenhum artefato carrega, e nada no laço a checa: os testes provam que o código faz o que os testes dizem; ninguém prova que os testes dizem o que você quis dizer. O controle sobre a intenção não desapareceu — ele migrou para quem escreve a spec, normalmente a pessoa que passou o tempo menos disputado pensando sobre o problema. E uma segunda coisa escapa por completo: a compreensão da organização. Um pipeline puro de verificar-em-vez-de-revisar produz artefatos verificados e um time que não entende nenhum deles — uma dívida invisível no momento do merge, faturada no próximo incidente e impagável por refatoração, porque ela nunca esteve no código. Quando a produção surpreende todo mundo, o que eventualmente acontece, a resposta roda na velocidade da compreensão, não na velocidade da verificação. A relocação é progresso real em casamento de taxa e posição; o custo não precificado é que a observação estreitou de "o que o sistema faz" para "o que a spec previu".

Relocação três: para montante, dentro de um classificador. Roteamento por risco — a resposta mais madura operacionalmente, e a de Osmani — mantém o ponto de controle humano completo, mas apenas para mudanças que o merecem: humanos são donos dos merges de grande raio de impacto, checam por amostragem o que é rotineiro e deixam a ferramenta triar o resto. "O gargalo não desapareceu; ele migrou para a verificação", escreve ele, e seu modelo mantém um humano responsável por todo merge consequente, o que preserva atribuição onde ela mais importa. A sutileza está no que aconteceu estruturalmente: o ponto de controle agora é o classificador. O que decide entre "rotineiro" e "consequente" — uma heurística, um modelo, um tech lead cansado às 17h — herda a posição que o revisor ocupava, com uma fração do escrutínio. Controle amostrado é um padrão legítimo de engenharia; todo load balancer faz health check de um subconjunto. Mas a amostra só controla o fluxo se o amostrador for confiável, e as mudanças com maior probabilidade de serem classificadas erroneamente como rotineiras são precisamente aquelas cujo risco ninguém entendeu ainda. O estágio serial também não desapareceu aqui. Ele migrou para uma caixa menor e menos examinada.

Contra todas as três relocações estão os dados comportamentais, que dizem que a maior parte do campo não relocou seu ponto de controle de forma alguma — deixou-o falhar no lugar. A pesquisa State of Code da Sonar encontrou 96% dos desenvolvedores não confiando plenamente em código gerado por IA, e apenas 48% verificando-o consistentemente. Metade da profissão está mergeando código em que não confia, sem ler e sem verificar — não porque algum campo tenha proposto isso, mas porque é o que um checkpoint saturado produz: contorno, usando o crachá do controle.

Onde está o seu?

Há uma relocação em torno da qual o debate fica circulando sem chegar a pousar, e vou esboçá-la apenas como um formato para pensar: controle como um gradiente, em vez de um portão. Nenhum time funcional dá root a um engenheiro novo no primeiro dia; autonomia é conquistada por domínio, a partir de um histórico, e revogada por incidente. Apontado para agentes, isso se torna um orçamento de autonomia — merge-sem-ler como privilégio conquistado por classe de tarefa e retomado automaticamente por defeitos escapados, do mesmo jeito que um error budget governa o ritmo de release. A engenharia em setores regulados é o que mais chegou perto disso: um framework de supervisão graduada publicado em junho de 2026 roteia toda mudança para um de três níveis — human-in-the-loop, human-over-the-loop, automated-with-monitoring — segundo impacto regulatório, reversibilidade e sensibilidade dos dados. Esse é um gradiente calibrado por raio de impacto, que dá para saber de antemão; o que estou descrevendo é calibrado por histórico, que não dá. Acho o formato atraente e não confio plenamente nele: calibrar o orçamento é julgamento, então o estágio serial migra para montante mais uma vez, e o histórico de um agente foi conquistado sob o modelo de ontem — uma atualização silenciosa invalida o livro-caixa de um jeito que a experiência humana nunca faz. Um gradiente que decai no relógio errado é um portão com marketing melhor.

E é aí que preciso parar, porque as evidências atualmente não sustentam a certeza de ninguém, incluindo a minha. A mesma literatura que mede taxas de defeito explodindo também mede 83,8% dos PRs de agentes aceitos por mantenedores open source, mais da metade mergeados sem modificação. Os dois achados são cuidadosos, os dois são atuais, e quem estiver vendendo uma resposta definitiva para o gargalo do review está à frente dos dados.

Então, em vez de uma resposta, as três perguntas em torno das quais eu fico circulando — colocadas a você do jeito que eu as colocaria em um design review em que o design é o da profissão:

• Onde está seu ponto de controle hoje — de fato, não nominalmente? Trace uma mudança consequente do briefing até a produção e marque o lugar em que um humano ainda poderia vê-la, julgá-la e barrá-la. Se você não consegue encontrar esse lugar, seu problema não é de gargalo.
• O que ele ainda controla, e o que ele silenciosamente parou de controlar? O review carregava cinco coisas ao mesmo tempo — defeitos, intenção, conhecimento, accountability, coerência. O que quer que seu ponto controle agora, a diferença entre aquela lista e esta está sendo abandonada hoje, por escolha ou não.
• Que evidência você aceitaria para movê-lo? Mergear sem ler é relocar controle para algo — uma suíte de testes, um classificador, um histórico. Nomeie o algo, nomeie a evidência — e pergunte-se se você teria aceitado esse mesmo padrão de uma dependência em dezembro de 2021.

O ponto de controle se sustentou por vinte anos porque nada nunca correu mais rápido do que ele, então ninguém precisou dizer de que ele era feito. Agora algo corre — e um incidente vai responder essas perguntas por qualquer time que não as responder antes.