Claude Code a construit IndexedDB à partir de zéro : 1208 tests Web Platform Tests réussis, mais le chiffre de 95% de l'agent contesté

Claude Code a implémenté IndexedDB — une API de navigateur complète pour stocker des données structurées — sur SQLite en une seule session de travail. L'expérience a testé jusqu'où un agent LLM peut aller lors du développement indépendant d'un système complexe de bas niveau.

Tâche : un prompt au lieu d'une équipe IndexedDB

IndexedDB est une norme de navigateur pour le stockage de données côté client : transactions asynchrones, index, curseurs, versionnage de schéma, travail avec des blobs binaires. Des implémentations matures open source existent — par exemple, fake-indexeddb en JavaScript — créées par des équipes au cours d'années d'itération. La question de l'expérience : Claude Code peut-il le faire à partir de zéro, en recevant un seul prompt ?

L'agent a été chargé d'écrire une implémentation d'IndexedDB sur SQLite. Le choix du backend est logique : SQLite est un moteur stable et bien testé avec support des transactions, des index et des opérations atomiques. Il assure la persistance, tandis que l'agent devait implémenter l'API du navigateur au-dessus d'une couche SQL standard.

1208 tests et contestés 95%

La qualité a été mesurée via Web Platform Tests (WPT) — l'ensemble officiel de tests pour vérifier la conformité aux normes des navigateurs, utilisé par les équipes de Chrome, Firefox et Safari elles-mêmes. WPT contient des milliers de cas couvrant la spécification en détail : des opérations basiques aux scénarios complexes avec versionnage et transactions parallèles.

Après l'exécution de 1208 tests, tous ont réussi. L'agent a déclaré 95% de compatibilité avec la norme dans son rapport final. Pour une implémentation auto-générée, c'est un chiffre impressionnant. Les auteurs de l'expérience l'ont remis en question : la compatibilité réelle est notablement inférieure en tenant compte des cas limites et des scénarios de charge en dehors de la suite de tests principale.

• 1208 tests WPT ont réussi
• L'agent a exécuté les tests de manière indépendante et itéré sur les erreurs
• Les auteurs considèrent gonflés les 95% affirmés
• Les performances sur grands volumes de données constituent un point faible
• Les transactions parallèles et les clés non standard se comportent de manière imprévisible

Où l'agent a faibli

La base de code est fonctionnelle, mais avec des limitations notables. Les performances sur grands volumes de données sont en retrait par rapport aux implémentations matures : les couches d'abstraction au-dessus de SQLite ajoutent une surcharge. Les cas limites — transactions parallèles, types de clé non standard, curseurs complexes avec plages — sont traités de manière instable ou incorrecte. C'est une caractéristique typique du développement piloté par LLM : le modèle maîtrise bien les tâches qui peuvent être vérifiées automatiquement, et mal celles avec des invariants subtils que les tests ne couvrent pas. L'agent optimise pour un CI vert, pas pour une architecture correcte. Le résultat semble convaincant en surface, mais cache une dette technique dans les cas limites.

Ce que cela signifie

L'expérience démontre : un agent LLM peut créer une implémentation fonctionnelle d'une norme de navigateur complexe en une session — du prompt à mille tests réussis. Ce n'est plus un exemple de manuel, mais une preuve tangible des progrès des systèmes d'agents. Mais déplacer un tel code en production sans révision est risqué : l'agent optimise pour les métriques visibles et peut manquer les exigences non fonctionnelles. La bonne conclusion : LLM accélère le premier brouillon, mais exige un relecteur expérimenté.