Ferramentas melhores de programação tornam viáveis projetos mais ambiciosos

O texto de Dan Luu parte de uma frase de Michael Malis, autor do pgrust: "we should be more ambitious with the software we build". O pgrust é uma reescrita de Postgres em Rust. Luu diz que o ceticismo é compreensível, porque há muito projeto gerado por IA de baixa qualidade. Mas ele aponta que Malis testa o suficiente para achar bugs reais no Postgres, como um bug numérico em operações SP-GiST, um bug de cache de formato no JSONPath, um bug no pgcrypto, falhas de segurança de memória no carregador de dicionários e um overflow em money. A pitch principal do pgrust, segundo ele, é performance, e otimizações podem acabar em Postgres ou Clickhouse mesmo que o projeto não vingue.

Luu relata os próprios experimentos, feitos sem rigor de benchmark (ele mesmo avisa que escreveu rápido): uma engine de regex ajustável por workload, um fork do ripgrep que usa o compilador nativo dessa engine, e uma ferramenta que acelerou builds de Rust, com ganho grande em builds frios e moderado nos quentes. Ele diz que isso levou poucas horas, contra um ano ou mais sem as ferramentas atuais. Também cita o zstd implementado por GPT-6 Astra, com mais de 99% dos testes registrados passando, a um custo em torno de US$ 1. Ele ressalva que "software is solved" não é o que observa: modelos melhores o levam a problemas mais ambiciosos, onde ainda travam. O apêndice traz a contra-posição de Yossi Kreinin: para a maioria, ambição moderada evita fracasso, já que faltam critérios claros de pass/fail e é difícil raciocinar sobre caixas-pretas.

O CEVIU já vinha registrando essa tendência. Em 24 de agosto de 2026, noticiou "Otimização de Software: A Nova Realidade para Desenvolvedores", sobre performance deixando de exigir especialistas. Em 22 de setembro de 2026, em "IA impulsiona projetos open source, viabilizando otimizações complexas", falou de ganhos de performance em projetos open source. Em 6 de outubro de 2026, "Desenvolvimento Acessível Impulsiona Ferramentas de Nicho e Narrativas de Projeto" tratava do custo menor de desenvolver. Agora o argumento vira tese explícita, com exemplos concretos de reescrita de banco de dados, regex e compilador.

Para quem desenvolve, a leitura é que o modelo de custo mental de "isso é caro demais para fazer" pode estar defasado. Vale reavaliar o que você descartou. Mas o contraponto de Kreinin pesa: sem testes e benchmarks sérios, a ambição vira código sobreajustado e difícil de manter.