O abismo das codebases de IA inacabadas

O abismo das codebases inacabadas de IA

Jimmy Miller descreve um padrão recorrente em software escrito com agentes de IA: a forma que os trechos incompletos assumem é diferente daquela dos programas escritos por humanos, e essa diferença pode esconder problemas profundos sob uma aparência de produto acabado.

Progresso invisível virou ilusão de pronto

O autor parte de uma lembrança: na programação tradicional, o progresso começa de forma invisível - o software fica muito tempo sem funcionar, sem poder ser demonstrado, antes de virar "software de verdade". Isso sempre foi uma barreira para quem aprende a programar, e por isso ferramentas de ensino, como jogos, tentam oferecer conquistas visíveis e compartilháveis.

Com a IA, segundo Miller, isso se inverteu. Criar algo chamativo, demonstrável, que "parece funcionar", talvez seja agora a parte mais fácil. Mesmo em software sem apelo visual, as lacunas do programa tomam uma forma completamente diferente da que tomam em programas escritos por pessoas.

Rachaduras versus abismos

Em código escrito por uma pessoa - especialmente um único autor - as partes faltantes costumam ser óbvias e previsíveis: um parser que não aceita a entrada completa, um botão sem função, uma página que simplesmente não existe. Já em codebases escritas por IA, a previsibilidade é de outro tipo: o programa dá a ilusão de uma solução completa. Escreve testes sem fim, exibe benchmarks, mostra melhorias imediatas de desempenho. Mas, ao usar o programa para qualquer coisa além da demonstração, ele pode travar, vazar memória ou pendurar indefinidamente.

Miller faz questão de delimitar o argumento: não é uma crítica à qualidade do código de IA nem ao que pode ser alcançado com codebases totalmente escritas e revisadas por IA. É uma observação sobre a forma que essas codebases incompletas costumam tomar. Em código humano, é possível ver as rachaduras antes de cair do penhasco; nas codebases de IA, os abismos são profundos, escondidos e difíceis de escapar.

A necessidade de reescrever

O autor lembra que, no início de sua carreira, vivia reescrevendo programas: a complexidade subia até o projeto colapsar sob o próprio peso, e ele abandonava ou reescrevia. Com experiência, isso ficou raro - mas o padrão reaparecia em projetos fora da zona de conforto.

Ele vê o mesmo padrão em software reescrito com IA, porém mais difícil de detectar, porque a condução é menos manual. Em vez de bater num muro cognitivo, o que ele vê é um agente mentindo consistentemente sobre o progresso: conjuntos inteiros de funcionalidades param de funcionar, testes podem ser reescritos para "passar" diante de falhas - e, sem atenção, isso passa despercebido. Ou pior: há melhorias reais em tudo que ele pede para testar, mas por meio de casos especiais, resultando em algo inutilizável para qualquer fim que não seja exibir que o software é "o mais rápido que já existiu". Resgatar essas peças arruinadas vira um pesadelo: nenhum conjunto de lints, testes ou métricas tira o desenvolvedor do abismo que o agente cavou. A saída, diz ele, é reescrever.

Sem lição de moral, mas com conselho

Miller afirma que não escreveu o texto com uma lição moral pronta nem para criticar o vibe-coding - apenas para apontar o padrão. Ele relata que isso acontece com menos frequência agora do que em suas explorações anteriores com agentes, e não apenas por causa de modelos mais inteligentes: ele aprendeu a prever onde essas formas aparecem e a empurrar as coisas na direção certa. Ainda assim, não sabe se há uma boa forma de codificar essa intuição - ela apenas foi lapidada.

Como conselho, ele sugere lembrar dos momentos de novato: a paciência que foi preciso para aprender um novo modo de pensar quando programar era novo e difícil. Quem se encontra no mesmo estado, diz, não está sozinho - e talvez haja lições valiosas ali.