¿Qué ocurrió?

Simon Willison anunció el 12 de agosto de 2026 la versión alfa alchemy-utils 0.1a0, una variante independiente de base de datos (database agnostic) de su librería sqlite-utils. Willison describió el proyecto como un "proyecto de ducha matutina" y explicó que encargó la tarea a Codex y al modelo GPT-5.6 Sol Ultra.

La definición de la tarea consistía en crear una librería que ofreciera las mismas funciones que los métodos insert, upsert, insert_all, upsert_all, create y update de sqlite-utils, junto con las funciones de introspección de tablas, pero construida sobre SQLAlchemy y capaz de funcionar con múltiples motores de bases de datos. Willison señaló que unos pocos comandos adicionales bastaron para llevar el proyecto a un punto lo suficientemente maduro como para publicarlo como alfa.

¿Por qué es importante?

El proyecto se construyó utilizando desarrollo guiado por pruebas rojo/verde (TDD) y pytest, tomando como referencia los repositorios existentes de Willison, sqlite-utils y django-sql-dashboard. La librería se probó contra las bases de datos PostgreSQL, SQLite y DuckDB.

Como ejemplo, Willison mostró que pudo listar las filas de una tabla de su base de datos de blog alojada en PostgreSQL con un único comando uvx. También logró importar un archivo CSV con la lista de árboles de San Francisco a una base de datos DuckDB cuyo esquema se generó automáticamente.

  • Al estar basada en SQLAlchemy, la librería admite múltiples motores de bases de datos, incluidos PostgreSQL, SQLite y DuckDB.
  • La importación inicial del CSV tardó aproximadamente una hora, pero tras la optimización realizada por Codex, el tiempo se redujo a 35 segundos.
  • El proyecto se inició con uv init y se desarrolló en un repositorio git siguiendo el principio de hacer commits tempranos y frecuentes.

¿Qué sigue?

Willison indicó que alchemy-utils se encuentra actualmente en etapa alfa y dio señales de que continuará desarrollando el proyecto. Todavía no está claro si la librería llegará a cubrir todas las funciones principales de sqlite-utils o si se admitirán motores de bases de datos adicionales en el futuro.

La cifra que importa: código que funciona frente a código utilizable

Lo más comentado del experimento fue que la librería apareciera tras unas pocas instrucciones. Pero la cifra más instructiva es otra: la primera versión funcionaba correctamente y hacía el mismo trabajo en cerca de una hora. Tras la optimización, 35 segundos. Es una diferencia de rendimiento cercana a cien veces entre la primera salida y una utilizable, y se mantenía en un código que superaba sus propias pruebas.

Es una propiedad poco reportada del código escrito por modelos. La corrección es fácil de comprobar: las pruebas pasan o no pasan. El rendimiento solo aparece cuando el código se ejecuta con datos reales y a tamaño real. Lo que lo detectó en el experimento de Willison no fue una prueba, sino intentar de verdad importar la lista de árboles de San Francisco.

Qué demuestra el experimento y qué no

Las condiciones eran inusualmente favorables. Willison había diseñado él mismo la API que se replicaba; podía señalar al modelo dos repositorios propios como referencia; aplicó desde el principio la disciplina de pruebas rojo/verde; y tenía la experiencia necesaria para juzgar si el resultado era correcto. Alguien que no reúna esas cuatro condiciones a la vez puede no obtener el mismo resultado del mismo proceso.

También hay cosas que no se comparten: no existe comparación con el tiempo que habría llevado escribir la librería a mano, ni un recuento de defectos que queden en la alfa, ni datos sobre qué ocurre en producción. El propio Willison etiqueta la versión como alfa. No estamos ante una medición de productividad, sino ante un único caso bien documentado, y buena parte de su valor viene de que el historial de instrucciones se publicó íntegro.