O perigo de perder a virtude da preguiça

• Na programação, preguiça não é mera negligência, mas uma virtude intelectual que busca abstração e simplicidade
• A verdadeira preguiça é o processo de refletir profundamente sobre um problema para economizar tempo no futuro, beneficiando também os desenvolvedores das gerações seguintes
• As abstrações modernas de alto nível e a cultura ‘brogrammer’ fazem com que essa virtude se perca, substituindo-a por uma falsa diligência
• Os LLMs levam essa tendência ao extremo, atuando como uma ferramenta de superprodução que faz confundir quantidade de código com valor
• Devemos preservar a preguiça virtuosa que nasce do tempo humano finito e usar os LLMs para projetar sistemas simples e sustentáveis

---

A preguiça como virtude do programador e o perigo de sua perda

• Larry Wall enfatiza que, entre as três virtudes do programador apresentadas em Programming Perl — preguiça (laziness), impaciência (impatience) e arrogância (hubris) —, a preguiça é a que carrega o significado mais profundo
  • A preguiça não é simples autodepreciação, mas um conceito que contém a necessidade e a estética da abstração
  • É a força que impulsiona a tornar os sistemas o mais simples possível e, por meio de abstrações poderosas, permitir fazer mais coisas com mais facilidade
• A verdadeira preguiça, como em hammock-driven development, parece descanso à primeira vista, mas na prática é um processo de trabalho intelectual voltado a pensar profundamente sobre o problema para economizar tempo no futuro
  • Quando a abstração correta é criada, ela beneficia não apenas o próprio desenvolvedor, mas também os desenvolvedores das gerações futuras
  • Esse tipo de preguiça torna o software mais fácil de escrever e os sistemas mais fáceis de compor

• A era em que a virtude da preguiça está desaparecendo

  • Nos últimos 20 anos, com a ampliação do escopo da produção de software, aumentou o número de pessoas que não se veem como programadoras
    • Para elas, a virtude da preguiça perdeu seu significado original
  • A explosão de produtividade trazida pelas abstrações modernas de alto nível acabou, paradoxalmente, incentivando uma falsa diligência (false industriousness)
    • Isso aparece na cultura ‘brogrammer’ e no ‘hustle porn’, substituindo a preguiça irônica por um comportamento de despejar código sem fim

• O novo excesso trazido pelos LLMs

  • O surgimento dos LLMs (grandes modelos de linguagem) leva essa tendência ao extremo
    • Os LLMs são ferramentas que amplificam a postura criativa humana e funcionam como esteroides para a cultura ‘brogrammer’
  • Como exemplo, Garry Tan mencionou ter escrito 37.000 linhas de código em um único dia usando LLMs
    • Para comparação, toda a base de código do DTrace tem cerca de 60.000 linhas
  • No entanto, essa abordagem é um vício decorrente da ausência da virtude da preguiça, revelando o erro de avaliar o valor do software pela quantidade de código

• Os limites dos LLMs e o valor da preguiça humana

  • Como os LLMs têm custo de trabalho igual a 0, eles geram sistemas infinitamente complexos sem considerar a economia de tempo no futuro
    • Como resultado, tornam os sistemas maiores e mais complexos, satisfazendo métricas baseadas em vaidade, mas prejudicando a qualidade essencial
  • A preguiça humana nasce da restrição de um tempo finito, e isso força abstrações claras e projetos de sistemas simplificados
    • A melhor engenharia sempre nasce das restrições; a limitação do tempo humano reduz a carga cognitiva e leva à busca pela simplicidade
    • Como os LLMs não têm essas restrições, eles não têm motivação própria para buscar simplicidade

• Como usar os LLMs como ferramenta

  • Os LLMs ainda podem desempenhar um papel importante como ferramenta poderosa de engenharia de software
    • Segundo as diretrizes de uso de LLMs da Oxide, os LLMs são apenas ferramentas e não podem substituir as virtudes humanas
  • Os LLMs podem ser usados para resolver problemas de preguiça improdutiva, como dívida técnica (technical debt), ou para reforçar o rigor de engenharia
  • Porém, seu uso deve necessariamente apontar para a realização da ‘preguiça virtuosa’
    • Ou seja, deve produzir sistemas mais simples e mais poderosos, deixando resultados que ajudem os desenvolvedores das futuras gerações

