O código ficou mais barato

• Com a disseminação das ferramentas de codificação com IA, o custo de escrever código caiu drasticamente, mas a realidade é que o custo de entender o código gerado aumentou ainda mais
• LLMs são não determinísticos, não preservam o código-fonte original e seu escopo de saída se amplia para o software em geral, portanto não podem ser tratados como equivalentes à saída de um compilador
• Como LLMs geram código muito mais rápido do que a velocidade com que humanos conseguem entendê-lo, recomenda-se o uso incremental para evitar grandes mudanças que ninguém compreende
• O principal risco quando o código fica barato é a complexidade, que aumenta pelo menos geometricamente conforme a escala do sistema, enquanto LLMs são codificadores prolíficos sem medo da complexidade
• Como solução, propõe-se o engenheiro subtrativo que remove e simplifica em vez de adicionar código, enfatizando a preservação da arte da programação de computadores

---

A era em que o código ficou barato

• No último ano, a IA passou a gerar em alta velocidade grandes volumes de código de qualidade razoavelmente boa, reduzindo muito o custo de gerar código
• Em resposta à afirmação de que “o problema nunca foi codificar”, o texto rebate que codificar também era parte do problema, e que essa parte foi bastante reduzida pelas ferramentas de codificação com IA
• Para desenvolvedores que antes se orgulhavam da própria habilidade de programar, levanta-se a questão do que significa a queda da importância da codificação pura

O aumento do custo de entendimento (Understanding is Expensive(er))

• Quando o código deixa de sair com esforço das mãos do programador e passa a ser gerado em massa, simplesmente não existe entendimento sobre esse código
  • Se o entendimento for necessário, ele precisa ser obtido lendo o código depois que ele foi escrito
  • Pelo senso comum, ler código escrito por outra pessoa é mais difícil do que escrever o próprio código
• A defesa pró-IA de que “também não entendemos a saída do compilador” é classificada como erro de categoria
  • Compiladores são determinísticos, mas LLMs são não determinísticos por projeto
  • O fluxo de trabalho com compiladores preserva o código-fonte original, mas o fluxo com LLMs em geral não preserva
  • A saída do compilador se limita ao domínio estreito do código de máquina, enquanto a saída de LLMs não se limita a software generalizado
• Na maioria dos casos, especialmente em software de missão crítica, o desenvolvedor ainda precisa entender o código subjacente, mesmo que ele tenha sido gerado por um LLM
• LLMs conseguem produzir código numa velocidade que ninguém consegue acompanhar, criando o risco de ultrapassar a velocidade de entendimento
  • Por isso, recomenda-se o uso incremental em vez de gerar de uma vez uma enorme lista de mudanças
  • Pode ser adequado para refatorações mecânicas, mas é extremamente perigoso ao introduzir nova semântica no codebase

