LLMs

Redigitar o código da IA contra a dívida cognitiva

Um engenheiro passou a digitar à mão o código gerado por LLM em vez de copiar e colar. Os bugs em produção caíram.

O que aconteceu

Um engenheiro que trabalha em uma plataforma de automação com IA começou a encontrar bugs depois de publicar código gerado por LLM. A solução que adotou foi pouco tecnológica: em vez de copiar e colar, passou a redigitar o código à mão.

No processo, foram aparecendo peculiaridades de formatação, importações faltando e erros sutis de lógica que o modelo havia introduzido — e que sobreviveriam a uma leitura rápida. O resultado relatado foi queda nos incidentes após a publicação e atualizações posteriores mais rápidas, porque o código no repositório era código que alguém de fato tinha entendido.

Por que isso importa para quem constrói

  • Detecção precoce de bug — digitar obriga a ler e compreender cada linha, o que pega erro que ferramenta automatizada deixa passar.
  • Menos dívida cognitiva — as premissas escondidas no código gerado por máquina vêm à tona, e a manutenção futura fica mais barata.
  • Integração mais tranquila de novos membros — código escrito por humano comunica intenção com mais clareza para quem chega depois.
  • Ferramental funciona melhor — código produzido conscientemente se encaixa melhor em linter, verificador de tipos e esteira de CI.
  • Mitigação de risco em produção — a revisão manual evita que uma falha de automação vire uma cascata de indisponibilidade.

A leitura da Tyna

O termo dívida cognitiva merece destaque, porque nomeia algo que times sentem antes de conseguir descrever.

Dívida técnica é código ruim que funciona. Dívida cognitiva é código que funciona e ninguém entende — e é uma dívida mais perigosa, porque não aparece em métrica nenhuma. O repositório passa nos testes, a cobertura está boa, o linter está limpo. O problema só se revela no dia em que algo quebra e a pessoa responsável descobre que não sabe explicar por que aquela função existe.

Geração por LLM acelera a criação dessa dívida de um jeito que nenhuma prática anterior conseguiu. Antes, escrever mil linhas por dia exigia entender mil linhas por dia. Esse acoplamento se rompeu.

A recomendação de redigitar tudo, porém, não escala — e o próprio relato admite isso ao sugerir a prática para módulos críticos. O princípio útil por trás dela é mais simples de aplicar: ninguém publica código que não sabe explicar em voz alta. Redigitar é uma das formas de chegar lá, não a única. Revisão em par sobre o código gerado, ou a obrigação de escrever o teste à mão antes de aceitar a implementação, produzem o mesmo efeito com menos atrito.

Para quem tem agente publicando código, o ponto vira governança: a barreira não é o LLM escrever, é quem assina embaixo.

Perguntas frequentes

P: Redigitar compensa em relação a rodar linter automático?

R: Os minutos a mais no início costumam se pagar no tempo de depuração que você não gasta depois. Não é substituto de linter — pega uma classe diferente de erro, a de lógica e de premissa.

P: Como encaixo isso na esteira de CI/CD?

R: Trate a versão redigitada como a fonte de verdade e rode as ferramentas contra ela.

P: É viável em base de código grande?

R: Como prática geral, não. A recomendação é aplicar em módulos críticos e adotar uma abordagem híbrida no resto.

Fonte original: ankursethi.com

Versão em inglês: Automations Cookbook

Próximo passo

Quer aplicar isso na sua empresa, com governança?

Agendar conversa