Ler código gerado por IA: quando vale a pena

Ler código gerado por IA demais é o erro silencioso de quem trabalha com software crítico. A tese central é simples: o volume de código que você lê não deve ser reduzido, mas o volume que você gera deve crescer muito. O código barato serve para testar, medir, verificar e derrubar hipóteses antes que qualquer linha entre no produto.

Ler código gerado por IA: o que realmente mudou

Ler código gerado por IA mudou de papel: antes a leitura era o filtro principal porque escrever era caro, agora gerar é barato e o gargalo virou decidir o que merece atenção humana. O volume de código disponível cresce mais rápido que a capacidade de revisão, então a pergunta correta não é quanto ler, mas o que ler.

Theo, engenheiro conhecido pelo canal Theo t3.gg, chamou a atenção para esse ponto no vídeo publicado em 22 de julho de 2026. Ele descreve uma mudança de proporção: antes escrevia cerca de 200 linhas por dia e lia aproximadamente 1.000; hoje lê um volume parecido, gera mais de 2.000 e faz merge de algo em torno de 500.

Esses números são estimativas do próprio autor, não um estudo medido. Mesmo assim, a proporção ilustra o argumento: a quantidade de código que existe fora da produção cresceu muito, e boa parte dela não precisa passar por revisão linha a linha. O erro seria tratar todo código como se fosse destinado ao merge.

A consequência prática aparece na distribuição do tempo. Se você tenta ler tudo, o tempo de leitura consome a capacidade de gerar código de verificação. Se você ignora o que importa, o risco sobe. O equilíbrio depende da camada em que o código vive, não de uma regra universal.

As quatro camadas de importância do código

A importância do código forma uma escala: no topo fica o slop descartável, embaixo o código cuja falha causa dano real, e a maior parte dos engenheiros passa o dia nas camadas do meio. Reconhecer a camada antes de decidir quanto ler evita dois erros opostos: revisar demais o irrelevante e revisar de menos o crítico.

Theo propõe quatro faixas. A camada A é código que ele prefere que ninguém leia, como os 10.000 linhas de JavaScript que ele escreveu apenas para organizar cerca de 100 arquivos. A camada B é código que precisa funcionar, mas cuja falha não é catastrófica. A camada C inclui sistemas cujo erro gera prejuízo sério ou demissão. A camada D é o código em que uma falha pode matar alguém, como firmware de marcapasso.

Camada	Exemplo	Revisão humana esperada
A: slop	Script de 10.000 linhas para mover 100 arquivos	Nenhuma, ou quase nenhuma
B: apoio	Ferramenta interna, automação de baixo risco	Assinaturas e contratos
C: negócio	ERP financeiro, serviço com receita	Leitura e testes relevantes
D: crítico	Firmware de marcapasso	Linha a linha, com verificação adicional

Ninguém vive em uma única camada. Quem usa construtores de aplicativos por prompt, como o Lovable, fica quase todo o tempo na camada A. Quem trabalha em infraestrutura crítica transita entre C e D. O ponto central é que a mesma pessoa deveria produzir código em todas as faixas, inclusive na última, para criar ferramentas de verificação.

Por que código crítico exige mais código, não menos

Código crítico exige mais código de verificação, não menos: cada linha que entra em produção pode ser cercada por dezenas ou milhares de linhas descartáveis que testam hipóteses. A ideia inverte a intuição comum de que sistemas críticos devem ser protegidos de IA, porque o código de apoio não entra no produto e serve apenas para aumentar a confiança.

A proposta de Theo é literal: cada linha que entra no produto deveria ter 100 linhas de slop verificando, e o sistema deveria ter cerca de 10.000 linhas de código descartável para validar a operação. Isso inclui debuggers próprios, runtimes de teste, hooks de compilador e sistemas de logging construídos especificamente para observar o comportamento do sistema.

O argumento tem uma resposta preparada para a objeção previsível. Se a camada de verificação também for crítica demais para IA, você sobe mais um nível e cria ferramentas que introspectam as execuções das próprias ferramentas de teste. Em algum momento, alguém precisa aceitar que existe código cuja função é ser descartável.

Ele menciona um relato em que cerca de 80% do código gerado vai para harnesses de teste e guardrails, com o modelo lendo os resultados desses harnesses. O número é uma experiência compartilhada citada no vídeo, não um benchmark independente, e serve como exemplo de fluxo, não como meta universal.

O que revisar linha a linha e o que ignorar