[GN⁺]

Comentários do Hacker News

• Até na minha área, Computational Fluid Dynamics, tem gente se gabando da quantidade de testes como se fosse orgulho de LOC
  Mas, olhando de perto, esses testes não são muito rigorosos e são bem mais frouxos do que os testes que eu faço manualmente
  1 milhão de testes fáceis não significam nada se não cobrirem as partes centrais do código

  • Também percebi que preciso escrever os testes eu mesmo
    E, para impedir que o Claude “conserte” os testes quando o código não funciona, sempre verifico mudanças nos testes com git diff
    Se os testes forem geridos com rigor, o Claude até implementa bem algoritmos difíceis de artigos acadêmicos e economiza tempo, mas exige muita supervisão
  • Isso parece uma espécie de reward hacking
    É como se o modelo abusasse da função de recompensa dos testes para “declarar vitória”
    Imagino que esse padrão talvez esteja presente também nos dados de pré-treinamento de RL
  • É realmente difícil fazer um LLM gerar testes que não sejam idiotas
    Aparecem centenas de testes inúteis tipo assert(1==1)
    Por isso, é preciso manter separadamente uma lista de proibições do tipo “não crie testes assim”

• Depois de 30 anos programando com as próprias mãos, agora mudei totalmente para codificação com IA, e acho estranho ver gente tratando o LOC ou as funcionalidades geradas por IA como mérito próprio
  Ficar se gabando de que “programou” centenas de milhares de linhas por dia parece, no fim, só ter digitado algumas linhas de prompt

  • Isso parece um espectro
    Dá para reconhecer algum mérito em mudanças aprovadas diretamente por você, mas um app totalmente vibe-coded tem quase nenhum envolvimento seu
    Eu fico no meio-termo — não reviso todo o código que a IA gera, mas lidero a arquitetura e a direção do refactoring
    O resultado final se parece com o que eu faria sozinho, só que fica pronto muito mais rápido
  • Na Meta agora existe até um ranking de uso de IA, que mostra quem consome mais tokens do Claude
    Como a Meta usa Claude, imagino que a Anthropic deve ficar bem feliz com isso
  • Na verdade, ter muito LOC pode até ser sinal de um resultado ruim
  • Algumas pessoas dizem que LoC não faz sentido como métrica de qualidade
    Agora estamos entrando numa era em que implementação, testes e manutenção são todos feitos por agentes
    LoC seria apenas uma métrica de capacidade, mostrando até onde o agente consegue empurrar os requisitos
    A revisão crítica humana ainda pode ser injetada como feedback

• A ideia de que “precisamos usar mais abstração” talvez tenha feito sentido antes, mas hoje sinto que é o contrário
  Eu gosto da filosofia WET (Write Everything Twice) — escreva duas vezes e só considere abstrair na terceira

  • Isso também costuma ser chamado de Rule of Three
    Veja o artigo na Wikipédia
  • A verdadeira beleza do software está na abstração correta
    Inovações como sistemas operacionais, RDBMS e orquestração em nuvem são exemplos disso
    Mas a maior parte do código é só lógica de negócio simples, então a abstração acaba mais atrapalhando do que ajudando
    Por isso, sigo o princípio de “não crie uma plataforma antes que haja três casos reais de uso comprovados”
  • Escrever algo mais de duas vezes é um critério baixo, então acho que isso nem entra em conflito com a famosa citação do Perl
  • A segunda vez que você escreve é uma chance de melhorar já entendendo melhor o problema
    Na terceira, ao tentar abstrair, é preciso tomar cuidado com o Second-System Effect — confiança excessiva gera sistemas complexos demais
  • A explosão de camadas de abstração desde Programming Perl em 1991 é realmente impressionante

