Claude Code criou o IndexedDB do zero: 1208 testes do Web Platform Tests passam, mas os 95% do agente são questionáveis

O Claude Code implementou o IndexedDB, uma API de navegador completa para armazenar dados estruturados, sobre o SQLite em uma única sessão de trabalho. O experimento testou até onde um agente LLM consegue chegar ao desenvolver sozinho um sistema complexo de baixo nível.

A tarefa: um prompt no lugar de uma equipe

O IndexedDB é o padrão dos navegadores para armazenar dados no lado do cliente: transações assíncronas, índices, cursores, versionamento de esquema e trabalho com blobs binários. Existem implementações maduras de código aberto, como o fake-indexeddb em JavaScript, criadas por equipes ao longo de anos de iterações.

A pergunta do experimento: o Claude Code consegue fazer isso do zero, com um único prompt? O agente foi encarregado de escrever uma implementação do IndexedDB sobre o SQLite.

A escolha do backend é lógica: o SQLite é um mecanismo estável e bem testado, com suporte a transações, índices e operações atômicas. Ele garante a persistência, e ao agente restava implementar a API de navegador sobre uma camada SQL padrão.

1208 testes e 95% questionáveis

A qualidade foi medida com o Web Platform Tests (WPT), o conjunto oficial de testes para padrões de navegador, usado pelas próprias equipes do Chrome, Firefox e Safari. O WPT tem milhares de casos que cobrem a especificação nos mínimos detalhes, de operações básicas a cenários complexos com versionamento e transações paralelas.

Na execução, 1208 testes passaram. No relatório final, o agente declarou 95% de compatibilidade com o padrão. Para uma implementação gerada de forma autônoma, é um número impressionante. Os autores do experimento o questionaram: a compatibilidade real é visivelmente menor quando se consideram casos de borda e cenários de carga fora do fluxo principal de testes.

• 1208 testes do WPT passaram
• O agente executou os testes por conta própria e iterou sobre os erros
• Os autores consideram inflados os 95% declarados
• O desempenho com grandes volumes de dados se mostrou um ponto fraco
• Transações paralelas e chaves fora do padrão funcionam de forma imprevisível

Onde o agente falhou

A base de código funciona, mas com limitações perceptíveis. O desempenho com grandes volumes de dados fica atrás das implementações maduras: as camadas de abstração sobre o SQLite acrescentam sobrecarga. Casos de borda, como transações paralelas, tipos de chave fora do padrão e cursores complexos com intervalos, são tratados de forma instável ou incorreta.

Isso é típico do desenvolvimento com LLMs: o modelo vai bem em tarefas que podem ser verificadas automaticamente e pior em invariantes sutis que os testes não cobrem. O agente otimiza para um CI verde, não para a arquitetura correta. O resultado parece convincente na superfície, mas esconde dívida técnica nos casos extremos.

O que isso significa

O experimento mostra que um agente LLM é capaz de criar uma implementação funcional de um padrão de navegador complexo em uma única sessão, do prompt a mais de mil testes aprovados. Isso já não é um exemplo didático, mas uma prova concreta do avanço dos sistemas agênticos.

Mas levar esse código para produção sem revisão é arriscado: o agente otimiza para métricas visíveis e pode deixar passar requisitos não funcionais. A conclusão correta: o LLM acelera o primeiro rascunho, mas exige um revisor experiente.