Assinaturas de função, definições de API e contratos públicos merecem leitura linha a linha; corpos de função em camadas de apoio podem ser ignorados com mais frequência. Essa separação é o mecanismo prático para manter qualidade sem transformar a revisão no gargalo do time.

Theo diz que lê todas as assinaturas de função e todas as definições de API do projeto Lakebed. A justificativa é de manutenção: uma API instável encarece atualizações futuras e aumenta o risco de cada release. O corpo da função importa menos quando o contrato está correto e existe teste cobrindo o comportamento.

O desenvolvedor citado como Kotek descreve uma variação do mesmo método. Depois de um diff grande, ele pede ao agente um resumo do que mudou em cada arquivo, em vez de ler o diff inteiro. Assinaturas e nomes de função continuam visíveis; o interior da função fica em segundo plano.

Há um limite claro nessa abordagem: ela funciona quando você consegue confiar em testes e verificação automática para o comportamento não lido. Sem essa cobertura, ignorar o corpo de uma função apenas transfere o risco para produção.

Como usar agentes para verificar código importante

Agentes e modelos baratos podem verificar código importante quando você os usa para explorar hipóteses, não para decidir o que entra em produção. O fluxo é gerar código descartável que testa teorias, mede alternativas e expõe falhas antes que a mudança chegue ao repositório principal.

Um exemplo descrito por Theo é validar uma nova API ou SDK colocando a interface em um pacote local e pedindo a vários agentes com modelos menores que construam algo em cima dela. Se modelos mais fracos conseguem usar a API sem ajuda, o desenho provavelmente está claro; se falham, a interface precisa de ajuste.

Outro uso é testar hipóteses de desempenho. Em vez de pedir a amigos para montar testes de carga, Theo relata dizer a um agente que ele tem acesso à AWS e pedir que suba infraestrutura temporária para testar quanto tráfego o sistema aguenta. O agente executa o experimento e devolve dados; o código do experimento é descartado depois.

O mesmo padrão se aplica a lint e observabilidade. Theo afirma que quase nunca escrevia regras de lint personalizadas e que agora gera essas regras com frequência, além de construir debuggers pontuais e hooks de compilador para instrumentar código React e observar desempenho.

Nos três casos, o código descartável tem uma tarefa e um prazo. Ele responde a uma pergunta, mede um comportamento ou expõe uma falha, e depois pode ser jogado fora sem culpa.

O que ninguém deve deixar de revisar

Nada nesta proposta autoriza parar de revisar código que entra em produção: merges, releases e mudanças de contrato continuam exigindo cuidado humano proporcional ao dano possível. A tese é sobre onde gastar a energia de leitura, não sobre reduzir a verificação do que chega ao usuário.

Theo afirma explicitamente que não está pedindo para verificar menos código do que antes, nem para acelerar merges inseguros. Ele também diz que código de nível D, em que a falha pode matar, deve seguir com revisão linha a linha, e talvez até com menos linhas escritas por dia se o tempo disponível cair.

O que muda é a existência de uma camada intermediária de verificação que antes era cara demais para existir. Portar um trecho de Go para Rust apenas para comparar desempenho, escrever testes que ninguém tinha pensado ou simular três teorias concorrentes com agentes são usos que antes custavam tempo demais.

Um revisor com Claude Code ou outro agente de terminal pode levantar inconsistências antes de um humano olhar o diff. Theo descreve que não leva código ao time antes de vários agentes verificarem a mudança, o que muda o tipo de dúvida que chega à revisão humana.

Erros comuns ao revisar código gerado por IA

Um erro comum é medir a importância do próprio código pelo prestígio do projeto, e não pelo dano real de uma falha. Isso leva a revisar demais sistemas toleráveis e a revisar de menos partes críticas que parecem triviais.

O segundo erro é presumir que a única saída para código gerado é revisão linha a linha ou descarte total. Theo chama isso de falta de criatividade: o engenheiro deveria procurar onde cortar as camadas, separando assinaturas, contratos e testes do corpo das funções.

O terceiro erro é comparar contextos diferentes. Código de um site com poucos usuários não tem o mesmo peso de firmware médico, e tratar os dois com a mesma régua distorce a conversa. Theo afirma que a discussão fica quase impossível porque cada pessoa assume que o interlocutor está na mesma camada que ela.

O quarto erro é acreditar que o volume de código gerado deve ser sempre revisado, mesmo quando ele nunca entra no produto. Código de experimento pode ser descartado, desde que a conclusão do experimento seja verificada antes de virar decisão.

