Estamos produzindo código mais rápido do que lemos

Leitura: ~7 minutos

Gerar código ficou rápido demais — e agora estamos produzindo código mais rápido do que lemos. Durante décadas, escrever código era caro. Cada linha custava tempo de uma pessoa qualificada, e por isso quase tudo que entrava no sistema tinha passado pela cabeça de alguém que o entendeu antes de digitar. Hoje, IA, agentes, ferramentas de linha de comando e IDEs inteligentes produzem código numa velocidade impressionante. Isso cria um problema novo: a capacidade de produzir software está crescendo mais rápido que nossa capacidade de compreendê-lo. Um desenvolvedor consegue aprovar em um dia milhares de linhas que não escreveria sozinho no mesmo período. O gargalo deixa de ser digitação. Passa a ser compreensão.

Pela primeira vez na história da programação, talvez seja mais fácil produzir código do que entender todo o código que estamos produzindo.

Leitura: ~7 minutos

Ouvir resumo (57s) — voz gerada por IA, narração dos pontos principais do post.

A produção acelerou. A compreensão não.

No ERP, que carrega décadas de produção real, sempre houve uma garantia implícita: o volume de código que entrava por mês era limitado pela capacidade do time de escrever — e, junto com a escrita, vinha o entendimento. Quem escrevia, entendia. Quem revisava, lia algo que outra pessoa havia raciocinado antes.

Isso mudou. Um agente bem alimentado gera em uma tarde o que um desenvolvedor produzia em duas semanas. A velocidade de digitação — que nunca foi o verdadeiro gargalo, mas servia de limitador natural — desapareceu. O que sobra é a parte que ninguém acelerou: ler, questionar, encaixar aquilo no sistema que já existe, com seus vinte anos de história, suas integrações fiscais, seus clientes de atacado que usam a tela de um jeito que nenhum diagrama documenta.

A tentação aparece todos os dias: aceitar o código porque “funciona”. Rodou, passou no teste rápido, entregou a funcionalidade. Mas código que ninguém entendeu não é entrega — é promessa feita por outra parte.

Pull request gigante não é revisado. É deferido.

A aritmética é simples. Se a geração cresceu dez vezes e o tempo de revisão não cresceu nada, cada revisor está olhando dez vezes mais código com a mesma atenção. O cérebro não multiplica atenção por dez. Ele faz o contrário: passa a rubricar. O botão “aprovar” vira um ato administrativo, não uma verificação.

E tem um agravante que a estatística de bugs não captura: o código correto isoladamente e errado arquiteturalmente. A função funciona. O teste passa. Mas ela duplica regra que já existia em outro módulo, consulta a tabela pela rota errada, ignora o padrão que sustenta as integrações do sistema. Em três meses, quando alguém precisar mudar aquela regra fiscal, vai encontrar duas versões — e vai alterar uma delas, sem saber que a outra existe. É assim que sistemas morrem: não de uma vez, mas por acúmulo de decisões corretas localmente e incompatíveis entre si.

Antes da IA, o tamanho de um pull request era limitado pelo esforço de digitar. Hoje um PR de quatro mil linhas sai em uma hora. E revisão de verdade, a que envolve entender o contexto e as consequências, roda a uma velocidade de centenas de linhas por hora — no máximo. A conta não fecha, e fingir que fecha é o erro.

Código gerado por agente: o conhecimento morre na sessão

O terceiro problema é silencioso. Quando um agente gera código, parte do raciocínio — por que aquela abordagem, o que foi descartado, qual restrição foi respeitada — fica no contexto da sessão. Quando a sessão acaba, esse conhecimento desaparece. Sobrou o código; evaporou o porquê.

Em time tradicional, o conhecimento se espalha por conversa, revisão e convivência. O desenvolvedor júnior que escreveu a função aprendeu algo construindo-a e conversou sobre ela no review. Com agentes, a mesma pessoa aprova três vezes mais código e aprende três vezes menos sobre o próprio sistema. Em dois anos, você tem um sistema que ninguém do time entende inteiro — e uma equipe que depende da IA para navegar nele. Dependência que não é de digitação, é de compreensão. Essa é mais difícil de reverter.

