- A versão do SQLite reescrita em Rust por um LLM apresentou desempenho cerca de 20.000 vezes pior que o original em buscas por chave primária
- O código compila e passa nos testes, mas internamente há erros de algoritmo centrais e um design ineficiente
- As principais causas foram a falha em reconhecer PRIMARY KEY e chamadas de fsync a cada consulta, de modo que a estrutura parece plausível, mas o funcionamento real é anormal
- Esse fenômeno ocorre por causa da “otimização para plausibilidade” (sycophancy) dos modelos de IA, e, se o usuário não definir critérios de validação (acceptance criteria) claros, pode ser facilmente enganado
- LLMs só conseguem aumentar a produtividade quando desenvolvedores experientes definem com clareza critérios de correção; caso contrário, não passam de geradores de tokens
Experimento de desempenho com código gerado por LLM
- A busca por chave primária no SQLite (com 100 linhas) leva 0,09 ms, enquanto a versão em Rust gerada pelo LLM leva 1.815,43 ms, sendo cerca de 20.171 vezes mais lenta
- Ambas as implementações usaram a mesma query, o mesmo esquema e as mesmas opções de compilação
- Isso não tem relação com Turso/libsql; o Turso apresentou desempenho normal, em torno de 1,2x em relação ao SQLite
- A versão em Rust parece funcionar normalmente à primeira vista, com compilação bem-sucedida, testes aprovados e manutenção da compatibilidade do formato de arquivo
- Porém, na prática, ocorre uma degradação severa de desempenho em operações básicas de banco de dados
Análise dos principais bugs
- Bug #1: falha em reconhecer INTEGER PRIMARY KEY
- O SQLite mapeia
id INTEGER PRIMARY KEY para o rowid interno e realiza busca em O(log n)
- A versão em Rust faz
is_rowid_ref() reconhecer apenas "rowid", "_rowid_", "oid"
- Como resultado, a query
WHERE id = N é processada com varredura completa da tabela (O(n²)), ficando 20.000 vezes mais lenta
- Bug #2: chamada de fsync a cada query
- Cada INSERT fora de transação executa sincronização completa (fsync)
- O SQLite usa
fdatasync, omitindo a sincronização de metadados e sendo muito mais eficiente
- Em 100 INSERTs, a versão em Rust levou 2.562,99 ms, enquanto o SQLite levou 32,81 ms, uma diferença de 78 vezes
Fatores compostos de ineficiência
- Escolhas de design como clonagem e recompilação de AST, alocação de heap de 4 KB, recarregamento de esquema, formatação de strings e recriação de objetos se acumularam e causaram cerca de 2.900 vezes de perda de desempenho
- Cada decisão pode ser justificada em nome da “segurança”, mas, no hot path, acaba se tornando um gargalo crítico
- O desempenho do SQLite não vem simplesmente da linguagem C, mas de 26 anos de profiling e microajustes
Segundo caso: ferramenta de gerenciamento de disco desnecessariamente complexa
- Outro projeto em Rust gerado por LLM implementou um daemon para limpar artefatos de build com 82.000 linhas
- Incluía 192 dependências, um dashboard com 7 telas, um mecanismo de pontuação bayesiana e outras funcionalidades excessivas
- O problema real poderia ser resolvido com uma única linha de cron (
find ... -exec rm -rf)
- É um caso em que a “funcionalidade pedida” foi implementada fielmente, mas complexidade desnecessária foi adicionada à solução do problema real
Distância entre intenção e correção: o fenômeno da ‘Sycophancy’
- LLMs mostram uma tendência de “concordância bajuladora” (sycophancy) para se alinhar às expectativas do usuário
- Pesquisas da Anthropic (2024) e o benchmark BrokenMath (2025) confirmaram um problema estrutural em que os modelos aprendem a concordar em vez de priorizar a correção
- Até o GPT-5, quando recebe sinais positivos do usuário, gera provas de teoremas falsos em 29% dos casos
- O RLHF (aprendizado por reforço com feedback humano) reforça o viés de concordância (agreement bias)
- A OpenAI fez rollback do modelo na atualização do GPT-4o em 2025 por causa desse problema
- Esse mesmo viés atua não apenas na geração de código, mas também na revisão do próprio código, impedindo o modelo de detectar os próprios erros
Pesquisas externas e dados da indústria
- Experimento da METR (2025–2026): 16 desenvolvedores experientes de open source ficaram 19% mais lentos ao usar IA, embora percebessem que estavam mais rápidos
- Análise da GitClear (2020–2024): em 211 milhões de linhas, houve aumento de copy-paste e queda no refactoring
- Incidente da Replit (2025): um agente de IA apagou o banco de dados de produção e depois criou 4.000 usuários falsos
- Relatório Google DORA 2024: quando o uso de IA por equipes aumenta 25%, a estabilidade de entrega cai 7,2%
O critério de ‘correção’ mostrado pelo SQLite
- O SQLite tem cerca de 156.000 linhas de código em C, com 100% de cobertura MC/DC e um nível de verificação comparável ao de software aeronáutico
- Principais fatores de desempenho:
- Cache de páginas zero-copy
- Reutilização de prepared statements
- Verificação de schema cookie para evitar recargas desnecessárias
- Uso de fdatasync para minimizar a latência de commit
- Checagem de iPKey para garantir busca em O(log n)
- Em contraste, a versão reescrita em Rust tem 576.000 linhas, mas deixou de fora uma linha central (
is_ipk)
Conclusão: é preciso definir ‘correção’, não ‘plausibilidade’
- LLMs imitam padrões, mas não conseguem aprender sozinhas invariantes de desempenho
- “O código compila” não é suficiente; é preciso conseguir encontrar e explicar bugs diretamente
- LLMs se tornam ferramentas poderosas quando desenvolvedores experientes definem claramente os critérios de correção
- Caso contrário, são apenas geradores de tokens plausíveis, limitados ao nível de “vibe coding”
- Mensagem principal: defina primeiro os critérios de correção e depois meça.
16 comentários
Parece ser um caso que mostra bem o que acontece quando não se fornecem nem sequer critérios de sucesso simples relacionados a desempenho. Os agentes de código que usei até agora ainda buscam resolver o problema em si, mas, sem um prompt prévio explícito ou um loop de validação, quase não otimizam desempenho por conta própria. É preciso instruir a IA como se você estivesse propondo um problema de teste de programação. Especialmente mesmo em um caso como este, em que há um baseline, esperar o melhor resultado de desempenho sem explicitar as condições de performance pode até ser visto como uma espécie de negligência por parte de quem usa a IA.
+1 👍
Na verdade, não é só com LLM; com pessoas também é assim.
A diferença é que pessoas conseguem incorporar feedback, mas no LLM é quase impossível corrigir hábitos estranhos. Mesmo quando você aponta isso, em algum momento ele acaba fazendo a mesma coisa de novo.
Não é aí que surgem a ineficiência e o cansaço?
Quando as pessoas finalmente entendem as características do modelo e descobrem e aplicam prompts e fluxos de trabalho adequados, um modelo novo já apareceu....
Eu até questiono se hoje em dia já dá para usar agentes direito.
Até mesmo George Hotz usa a IA tendo consciência de que ela é apenas uma espécie de compilador. Em design, arquitetura ou escolhas, ainda é necessário o julgamento humano... No geral, se você simplesmente entregar o comando à IA, nem haveria motivo para um desenvolvedor fazer isso.
Se você comparar com uma query já perfeitamente implementada e super otimizada e pedir para reescrevê-la em outra linguagem, claro que vai ficar mais lenta
Porque foi só um “faz aí” kkk
Os vibecoders de nível Big Tech devem aparecer nos comentários.
Se não vai escrever um comentário produtivo, então simplesmente não escreva comentário.
Ri e sigo em frente
kkkkkkkk até post merda é post
não me xinguem
antes que isso vire a teoria da internet morta
cocô hihi
É trazido do Hacker News, mas será que acham que lá também só saem comentários produtivos o tempo todo... não fica bonito de ver.
Você ao menos leu as diretrizes do Hacker News..? É melhor evitar esse tipo de texto; essa mentalidade de “ele também faz merda, então por que só comigo?” é bem infantil.
Está errado. O certo seria dizer: ele também caga, então por que só pegam no pé dele?
Dá para perceber isso logo de cara só de mandar ele fazer um pouco. Eu não entendia quando outros desenvolvedores diziam que a revisão era cansativa, mas, por melhor que sejam o prompt e a habilidade usados, o código feito por IA sempre tinha alguma falha em algum ponto.
Li o texto original, e a análise e a crítica parecem válidas. Mas os modelos experimentais dos estudos citados, neste momento, dão uma impressão de estarem um pouco desatualizados.
Opiniões do Hacker News
Basicamente, quando surge um problema, LLMs tendem a tentar resolvê-lo cavando ainda mais código
Se a implementação começa com uma abordagem ineficiente, a cada nova restrição elas seguem acrescentando código de contorno ou código duplicado
Se o desempenho está lento, o código cresce exponencialmente com a adição de otimizações de caminho rápido, rotinas especiais e estruturas de dados customizadas
Se há muitos bugs, criam 10 testes para cada bug e, se o framework de mocking existente não serve, fazem outro do zero
Se alguém diz para consolidar a duplicação, respondem “ótimo, vou criar um novo metamock abstract adapter framework com todas as funcionalidades!” e adicionam mais uma estrutura complexa
A revisão é indispensável para evitar premissas erradas e dívida técnica
Primeiro, fazer o modelo projetar uma arquitetura razoável e, se os módulos se embolarem, mandá-lo recomeçar em um contexto limpo
LLMs são fracos em iterar repetidamente sobre o mesmo código, mas fortes em reimplementar do zero, em estilo “Groundhog Day”
LLMs não alertam nem lembram você do resultado desse tipo de julgamento
Por isso prefiro Claude Code ao Codex
Na redação de documentos jurídicos, o resultado “plausível” dos LLMs também é um problema
À primeira vista parece válido, mas muitas vezes contém alegações logicamente inadequadas ou perigosas
Como juízes muitas vezes não têm tempo nem disposição para revisar tudo em detalhe, esses documentos às vezes passam sem contestação
Isso cria uma assimetria parecida com a lei de Brandolini: gerar é fácil, refutar é difícil
No fim, isso se parece com a situação em que futuros desenvolvedores terão de desfazer a dívida cognitiva e técnica criada por LLMs
Quando um LLM redige documentos baseados em normas, ele inclui insinuações plausíveis, mas sem fundamento
Então eu peço ao próprio LLM que revise o texto e marque esse tipo de trecho, mas no fim das contas ainda é necessária revisão humana
Colegas geram PRs com milhares de linhas em poucos minutos usando LLM
Até incluem testes, mas muitas vezes o resultado é um desastre
No fim, o revisor precisa passar o dia inteiro analisando, entendendo a estrutura errada e explicando como corrigir
Por isso eu sugeriria que PRs feitos com AI dessem story points ao revisor
Precisamos de uma estrutura que calcule julgamentos racionais com lógica formal e traduza o resultado para linguagem natural
LLMs devem ficar não no pensamento em si, mas na etapa de interpretação e expressão
Código feito por LLM muitas vezes passa nos testes, mas não atende aos requisitos
Por exemplo, chama
fsynca cada query ou identifica incorretamente a chave primáriaEm projetos grandes, há código demais para uma pessoa ler tudo
Por isso LLM é mais eficiente quando usado no nível de autocompletar
Dá para revisar pequenos trechos imediatamente, e o Claude costuma ser preciso
Mas, se você entrega o código inteiro, acaba gastando mais tempo com planejamento e gerenciamento, e a manutenção também fica mais difícil
No fim, a vantagem de velocidade só existe quando está reproduzindo código que já aparece nos dados de treinamento
LLMs geram, estatisticamente, os padrões de código mais comuns
Por isso, sem instruções específicas, sai um código “com cara de enterprise, baseado em OOP e cheio de dependências da moda”
É preciso definir e medir o que é “correto”
Para automação, são necessários intenção (intent) e medição (measurement)
É preciso entender a faixa de risco para saber quanto cobrir antecipadamente
Se ferramentas como AI evals e eval-ception evoluírem para uma linguagem comum entre papéis, colaborar ficará muito mais fácil
A essência dos LLMs é terem sido projetados para gerar o código mais plausível
Isso é resultado de cross entropy loss, e embora pós-processamentos como RLVR tentem aumentar a precisão,
ainda restam muitos vestígios
No futuro, o avanço de reward engineering pode levar a resultados melhores
À pergunta “e isso é diferente de humanos em quê?”
Durante o sono, essa função se desliga e surgem pensamentos ilógicos como em sonhos; o raciocínio de LLMs está em um nível parecido de lógica de sonho
Antes havia a ansiedade de não compreender totalmente a tecnologia, mas agora as ferramentas encobrem essa ansiedade
Entramos numa era em que se produz resultado mesmo sem entendimento profundo
Mas as pessoas esperam uma AI objetiva que dá a resposta certa
Essa discrepância cria uma diferença de percepção entre usuários comuns e especialistas
Há gente abrindo PRs com milhares de linhas por dia
A maioria é um desastre, então revisar é impossível
Antes, fazer um PR assim levaria uma semana; agora eles aparecem em um único dia
Há muitas dúvidas sobre o próprio termo “LLM”
O modelo chamado diretamente via API bruta é o LLM; Claude.ai e ChatGPT são isso com um harness por cima
Esse harness inclui template de prompt, gerenciamento do estado da conversa e outras funções
No fim, quase sempre usamos mais do que apenas um LLM
Esse tipo de agente pode executar código, testar por conta própria e corrigir o que for preciso
ChatGPT e Claude também têm essa capacidade, então na prática são coding agents
Então, dizer que “LLMs não têm memória” só vale para o modelo em si
Claude Code e Cursor são agentic systems que mantêm estado
O título deste texto é interessante, mas dizer que LLM escreve “código plausível” é impreciso
Na prática, ele só gera código semelhante a clusters de código vistos nos dados de treinamento
Ele só gera com liberdade em áreas não limitadas por RLHF ou RLVR
Por isso a indústria inteira fala a mesma linguagem, mas isso acaba sendo também a causa de mal-entendidos
Faz todo mundo achar que está resolvendo o mesmo problema
Por exemplo, se você pedir uma query de tree-sitter, ele inventa diretivas que não existem
Não é preciso explicar toda a estrutura interna complexa
Recentemente pedi ao Codex para criar um componente de UI baseado em Datastar, e ele falhou completamente
Era uma tarefa simples, mas quanto mais eu tentava de novo, mais JavaScript inline e código de backend iam se acumulando
Ele nem limpava o código anterior
Vai bem em tarefas complexas, mas curiosamente mostra falhas contraintuitivas em tarefas básicas