FAQ sobre ler código gerado por IA

• Preciso ler todo o código que um agente escreve? Não, se parte desse código não vai para produção e serve apenas para testar hipóteses. O que precisa de leitura humana é o que entra no produto e o contrato que outros times vão consumir.

• O que é slop no contexto de código? Slop é código gerado sem pretensão de qualidade, usado para explorar uma ideia, medir algo ou validar uma suposição. Ele costuma viver em outro repositório ou em uma pasta separada, longe do código de produção.

• Como validar uma API sem revisar o corpo de cada função? Leia as assinaturas e as definições de API, depois peça a modelos menores que construam algo sobre ela. Se eles conseguem usar a interface sem explicação, o contrato está claro.

• Isso vale para firmware de marcapasso? O firmware continua exigindo revisão linha a linha e verificação rigorosa. A diferença é que você pode gerar código descartável para testar teorias, portar comparações de desempenho e instrumentar o sistema antes do merge.

• Gerar mais código não aumenta o risco de bugs? O risco depende de onde o código vai. Código descartável pode falhar sem consequência; código que entra em produção continua passando por revisão, testes e verificação proporcional ao dano possível.

• Qual o papel dos modelos baratos nesse fluxo? Modelos menores servem para uso descartável, como testar se uma API é fácil de entender ou comparar caminhos de implementação. Modelos mais fortes ficam reservados para o que exige precisão.

• Preciso de testes automatizados antes de ignorar corpos de função? Sim, na prática. Ignorar o interior de uma função só é seguro quando existe cobertura que detecte regressões e quando o contrato da função está claro para quem consome.

• O que muda para quem trabalha com ERP financeiro? O ERP continua no grupo de código crítico, com revisão cuidadosa e testes. A diferença é usar código gerado para cenários de falha, análise de dados e testes de integração que antes não cabiam no orçamento de tempo.

• Qual é o limite prático dessa abordagem? O limite é a capacidade de verificar os resultados do código descartável. Se você gera 800 linhas de teste e não lê a conclusão, o exercício não reduz risco nenhum.

• Como o Crazystack Typescript entra nessa discussão? Ele serve como exemplo de stack e comunidade onde a prática de revisar contratos, testar hipóteses e usar agentes aparece no dia a dia. Estudos de caso comunitários ajudam a mostrar como o fluxo funciona fora do vídeo original.

Como aplicar isso no seu fluxo de trabalho

Comece classificando o código do seu projeto por camada de dano: o que pode falhar sem consequência, o que exige revisão e o que é crítico. Essa classificação define quanto tempo humano cada parte merece e onde vale investir em código descartável.

1. Liste os módulos do projeto e marque cada um como camada A, B, C ou D.
2. Para as camadas C e D, defina o que precisa de leitura linha a linha, como contratos, assinaturas e caminhos de falha.
3. Crie espaço para código descartável que teste hipóteses, compare implementações e instrumente o sistema antes do merge.
4. Use agentes para gerar esses experimentos e revise a conclusão deles, não cada linha do código de teste.

Quem trabalha com ERP financeiro ou sistemas de saúde costuma subestimar o valor de experimentos descartáveis. Um teste que simula uma falha rara vale mais que dez funções lidas sem contexto, porque ataca diretamente o risco de uma decisão errada entrar em produção.

A ideia de gerar mais código também aparece em comunidades de aprendizado, como o Bootcamp do Dev Doido, onde iniciantes treinam mais pela prática de gerar, testar e refatorar do que pela leitura passiva de cada linha. O mesmo raciocínio vale para quem já trabalha com sistemas críticos.

A conversa completa está no canal do Gustavo Dev Doido e em discussões ligadas ao ecossistema TypeScript. O importante é entender que a mudança não é sobre revisar menos, e sim sobre produzir mais código com finalidades diferentes.

Transforme seus vídeos em artigos com Skala Blog

A mesma lógica de gerar código descartável para verificar o que importa vale para conteúdo: você pode ter uma ideia valiosa gravada em vídeo e nunca transformá-la em texto. Todo esse material fica parado, sem alcançar quem prefere ler ou pesquisar.

Se você produz vídeos com conhecimento técnico, entrevistas ou opiniões que merecem circular, o Skala Blog permite colar a URL de um vídeo do YouTube, transcrever o conteúdo e gerar um artigo estruturado. O processo começa no vídeo, passa pela transcrição e termina em texto pronto para revisão.

Source video