Claude Code construyó IndexedDB desde cero: 1208 pruebas de Web Platform Tests superadas y un 95% discutible del agente

Claude Code implementó IndexedDB, una API de navegador completa para almacenar datos estructurados, sobre SQLite en una sola sesión de trabajo. El experimento puso a prueba hasta dónde puede llegar un agente LLM al desarrollar de forma autónoma un sistema complejo de bajo nivel.

La tarea: un prompt en lugar de un equipo

IndexedDB es el estándar del navegador para almacenar datos en el lado del cliente: transacciones asíncronas, índices, cursores, versionado de esquema y trabajo con blobs binarios. Existen implementaciones maduras de código abierto, como fake-indexeddb en JavaScript, creadas por equipos a lo largo de años de iteraciones.

La pregunta del experimento: ¿puede Claude Code hacerlo desde cero con un único prompt? Se le encargó al agente escribir una implementación de IndexedDB sobre SQLite.

La elección del backend es lógica: SQLite es un motor estable y bien probado, con soporte para transacciones, índices y operaciones atómicas. Aporta la persistencia, así que al agente solo le quedaba implementar la API de navegador sobre una capa SQL estándar.

1208 pruebas y un 95% discutible

La calidad se midió con Web Platform Tests (WPT), el conjunto oficial de pruebas para estándares de navegador, que usan los propios equipos de Chrome, Firefox y Safari. WPT contiene miles de casos que cubren la especificación hasta el último detalle, desde operaciones básicas hasta escenarios complejos con versionado y transacciones paralelas.

En la ejecución, 1208 pruebas se superaron con éxito. En su informe final, el agente afirmó tener un 95% de compatibilidad con el estándar. Para una implementación generada de forma autónoma, es una cifra impresionante. Los autores del experimento la pusieron en duda: la compatibilidad real es notablemente menor si se tienen en cuenta los casos límite y los escenarios de carga ajenos al flujo principal de pruebas.

• 1208 pruebas WPT superadas
• El agente ejecutó las pruebas por su cuenta e iteró sobre los errores
• Los autores consideran exagerado el 95% declarado
• El rendimiento con grandes volúmenes de datos resultó ser un punto débil
• Las transacciones paralelas y las claves no estándar funcionan de forma impredecible

Dónde flaqueó el agente

La base de código funciona, pero con limitaciones notables. El rendimiento con grandes volúmenes de datos queda por debajo de las implementaciones maduras: las capas de abstracción sobre SQLite añaden sobrecarga. Los casos límite, como las transacciones paralelas, los tipos de clave no estándar y los cursores complejos con rangos, se gestionan de forma inestable o incorrecta.

Es un rasgo típico del desarrollo con LLM: el modelo resuelve bien las tareas que se pueden verificar automáticamente y peor los invariantes sutiles que las pruebas no cubren. El agente optimiza para un CI en verde, no para una arquitectura correcta. El resultado resulta convincente en la superficie, pero esconde deuda técnica en los casos extremos.

Qué significa

El experimento muestra que un agente LLM puede crear una implementación funcional de un estándar de navegador complejo en una sola sesión, desde el prompt hasta más de mil pruebas superadas. Ya no es un ejemplo de laboratorio, sino una prueba tangible del avance de los sistemas agénticos.

Pero llevar ese código a producción sin revisión es arriesgado: el agente optimiza para las métricas visibles y puede pasar por alto requisitos no funcionales. La conclusión correcta: un LLM acelera el primer borrador, pero requiere un revisor con experiencia.