- À medida que a quantidade e a escala de código gerado por IA aumentam exponencialmente, o modelo tradicional de revisão manual de código já não é mais válido
- Equipes com alta adoção de IA tiveram aumento de 21% na entrega de trabalho concluído e de 98% nas fusões de PRs, mas surgiu um paradoxo: o tempo de revisão de PRs aumentou 91%
- Em vez de revisar o código diretamente, o papel humano deve migrar para uma validação mais a montante, revisando especificações e critérios de aceitação (Acceptance Criteria)
- Em vez de um único gate de validação, é necessária uma estrutura de confiança em múltiplas camadas baseada no modelo do queijo suíço, com competição entre múltiplos agentes, guardrails determinísticos, BDD, sistemas de permissão e validação adversarial
- O modo de trabalho de "fazer deploy rápido, observar tudo e reverter ainda mais rápido" substitui o antigo paradigma de revisão lenta seguida de debugging em produção
Os humanos já não conseguem mais dar conta do code review
- PRs ficam parados por dias, aprovações formais acontecem sem profundidade, e a realidade é de revisores passando os olhos por diffs de 500 linhas
- O code review é visto como gate de qualidade, mas há equipes que lançaram software por décadas sem revisão linha por linha, e a popularização do code review aconteceu só por volta de 2012–2014
- Mesmo com revisão, incidentes continuam ocorrendo, e por isso foram sendo construídos sistemas como feature flags, rollout gradual e rollback imediato
Precisamos desistir de ler todo o código
- Em equipes com alta adoção de IA, o número de mudanças e o tamanho das mudanças estão crescendo exponencialmente ao mesmo tempo
- Com base em dados de 1.255 equipes e mais de 10.000 desenvolvedores (análise da Faros)
- Desenvolvedores sentem que revisar código gerado por IA exige mais esforço do que revisar código escrito por colegas
- Não dá para vencer essa batalha com revisão manual de código; o code review é um gate de aprovação do passado que já não combina com a forma atual de trabalho
Revisão de código por IA continua sendo apenas 'revisão'
- Se a IA escreve o código e a IA revisa o código, não há motivo para colocar uma UI bonita de revisão
- Ferramentas de revisão de código por IA só compram tempo, e esse tipo de revisão vai se mover para a esquerda do ciclo de desenvolvimento (shift left)
- Não faz sentido desperdiçar recursos de CI e gerenciar versões entre ciclos de revisão
- Em um ambiente onde agentes escrevem código, "olhos novos" são apenas outro agente com os mesmos pontos cegos; o valor está no loop iterativo, não no gate de aprovação
- O instinto de pensar "já vi a IA fazer besteira uma vez, então preciso sempre conferir" era racional quando a validação manual era viável, mas na escala atual isso já não é executável
Do code review para a revisão de intenção (Intent)
- O checkpoint humano precisa ser movido para montante (upstream)
- Já houve precedentes de mudança de checkpoints no desenvolvimento de software: assinaturas no waterfall → integração contínua (CI)
- O desenvolvimento orientado por especificação (spec-driven development) está surgindo como principal forma de colaboração com IA
- Humanos devem revisar especificações, planos, restrições e critérios de aceitação, sem necessidade de revisar um diff de 500 linhas
- No novo paradigma, a especificação se torna a fonte da verdade (source of truth), e o código é o resultado da especificação
- Em vez de revisar o código, revisam-se etapas (steps), regras de verificação (verification rules) e o contrato (contract) que o código deve cumprir
- A aprovação com human-in-the-loop muda de "isto foi implementado corretamente?" para "estamos resolvendo o problema certo com as restrições corretas?"
- O julgamento humano de maior valor acontece não depois da geração do código, mas antes de a primeira linha ser gerada
Construindo confiança em múltiplas camadas — modelo do queijo suíço
- LLMs não seguem instruções com confiabilidade, desviam com frequência e não são confiáveis nem para autoverificação (mesmo com o código pegando fogo, respondem com confiança que "funciona")
- A solução não é pedir ao LLM que valide, e sim pedir que escreva scripts de validação — migrando de julgamento para artefato
- Confiança é construída em camadas e, seguindo o modelo do queijo suíço, empilha-se uma série de filtros imperfeitos para que seus furos não se alinhem
Camada 1: comparação entre múltiplas opções
- Em vez de pedir a resposta certa a um único agente, três agentes tentam de formas diferentes e o melhor resultado é selecionado
- A seleção não precisa ser manual; é possível ranquear com base em critérios como passar pelo maior número de etapas de validação, ter o menor diff ou não adicionar novas dependências
- O custo de gerar opções está no nível mais baixo da história da engenharia de software
Camada 2: guardrails determinísticos
- É preciso haver uma forma determinística de validar o trabalho — testes, type checking, validação de contratos e tudo que lide com fatos, não opiniões
- Em vez de perguntar ao LLM "isso está pronto?", define-se uma etapa de validação que gera uma série de artefatos de pass/fail
- Hierarquia de guardrails:
- Diretrizes de código — podem ser implementadas com linter customizado
- Regras invariáveis da organização — exigências inegociáveis, como proibição de credenciais hardcoded, chaves de API e tokens
- Contratos de domínio — regras por framework, serviço ou área do codebase (ex.: no domínio de pagamentos, todos os valores monetários devem usar o tipo Money)
- Critérios de aceitação (Acceptance Criteria) — critérios específicos de cada tarefa
- As etapas de validação devem ser definidas antes de o código ser escrito, e não criadas depois apenas para confirmar o que já existe
- Se o agente escreve tanto o código quanto os testes, isso só desloca o problema; os critérios de validação devem vir da especificação, não da implementação
Camada 3: humanos definem os critérios de aceitação
- O ponto em que humanos agregam valor é a montante, definindo o que significa sucesso
- BDD (Behavior-Driven Development) volta a ganhar relevância
- É uma forma de descrever o comportamento esperado em linguagem natural e automatizá-lo em testes
- Antes, como também era preciso escrever o código, redigir a especificação parecia trabalho extra; em um ambiente com agentes, a especificação é o artefato primário
- Quando humanos escrevem a especificação, os agentes implementam e o framework de BDD faz a validação — se não falhar, não há necessidade de ler a implementação
- Coisas em que humanos são bons: definir "correção", codificar lógica de negócio e edge cases, e pensar no que pode dar errado
- Os critérios de aceitação escritos por humanos e verificados por máquinas são o gate que realmente importa
Camada 4: sistema de permissões como arquitetura
- O que um agente pode tocar e o que exige escalonamento (escalation) precisa ser uma decisão arquitetural
- A maioria dos frameworks de agentes trata permissões como all-or-nothing, mas a granularidade é essencial
- Um agente que corrige um bug em uma função utilitária não precisa de acesso à configuração de infraestrutura
- Um agente que escreve testes não precisa de permissão para alterar o pipeline de CI
- O escopo deve ser o mais estreito possível, desde que o agente ainda consiga realizar trabalho útil
- Ex.: se a tarefa é corrigir um bug de parsing de data em
utils/dates.py, então o acesso deve se limitar àquele arquivo e aos arquivos de teste
- Gatilhos de escalonamento também são importantes: alterar lógica de autenticação, mudar schema de banco de dados ou adicionar nova dependência são padrões que devem acionar revisão humana automaticamente, independentemente do nível de confiança do agente
Camada 5: validação adversarial
- É preciso separar responsabilidades: um agente executa a tarefa e outro agente valida — o essencial é que eles não confiem um no outro
- É o mesmo padrão antigo segundo o qual o time de QA não deve se reportar ao gerente de engenharia, e quem escreve o código não deve ser o único a revisá-lo
- Isso pode ser imposto arquiteturalmente: o agente que codifica não sabe o que o agente de validação vai verificar, e o agente de validação não pode modificar o código — adversarial por design
- Dá para ir além: um terceiro agente tenta quebrar o que o primeiro criou, mirando edge cases e modos de falha — automação de red team/blue team aplicada a todas as mudanças
O significado de "bom código" está mudando
- Os incentivos de sistemas baseados em agentes são simples: concluir a tarefa dada e satisfazer quem pediu — precisão de longo prazo ou requisitos de negócio não são motivações intrínsecas
- O papel humano é codificar isso nas restrições
- Em um mundo em que agentes geram código e agentes leem código, o formato de "bom código" tende a ficar mais padronizado, reduzindo a quantidade de direcionamento que precisa ser dada em novos codebases
- A direção futura é: "fazer deploy rápido, observar tudo e reverter ainda mais rápido"
- O oposto: "revisar devagar, ainda assim deixar bugs passarem, e depurar em produção"
- Não vamos vencer lendo mais máquinas; precisamos pensar melhor do que elas na etapa a montante em que as decisões realmente importam
- Se os agentes conseguem lidar bem com o código, deixa de importar se humanos conseguem lê-lo ou não
24 comentários
Como a revisão de código é um gargalo, dizer para não fazer revisão é tão inusitado que chega a ser engraçado kkkkkkkk
Fico curioso para saber se, antes da IA, a revisão de código realmente funcionava bem para todo mundo.
Na verdade, eram bem raras as organizações que faziam code review com rapidez e dedicação.
Muitos desenvolvedores, mesmo antes da IA, já faziam revisões de código de forma displicente, atrasada e superficial.
Pela minha experiência, as empresas de tecnologia dos EUA seguiam o padrão certinho, enquanto as de outros países, incluindo as daqui, eram uma bagunça.
Dito de outro modo, quanto mais rigorosa era a revisão, maior era o estresse no trabalho; já as revisões bagunçadas eram relativamente mais tranquilas
Acho que o desaparecimento da revisão é resultado dos incentivos de comportamento.
Se o que a empresa exige
for uma baixa taxa de erros, vai exigir revisões com mais rigor,
e se for lançamento rápido de funcionalidades, as revisões serão gradualmente omitidas.
Quando se fala que a revisão está desaparecendo, dá a sensação de que o que as empresas preferem é lançar funcionalidades rapidamente.
Mas, se eu fosse investidor, provavelmente também exigiria isso, haha
Não tenho certeza. Pensar que, porque a revisão se tornou um gargalo, não se deve mais revisar me parece esquecer o principal. Acho que, em vez disso, uma boa abordagem seria alocar obrigatoriamente tempo para revisão na mesma medida em que o tempo de implementação foi reduzido.
É uma ideia que vale considerar, mas parece que ainda prevalece a visão de que é cedo demais.
Continuar empilhando caixas-pretas?
A ideia é simplesmente tratar o código como uma caixa-preta e olhar só para o resultado... mas será que essa é mesmo uma direção desejável? Eu acho que, em algum momento, com certeza vai chegar a hora de revirar tudo o que foi escrito por AIs até agora.
É uma questão que dá para pensar de forma parecida com dizer: "Como o FSD ficou mais inteligente, o motorista pode até dormir."
Tecnicamente, parece que aos poucos vamos caminhar para uma era assim, mas o importante é como vamos superar a barreira da responsabilidade.
Eu acho que revisão de código não deixa de ser um dispositivo mínimo de segurança.
Por que a validação da intenção, que é um conceito de nível mais alto, é feita por uma pessoa..?
Na verdade, nem é preciso mandar programar usando uma linguagem de programação.
Se a mesma IA receber o mesmo prompt, revisar o resultado não seria algo parecido com testar o desempenho do modelo?
Parece que já definiram a conclusão e pediram para a LLM escrever. Sofisma.
Parece que não tem nenhuma experiência em produção
Parece conversa de sonho mesmo.
Com o passar do tempo, até a documentação perde o sentido e a tendência é fazer revisões de forma mais rigorosa, não?
Pois é~ só o texto pensado para provocar esse tipo de debate já bastava para transmitir a intenção.
Na verdade, isso é um problema que já poderia ser barrado na etapa de planejamento.
No processo de escrever código manualmente, o desenvolvedor naturalmente também faz planejamento, design, exploração, compreensão, testes, auto-revisão e, quando surgem problemas, até sugere implicitamente o processo de resposta posterior, tudo isso de forma implícita e paralela, ajustando naturalmente cada aspecto. Por isso, acho que mesmo quando testes ou revisão eram insuficientes, as coisas ainda funcionavam até certo ponto.
Mas, se eliminarmos o processo de escrever manualmente, os processos que antes eram implícitos precisam ter fronteiras explícitas. Como o agente que escreveu o código e o agente que o revisa ficam ainda mais separados, a ineficiência de comunicação aumenta. Como a confiança no agente que escreveu o código diminui ainda mais, o custo da revisão também aumenta.
Acho que isso não é parecido com o conceito de doorman's fallacy?
Esse também é um tema sobre o qual eu pensava com frequência na empresa, e achei muito bom. Pessoalmente, também preciso tentar adotar isso no Harnis, que estou desenvolvendo.
Acho que vamos aos poucos migrar para uma direção em que a revisão fique cada vez mais simplificada e os testes se tornem bem mais rigorosos.
Não parece que a ideia seja simplesmente acabar com a revisão de código, mas sim fazer a revisão com base em artefatos de nível mais alto, que permitam verificar explicitamente a intenção e se essa intenção funcionou corretamente.
No momento atual, considero desejável manter como caixa-preta os detalhes da implementação do código, desde que não estejam no nível de design ou arquitetura.
Acho que essa caixa-preta pode ir se acumulando até chegar a um ponto em que nem a IA consiga mais lidar direito com ela. Parece que todo mundo está encantado demais com a conveniência. Acho que um dia vai acontecer um grande acidente.
Também concordo com a opinião da pessoa acima. E se, de repente, descobrirmos que o modelo aprendeu errado alguma parte do código humano e percebermos que isso foi sendo refletido no código até agora? Esse dia pode acabar sendo o dia em que tudo vira de cabeça para baixo..
Por melhor que o modelo mais recente seja, se ele não conseguir tirar nota máxima no benchmark SWE "sempre" (6 noves, 0,999999), acho que essa possibilidade continua em aberto.
Revisão de intenção. Belo termo.
Eu estava pensando em como responder nesta era acelerada pela IA, e este é um ótimo texto que traz uma nova perspectiva sobre revisão de código!