Humanos Ainda Vão Revisar Código?
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Estamos vivendo um momento estranho na indústria de software.
Se você olhar para as mudanças que estamos vendo em tecnologia de desenvolvimento, estamos certamente vivendo no futuro: entregando features a partir de uma mensagem no Slack, gerando aplicações inteiras a partir de uma spec, escrevendo 20 PRs em um dia sem abrir uma IDE. Cada vez mais, os engenheiros com quem trabalho e converso relatam que não escrevem mais código. A tecnologia é genuinamente sem precedentes.
E no entanto. Se você sair das demos e das threads no Twitter e olhar o que está realmente acontecendo dentro das empresas de software, vai encontrar algo constrangedor: pouca coisa mudou em termos de produtividade. Sim, existem grandes afirmações, e sim, existe mais código do que nunca. Porém, a maioria das empresas ainda parece estar entregando valor em um ritmo semelhante ao de um ano atrás.
O que é empolgante, no entanto, é que essa situação está evoluindo semana a semana. Parece que estamos em uma encruzilhada estratégica, onde empresas que diagnosticarem corretamente o porquê e fizerem os movimentos técnicos estratégicos certos vão ultrapassar significativamente as outras. E as empresas que sairão na frente serão aquelas que responderem corretamente a uma pergunta: “Humanos ainda vão revisar código nos próximos anos?”
Codar Nunca Foi o Gargalo
A razão pela qual a maioria das empresas está correndo sem sair do lugar é direta, embora desconfortável: codar nunca foi o verdadeiro gargalo na entrega de valor em software.
Embora um engenheiro escrever código certamente leve tempo, isso é apenas uma parte da cadeia de entrega de valor que começa com uma ideia e culmina em uma feature em produção. Mesmo se você focar nos aspectos de engenharia, quando olha para a maioria das empresas enterprise, vai encontrar que o trabalho de engenharia geralmente fica travado em reviews, deploy, testes e diferentes níveis de retrabalho.
Escrever código é apenas um dos muitos passos na entrega de valor com software
Isso não é uma descoberta nova, mas o que é novo é como o desenvolvimento assistido por IA tornou essa situação extremamente óbvia. Não há como examinar o estado atual da indústria sem reconhecer que o gargalo está em outro lugar.
Também podemos ver como isso não é novo dado que cada inovação sobre como acelerar a entrega parece um déjà vu de vinte anos atrás:
- Rebatizamos TDD (Test-Driven Development) como Spec-Driven Development.
- Temos diferentes versões de um ciclo red-green-refactor para manter a supervisão sobre agentes.
- Estamos falando sobre abandonar PR requests ou adotar Trunk-Based Development.
E esse é o movimento certo. Parece o mesmo porque metodologias iterativas da era Agile eram baseadas no mesmo princípio: escrever código não é o problema principal a resolver; o problema é garantir que escrevemos o código certo para entregar valor.
O Estado da Arte do Software Enterprise
Não sou pesquisador, então isso não é um estudo. Porém, tenho visibilidade sobre várias empresas de software enterprise através do meu trabalho e conexões com pessoas de diferentes áreas.
Acho que esse é um bom resumo do que está acontecendo hoje:
- Toda empresa implementou IA v0, o que significa dar aos engenheiros acesso ilimitado a ferramentas de IA.
- Organizações de software estão afogadas em PRs, por razões óbvias. No passado, se eu quisesse escrever 10 mil linhas de código, precisava escrevê-las. Agora consigo fazer isso com alguns prompts.
- Manter qualidade é um desafio. Há código demais para revisar, autores frequentemente não revisam seu próprio código, e a pressão naturalmente leva a erros.
- Há um esforço consistente para automatizar mais partes do trabalho. Isso se traduz em bugs, issues pequenas e comentários de review sendo automaticamente tratados por agentes.
- Há um esforço forte para resolver o gargalo de review de PRs, com reviews automatizados e ferramentas para auxiliar engenheiros.
E esse é um movimento lógico. Se IA v0 era acesso a ferramentas, IA v1 significa agir sobre o novo gargalo. Dado que ele mudou inteiramente de escrever código para revisar PRs, a forma natural das empresas lidarem com isso é o que estão fazendo: facilitar reviews e liberar capacidade de engenharia do desenvolvimento para dedicar a code review.
Se o gargalo está em code reviews, é natural otimizar code reviews
Porém, otimizar reviews de PRs significa iterar em um processo que pode estar quebrado. Por exemplo, usar PRs assume que duas pessoas (o autor e o revisor) vão revisar o código, mas a relação do autor com seu código mudou completamente. Afinal, ele não está mais escrevendo.
Além da atenção reduzida, se agentes continuarem evoluindo, não importa quantas pessoas revisem código. Não vai ser suficiente. O caminho natural para IA v2 será repensar o processo, tornando todo o SDLC adaptado para agentes, um movimento que algumas empresas já estão tentando.
E se pudéssemos pular essas etapas completamente?
E isso cria um risco significativo para enterprises, onde uma mudança dessas levaria meses ou talvez anos. E se outra empresa conseguisse fazer isso mais rápido que você?
A Bifurcação no Caminho
É claro que para software greenfield, v2 já chegou. A maioria das startups começando uma codebase agora vai reduzir sua dependência de reviews de PR. Esse é um problema diferente para o enterprise, no entanto. Por enterprise, me refiro a empresas com centenas ou milhares de engenheiros, uma codebase grande e estabelecida, e receita significativa.
Para essas empresas, a situação é:
- Elas possuem uma codebase brownfield complexa com níveis variados de qualidade, e code reviews são um passo crítico para evitar problemas em produção.
- Um incidente em produção resulta em perda de receita e deterioração da percepção. Se você quer um exemplo, até hoje, o GitHub teve 24 atualizações na status page em 17 dias em fevereiro de 2026.
- Mudar como centenas/milhares de pessoas trabalham requer um esforço coordenado por um longo período. Implementar mudanças técnicas para reimaginar o SDLC pode exigir ainda mais tempo.
- Se você superar tudo isso, ainda pode precisar de compliance, que frequentemente exige revisão humana.
Embora o futuro pareça estar aqui, ele também não é garantido. Agentes podem não evoluir tanto quanto os otimistas esperam. As startups construindo dessa nova forma podem enfrentar dificuldades quando suas codebases realmente crescerem. O custo de ferramentas de IA pode ser uma barreira para as expectativas mais ambiciosas.
Não há resposta óbvia: empresas de software enterprise em 2026 podem de fato estar enfrentando uma escolha difícil de estratégia técnica que vão se arrepender de errar.
A Opção Conservadora
A opção mais fácil é seguir essa tendência um passo de cada vez, assumindo que embora IA para codar veio para ficar, a forma do SDLC não vai mudar. Ainda vamos exigir que humanos supervisem todo código indo para produção em aplicações complexas, assim como fazemos agora.
Nesse caso, o caminho é de fato otimizar o processo de code review. Já temos algumas ferramentas para apoiar reviews e provavelmente teremos mais. Processos de time serão alterados para focar em code reviews. Desenvolvimento com agentes será restringido, talvez com limites de WIP em código ou PRs abertos, para balancear o sistema.
O resultado nessa situação será positivo, mas provavelmente não extraordinário. Embora deva levar a um aumento real na entrega de valor (mais do que temos agora), não vai mudar em uma ordem de magnitude. Porém, se você seguir esse caminho, estará deixando uma grande opção em aberto.
Deixe os Agentes Serem Donos do Código
Uma visão progressista envolveria remover humanos do loop de review, permitindo que agentes conduzam a entrega de código. Isso não é uma tomada completa pela IA. É pragmático. Algo como:
- Um engenheiro conduz uma feature, direcionando agentes para implementá-la com as restrições necessárias. O engenheiro tem entendimento suficiente para questionar a implementação e guiar a arquitetura, mas não precisa revisar cada linha.
- Times ainda podem testar features de ponta a ponta, garantindo que o comportamento é o esperado.
- Código é deployado para produção sem review, e a qualidade é garantida através de automação de testes, monitoramento e diferentes tipos de verificação automatizada (agêntica ou determinística).
Isso não é algo distante. Porém, se uma empresa conseguir implementar isso em escala, provavelmente entregaria valor muitas vezes superior ao que entrega hoje. Mas requer investimento substancial em tecnologia, pessoas e aspectos legais.
Para ser prático, seu código precisa ser modularizado o suficiente para que partes dele caibam no contexto de um agente. Sua automação de testes precisa ser forte o suficiente para substituir a revisão humana. Seu monitoramento deve ser eficaz, e sua resposta deve ser rápida o suficiente para tratar problemas potenciais. E os papéis desempenhados pelos engenheiros vão mudar significativamente (junto com como contratamos, recompensamos e avaliamos performance).
Se você é um líder de engenharia, aqui estão as perguntas que estou me fazendo:
- Code reviews são uma parte permanente de como construímos software, ou uma restrição que podemos eventualmente remover?
- O que seria necessário para remover code reviews de parte do nosso stack técnico?
- Que tipo de ferramentas precisaríamos para tornar deploys muito mais seguros?
- Conseguiríamos de fato construir as ferramentas necessárias, dado que codar está mais barato?
- Como os papéis de engenharia precisariam mudar se code review não fosse mais o principal gate de qualidade?
Embora desafiador, um movimento em direção a desenvolvimento conduzido por agentes é certamente viável no médio a longo prazo. Mais importante, se você não fizer isso mas seu concorrente fizer, qualquer vantagem técnica que sua empresa tem provavelmente vai desaparecer.
Escolher seu caminho não é uma decisão fácil. Mas é uma que vai importar.