Claude Code construyó en 12 horas un motor SPARQL dentro de SQLite. Quien lo encargó no lo ha leído

Simon Willison escribió desde el móvil un único prompt, con errata incluida, y Claude Code for web pasó más de 12 horas construyendo en Rust una extensión que añade el lenguaje de consultas SPARQL 1.1 a SQLite. El proyecto impresiona desde el punto de vista técnico y, a la vez, muestra con precisión dónde se acaba la supervisión humana en la programación con agentes.

Un prompt con una errata bastó para once crates de Rust

Willison describió el experimento el 16 de octubre en su blog. Sobre todo quería probar el modo Ultracode de Claude Code for web, en el que Claude genera JavaScript que coordina toda una red de subagentes, lo que la documentación llama dynamic workflows. El encargo pedía, más o menos, una extensión de SQLite en Rust que implementara SPARQL y fuera rápida porque lee las filas directamente. La palabra «delete» del prompt original fue, según él, una errata del teléfono.

El agente trabajó más de 12 horas. Después Willison envió un único prompt adicional: un README en cada carpeta, un tutorial y un script con datos de ejemplo. Así nació sparqlite, con 11 crates de Rust y un tutorial de unos 240 kB. El repositorio indica abiertamente que todo el texto y el código los escribió un modelo de lenguaje.

Según el README, sparqlite guarda los datos RDF en tablas normales de SQLite y evalúa las consultas con su propio motor, en lugar de traducirlas a una sola sentencia SQL. Opcionalmente lee las páginas del árbol B directamente del archivo. Con un conjunto de 1,6 millones de tripletas de una red social y 1 millón de tripletas de productos, es en media geométrica 3,5 veces más rápido que la traducción a SQL y 10,6 veces más rápido que pyoxigraph al contar resultados. Al devolver resultados completos, las cifras son 2,8 y 6,6 veces.

Las pruebas de comportamiento sustituyen a la lectura del código

El propio Willison escribe que no puede revisar el código de forma realista y que incluso seguir la documentación exige un esfuerzo considerable. Se pregunta qué valor tiene una implementación completa de SPARQL creada por capricho si no va a dedicar tiempo a entenderla.

El agente respondió de la única manera que tenía a mano: con pruebas en lugar de revisión. Según el README supera 636 de 639 tests aplicables del W3C (99,5 %) y atribuye los tres fallos al parser spargebra en el que se apoya. A eso se suman más de 1.000 tests en Rust, 50 tests en pytest y fuzzing diferencial con unos 7,7 millones de comparaciones frente a una implementación deliberadamente ingenua copiada directamente de la especificación.

Para los equipos de ingeniería es un patrón útil. Con código escrito por agentes, la verificación pasa de las líneas sueltas al comportamiento comprobable: una batería de pruebas estándar, un modelo de referencia independiente y la comparación con una biblioteca existente. SPARQL encaja bien porque el W3C ya publica su batería de pruebas. La mayoría de los sistemas internos de una empresa no tienen nada parecido.

El mismo agente escribió las pruebas, los benchmarks y el modelo de control

Ahí está el punto débil. La implementación de referencia, el ejecutor de pruebas y los benchmarks salieron del mismo agente. El README afirma que el ejecutor se validó frente a un evaluador independiente y con pruebas de mutación, pero también eso lo cuenta el propio modelo. Las cifras de rendimiento proceden de una sola máquina en la nube con 4 vCPU y nadie las ha reproducido todavía.

El segundo problema es el mantenimiento. Una extensión que lee el formato interno de los archivos de SQLite es sensible a los cambios de la propia base de datos. El README lo resuelve volviendo a los cursores normales cuando el lector no está seguro, por ejemplo con una base de datos en modo WAL. Quien despliegue sparqlite heredará un código que ni siquiera entiende quien lo encargó. Willison, de hecho, lo guardó en su repositorio de investigación y no entre sus herramientas terminadas.

Su valor lo decidirán quienes usan SPARQL de verdad

La primera señal será si la comunidad de RDF y web semántica prueba sparqlite y si sus mediciones confirman las cifras del README. Una sola repetición independiente del benchmark pesa más que otros mil tests del mismo agente.

La segunda señal tiene que ver con la responsabilidad. Hoy un agente puede entregar un motor de base de datos completo en una noche. Lo decisivo será quién firma ese código cuando, dentro de seis meses, alguien encuentre un fallo.

El veredicto de Lilith

Willison encargó un motor de base de datos con una errata desde el móvil y por la mañana tenía 11 crates, casi un cuarto de megabyte de tutorial y 7,7 millones de comparaciones que garantizan que funciona. Ahora es dueño de una máquina con un manual muy gordo y sin ningún mecánico que sepa qué hay bajo el capó.