Somem-se as dependências criadas automaticamente: o agente precisa de uma biblioteca, adiciona, resolve o problema, segue. Ninguém avaliou licença, maturidade, superfície de ataque ou se aquele pacote duplica funcionalidade que o sistema já tinha. O supply chain do sistema cresce sem que ninguém assine embaixo.

Como revisar código gerado por IA

Se o gargalo é compreensão, a resposta precisa atacar compreensão — não proibir produtividade. O que funciona na prática:

Estreitar o canal. PRs pequenos continuam sendo a unidade de revisão, agora mais do que nunca. Agente que gera quatro mil linhas de uma vez está com escopo mal definido. Hoje, cinco PRs de oitocentas linhas sequenciais — cada um revisável de verdade — a um monólito deferido.

Ler pedindo explicação, não só o código. Exigir do agente (ou de quem o conduziu) um resumo: o que mudou, o que não mudou, quais regras de negócio foram tocadas, quais alternativas foram descartadas. Metade do custo de compreensão é recuperada em dez linhas de texto. A outra metade exige leitura de verdade — e é a metade que ninguém pode pular.

Revisar a fronteira primeiro. Onde o código novo encosta no sistema velho é onde mora o problema arquitetural. Assinatura de função, consulta a dados compartilhados, regra fiscal duplicada. O miolo da função o teste cobre; a fronteira, não.

Testes e guardrails: compreensão verificada por máquina

Ninguém vai voltar a entender linha por linha tudo que entra. A saída honesta é deslocar parte da compreensão para artefatos verificáveis.

Testes automatizados deixaram de ser virtude e passaram a ser pré-condição. Se o código foi escrito por uma máquina, quem verifica também pode ser uma máquina — mas em condições que a máquina geradora não controla. Teste escrito junto com o código pelo mesmo agente vale menos que teste escrito a partir da especificação, por caminho separado. Cobertura de regressão nos fluxos que sustentam o negócio — emissão de documento fiscal, fechamento de pedido, saldo de estoque — é o que permite aceitar velocidade sem aceitar cegueira.

Guardrails arquiteturais são o acordo coletivo. Camadas que o código gerado não pode atravessar, padrão de acesso a dados, limites de dependência, convenções que a revisão confirma com ferramenta, não com memória. Em sistema com décadas de produção, os guardrails são o que impede que cinco agentes autônomos, cada um resolvendo seu problema, cindam a arquitetura em silêncio. Uma checagem de dependências circulares e uma verificação de camadas no CI custam pouco e previnem o erro que nenhum teste unitário pega.

O novo papel do desenvolvedor sênior

O sênior não perdeu espaço — perdeu a ilusão de que sua função era digitar rápido. O papel volta ao que sempre foi em sistemas maduros: decidir arquitetura, definir os guardrails, revisar as fronteiras e dizer “não” para o elegante que não caberia no sistema.

O júnior também muda: aprende o sistema lendo código que não escreveu, com mediação de quem entende — o inverso do caminho tradicional, onde se aprende escrevendo. Isso exige mais, não menos, presença dos mais experientes.

A pergunta que faço ao time antes de aprovar qualquer coisa gerada por agente é simples: se amanhã esse código falhar em produção, quem consegue explicá-lo? Quando a resposta é “ninguém”, o código não foi aceito — foi apostado. E apostas em sistema que sustenta empresa há décadas não são aceitáveis, por mais rápido que tenham sido geradas.

A velocidade de produzir software vai continuar crescendo. A de compreender, não — ela cresce com pessoas, e pessoas têm ritmo. Quem equilibrar as duas curvas entrega mais rápido e com segurança. Quem só acelerar a primeira vai descobrir, da pior forma, que sistema que ninguém entende é sistema que ninguém consegue mudar.

Leitura relacionada

• Você não pode debugar o que não entende — compreensão como prática número um quando a IA escreve o código.
• Autonomia de agentes de IA: limites e riscos — os limites que definem o que um agente pode tocar sem aprovação.
• Seu processo de validação de código com IA é inadequado — por que validar código gerado exige cerimônia própria.