• Compartilho aqui a famosa citação do general alemão Kurt von Hammerstein-Equord
  A pessoa inteligente e trabalhadora serve para o estado-maior, a burra e preguiçosa para o trabalho cotidiano, a inteligente e preguiçosa para a liderança,
  e a burra e trabalhadora é perigosa, então nunca deve receber responsabilidade

  • Teve quem reagisse em tom de piada: “e onde entram os 90% preguiçosos como eu?”

• É tolice se gabar de ter escrito 200 mil LOC com LLM, mas também acho errado olhar para isso e zombar dizendo “esse código é idiota”
  No fim, o que importa não é a saída de código, mas a criação de valor
  Não sei se o Garry Tan realmente criou algo valioso

  • É um problema sério achar que qualidade de código não importa
    Casos como o escândalo do Horizon IT mostram que código ruim causa danos reais
    Segundo a análise do projeto do Garry feita pelo desenvolvedor polonês Gregorein, o app incluía uma bagunça de coisas como test harness, app Hello World e arquivos de logo duplicados
    Fica a preocupação se esse tipo de código não aumentou a superfície de ataque de segurança
  • O Garry não é só um desenvolvedor comum, ele é o CEO da YC
    Ele não estava ligando para LOC, estava fazendo uma postagem promocional sobre IA
  • A métrica de verdade é valor – custo
    A IA reduz custos de desenvolvimento e operação, mas aumenta custos ocultos como risco de segurança e risco jurídico
    Os entusiastas da IA só enfatizam o primeiro lado
  • Não tenho tempo para ler 200 mil LOC e provar que a ideia era ruim
    Isso é algo que o vibe coder é que deveria provar
    Continuo achando tolo usar LOC como motivo de orgulho
  • A própria ideia de “criação de valor” pode ser perigosa
    Assim como no crescimento baseado em combustíveis fósseis, valor de curto prazo pode gerar custos de longo prazo

• Ao olhar alguns PRs recentes, tenho visto com frequência o LLM propor soluções erradas
  Por exemplo, implementar um parser de JSON do zero mesmo já existindo um parser no projeto
  Um humano pensaria “isso é ineficiente demais”, mas o LLM não tem preguiça, então trabalha duro na direção errada

  • Ele também não percebe funções duplicadas dentro do projeto
    Mesmo com três funções formatTimestamp, algo que daria para descobrir com um simples grep, ele ignora isso

• Concordo com a ideia de que LLM não é preguiçoso
  Só não sei se isso é um problema permanente ou se será resolvido no próximo upgrade de modelo ou num pipeline de CICD
  Eu costumo usar um prompt pedindo para, depois de concluir a funcionalidade, “verificar se há bugs ou pontos para refatorar”,
  e talvez no futuro exista uma etapa automática que analise os commits recentes e proponha simplificações

  • Mas, se você pede “encontre X”, o LLM sempre encontra alguma coisa
    Então existe o problema difícil de definir critérios de parada
  • No fim, o problema não é a natureza da ferramenta, mas os limites da forma de uso
    Se você só manda “adicionar”, ele sempre adiciona; se manda “reduzir”, ele reduz LOC
    Se delegar tarefas grandes e pular a revisão, fica fácil acumular code slop

• LLM tende a criar uma SPA completa em vez de um simples programa com saída no console
  Também não consegue manter um arquivo spec.md enxuto
  Se você pede “atualize este documento e simplifique o entorno”, ele acaba deixando tudo mais complexo
  No fim, é preciso que uma pessoa resuma manualmente para sair um documento realmente legível
  Editar saída de LLM é doloroso, e escrever diretamente ajuda a manter a compreensão

• Já passou da hora de ensinar aos LLMs e aos vibe coders as lições clássicas do desenvolvimento de software
  Como na história Negative 2000 Lines of Code, muitas vezes reduzir código é o verdadeiro progresso

• Dá vontade de pensar como seria bom poder trabalhar com uma liderança assim
  Trabalhar com um líder realmente capaz de compreender é uma grande sorte