Gerar código rápido não resolve engenharia de software de produção

A tese: código não está resolvido

O engenheiro Alex Ewerlöf contesta a narrativa de que "programar está resolvido" e que a engenharia se resume agora a "taste". Ele se declara adepto do uso de IA, mas argumenta que gerar código é apenas parte do custo real: manutenção, confiabilidade, segurança e escalabilidade (os requisitos não funcionais) dominam o gasto em produção. Em sua experiência, até os requisitos funcionais continuam sem solução, e há um efeito Dunning-Kruger: quanto menos a pessoa entende a tarefa, mais confia na saída do modelo.

Quem pode dispensar a leitura do código

Ewerlöf admite quatro contextos em que não é preciso ler o código gerado: software pessoal, provas de conceito, automações descartáveis e a chamada "IA weaponizada", que assume deliberadamente o risco. O ponto comum dos três primeiros é a alta tolerância a falhas. Já o software que justifica contratar engenheiros costuma ter baixa tolerância a risco - saúde, finanças, aviação, defesa -, onde erro custa dinheiro, vidas ou consequências legais, e exige prestação de contas. IA não pode ser responsabilizada: não sofre punição, multa ou prisão, e não é possível ser responsável pelo que não se controla.

Por que LLMs tropeçam em código

Código é lógica, e LLMs são estocásticos e probabilísticos. O sucesso deles em programar vem de um ciclo de feedback em que erros de compilador e testes são realimentados até os erros desaparecerem ou serem escondidos. A precisão cai conforme o contexto cresce, e as melhorias vêm de embrulhar o modelo em código determinístico (harness), não de lógica intrínseca. Ewerlöf nota retornos decrescentes: modelos mais caros nem sempre são mais produtivos na proporção do aumento de preço.

Fallacies e exemplos concretos

Ele rebate frases comuns: "spec completa antecipada" (software evolui em iterações), "inglês é a nova linguagem de programação" (linguagem natural é vaga e conflitante; é para isso que existem compiladores), "movo muito mais rápido" (não confundir movimento com progresso; medir níveis de serviço, não SLOC ou contagem de PRs), "taste é leverage" (todos têm taste; a IA baixou o piso e elevou o que é remunerável) e "agente é o novo compilador". Sobre "programar está resolvido, engenharia não": o código continua sendo a fonte da verdade sobre o que acontece e como funciona.

Ele cita falhas do Claude Code - que retorna o menu de ajuda do Bun, se autodeleta silenciosamente após instalação e cobra usage extra com capacidade disponível - lembrando que a Anthropic controla modelo, harness, prompt e runtime. Um exemplo próprio: um agente levou 12 minutos e 72 passos para atualizar 5 dependências npm de patch, que ele faria em menos de um minuto. Também alerta para o "truque velho" de rodar múltiplos agentes em paralelo para que o volume torne a revisão inviável.

Propriedade, gestão e economia

A responsabilidade tem três pilares - conhecimento, mandato e accountability - e enviar código sem entender o quebra a propriedade. Ele aponta o CEO do Shopify, Tobi Lütke, que antes pressionou funcionários a usar IA e depois cunhou "slop grenades" para descrever o resultado. Executivos que medem produtividade por consumo de tokens são alvo de crítica direta. Quanto ao "AI Dunning-Kruger" de gestores que delegam a agentes: o executivo não pode ser responsável pelo que não entende.

Na economia do software, mesmo se o código de IA tivesse bons NFR, ele discute o modelo de precificação: fornecedores cobraram "preços humanos" por saída de IA, e a lacuna deve se fechar. SaaS tende a vender SLAs, pois quando o produto gerado por IA quebra, empresas preferem acionar o fornecedor. Só "lento é rápido" se justifica para software crítico.

Conclusão: barreira elevada, não fim da profissão

Ewerlöf rejeita enquadramentos de "crise de identidade" e alerta para o "AI overdose", incluindo a perda de leitura de textos longos e da habilidade de programar. Para ele, estamos a pelo menos duas revoluções da dispensa de ler código: IA que aprende em tempo real e IA que raciocina abstratamente. A IA é um "bar raiser": quem produz qualidade igual ou inferior à dela precisa se especializar. Seu conselho é experimentar em primeira mão, manter um projeto sem IA para preservar as habilidades, e não confundir a velocidade de geração com engenharia de produção.