Perigosamente Pulando a Leitura do Código: Quando LLMs Escrevem Código Mais Rápido do Que Você Pode Ler

A premissa é simples: e se parássemos de ler código gerado por LLM por completo? Tratá-lo como assembly, bytecode ou JavaScript transpilado — a fonte em linguagem de alto nível se torna outra forma de código de máquina. Essa ideia vem do relatório do retiro da Thoughtworks e do post de blog de Facundo Olano.

Por que isso faz sentido

LLMs produzem saída não determinística e geram código muito mais rápido do que humanos podem ler. Revisar cada diff não é mais viável. Em vez de abrir mão do rigor, mova-o para outro lugar: especificações e testes.

Pré-requisito organizacional

Esta não é uma decisão individual ou de equipe — deve ser organizacional. A lei de Amdahl se aplica: maximizar a velocidade de geração de código sem reestruturar processos não traz ganhos reais. Você não pode ter alguns devs bombeando 20 mil linhas de porcaria por dia enquanto outros ainda leem e aprovam.

Os requisitos incluem:

• Remover humanos no meio do processo, reduzir coordenação e pontos de controle
• Oferta virtualmente infinita de requisitos, engenheiros responsáveis por fluxos de trabalho de forma autônoma
• Retrabalho é quase gratuito, então não impeça trabalho incorreto — detecte via especificações/testes

Fluxo de trabalho proposto

Use uma especificação padronizada em Markdown como a nova unidade de conhecimento. Product owners e engenheiros colaboram na especificação e nos casos de teste para regras de negócio. Faça check-in destes no repositório junto com o código de implementação.

Verificações automatizadas de pull request garantem:

• Testes passam
• Código está em conformidade com a especificação

A especificação — não o código — é o que a equipe entende, revisa e pela qual é responsável.

Distinção importante

Especificações não são prompts. Testes não são TDD. Trata-se de rigor deslocado para a camada de contrato, não para a camada de implementação.