A armadilha do aprendiz de feiticeiro (The Sorcerer's Apprentice Trap)

• A cena “The Sorcerer's Apprentice” do filme da Disney Fantasia é apresentada como uma boa metáfora para a era da IA
  • Quando o aprendiz lança um feitiço na vassoura para aliviar o trabalho pesado da limpeza, a vassoura passa a limpar de forma cada vez mais frenética até a situação sair do controle
  • No fim, o feiticeiro reaparece, retoma o controle da situação e repreende a tolice do aprendiz enquanto restaura a ordem
• A lição dessa metáfora é que é preciso ser o feiticeiro, não o aprendiz, e o feiticeiro precisa entender o código

Complexidade continua sendo ruim (Complexity: Still Bad)

• Humanos não entendem bem curvas geométricas e exponenciais, e acabam tratando coisas como juros compostos quase como se fossem contos de fadas
• O principal risco quando o código fica barato é a complexidade, que, segundo o texto (sem prova), cresce pelo menos geometricamente e muitas vezes exponencialmente com a escala do sistema
• Mesmo antes dos LLMs, já existiam codificadores prolíficos
  • Um codificador prolífico sem medo da complexidade continua empilhando código sobre problemas já existentes, levando o sistema a um estado de estagnação impossível de consertar, em que qualquer mudança cria tantos bugs quanto corrige
• LLMs são perigosos porque, além de prolíficos, também não têm medo da complexidade

O engenheiro subtrativo e restritivo (The Subtractive, Constraining Engineer)

• Para lidar com os riscos do código gerado por LLMs, propõe-se o engenheiro subtrativo e restritivo
  • Esse engenheiro sabe dizer “não”, revisa cuidadosamente a saída do LLM, propõe simplificações e mantém o controle com firmeza
  • Sente orgulho não do código que criou, mas do código (e das camadas) que removeu do sistema ou impediu de entrar
  • Essa postura se aproxima mais da de um escultor do que da de um construtor
• A postura de construtor ainda continua válida no nível de projeto de sistema
  • Um bom engenheiro precisa saber combinar componentes de forma eficaz para montar sistemas
  • Mas mesmo nesse nível, o pensamento subtrativo é útil para remover componentes e fronteiras de sistema desnecessários, simplificando implantação e interação
• O engenheiro subtrativo é um tipo diferente da maioria dos programadores do passado e combina com a atitude de saber dizer “não” e preferir lapidar sistemas existentes em vez de fazer reescritas heroicas
• Essa abordagem reconhece a dupla realidade de que o código ficou barato e a complexidade continua sendo o predador de topo, oferecendo uma forma produtiva de preservar a arte da programação de computadores

[GN⁺]

Opiniões no Lobste.rs

• O texto de 1985 de Peter Naur, Programming as Theory Building, parece valer mais algumas releituras hoje em dia

• Acho que a frase “LLMs não conseguem temer a complexidade” chega perto de ser um exagero
  O padrão de falha em si existe mesmo. Se você dá instruções amplas, o LLM adiciona camadas, cria abstrações e com frequência produz código excessivo para o problema. Mas esse comportamento é fácil de observar, fácil de revisar e, surpreendentemente, também fácil de redirecionar. Dá para ajustar o estilo de software desejado com arquivos AGENTS/CLAUDE.md
  Basta exigir a menor mudança possível, perguntar o que pode ser removido e questionar se aquela abstração realmente se paga. Também dá para perguntar sobre invariantes, pontos de acoplamento e carga cognitiva, e pedir uma segunda passada removendo espertezas; em geral ele acompanha essa pressão. Se isso estiver no prompt, dá até para fazer com que evite isso desde o início
  O risco não está em o LLM jamais conseguir respeitar a complexidade, mas em ele produzir de bom grado a forma de código que o processo ao redor recompensa. Equipes que recompensam volume recebem volume; equipes que recompensam simplicidade em geral também conseguem receber isso
  Os modelos atuais já são melhores do que a maioria dos humanos e vão melhorar ainda mais. Se o código não estiver bom, é preciso pressionar os laboratórios de IA com feedback. Por exemplo, acho a linha GPT péssima para escrever boa documentação

  • É verdade e não é. O ponto central parece ter menos a ver com capacidade e mais com forma de treinamento e objetivo. O que está em alta agora é esse papo de “vibe codei o projeto inteiro”, e os LLMs são muito mais fracos para modificar código existente do que para criar algo do zero. Provavelmente isso tem a ver com o modo de treinamento, e também parece haver um viés estatístico. Há muito mais código de codebases grandes e complexas do que de projetos pequenos e simples, então isso provavelmente teve um peso maior no treinamento
    Por isso, talvez “impossível” não seja a melhor palavra, mas acho que existem vários vieses que, por padrão, puxam para a complexidade
    Também existe um viés em fazer alguma coisa em vez de não fazer nada. Bons programadores usam muito mais contexto do que um gerente que só joga um pedido, e também propõem alternativas. Talvez os LLMs consigam fazer isso, mas os atuais não são bons em formular as perguntas certas, mesmo quando há código para “perguntar durante o planejamento” ou detectar repetição. Também é bem possível que esse tipo de dado de treinamento não seja comum
    Em certo sentido, prompt engineering chega perto de ser um hack horrível em volta desse conjunto de problemas
  • Não sei se concordo totalmente com essa formulação, mas com certeza há algo aí. Por um lado, já vi essa “complexidade comum” de gerar por padrão um projeto CMake gigante quando um Makefile de alvo único já bastaria
    Por outro lado, já recebi respostas do tipo “não recomendo isso para um projeto de um mês. Que tal commitar assim e deixar como demo?”, e depois tive que convencer e tranquilizar o LLM. Isso mesmo sabendo que ambos os caminhos terminariam em menos de uma hora. Mas se você diz “tá, tenta algo completamente novo; descobre o caminho”, ele tenta, então nesse sentido também dá para dizer que não tem medo
  • Uma discussão cheia de nuances sobre “vibe coding” no Lobsters? Acho que o inferno congelou /s
    Brincadeiras à parte, concordo. Bate com a minha experiência também

• Em geral, não concordo muito com a ideia de que “o custo de entender código ficou mais caro”
  Se for código de LLM gerado sem pensar, isso pode até ser verdade, mas, com orientação adequada, o LLM também consegue produzir código fácil de ler e com camadas bem separadas. Claro que, nesse caso, a maior parte das escolhas de arquitetura é feita por humanos, e acho que tem que ser assim mesmo
  Como contraponto, senti que LLMs são muito bons para entender código escrito por alguém que não é familiar para você. Dá para pedir ao Claude Code uma análise profunda de um trecho específico e que ele gere um documento em Markdown explicando cada parte, além de sugerir até a ordem em que eu deveria revisar ou começar a entender aquilo
  Isso tem muito valor mesmo

  • Minha experiência com LLMs em código desconhecido no geral foi boa, mas às vezes eles inventam criativamente e mentem em partes que fogem das convenções. O problema é que, justamente por o código ser desconhecido, fica difícil distinguir uma coisa da outra

• “Humanos em geral não entendem bem curvas exponenciais. É por isso que acreditam em contos de fadas como juros compostos”: isso quer dizer que juros compostos são um conto de fadas? Eu entendi alguma coisa errada?