Simon Willison ha lanzado sqlite-utils 4.1, el primer dot-release después de la versión 4.0rc2 escrita casi enteramente con Claude Fable. La actualización introduce cinco funcionalidades menores: la opción --code para generar filas directamente desde código Python, --type para forzar el tipo de columna (útil para códigos postales que parecen números pero deben conservarse como texto), un método para eliminar índices, la capacidad de leer queries SQL desde entrada estándar, y soporte para cambiar una tabla de strict a no-strict y viceversa.

Por qué te importa: el código escrito por un agente hace cuatro días ha superado el primer ciclo de desarrollo real. Willison usó GPT-5.6 Sol xhigh Codex para implementar las funcionalidades, e instruyó explícitamente al modelo para que testeara manualmente su propio trabajo fuera de los tests automatizados. Esta vez identificó dos bugs menores que los tests unitarios no habían detectado. No es la primera vez que shipea código asistido por IA, pero es la primera vez que la base de código completa ha sido reescrita por un agente y la primera actualización posterior confirma que esa base es sólida.

Dónde mirar: Willison publica siempre los transcripts completos de las sesiones con Codex. El prompt más interesante es «use uv run python -c and manually exercise the new .transform(strict=) option, see if you can find any edge-cases or bugs», que delega al modelo el testeo exploratorio manual.

En detalle

El contexto

Hace cuatro días Willison había lanzado sqlite-utils 4.0rc2, una release candidate escrita casi enteramente por Claude Fable en 37 prompts por alrededor de 149 dólares. Esa reescritura había tocado gran parte de la base de código, añadiendo migraciones de schema y otras funcionalidades estructurales. La 4.1 es el primer dot-release después de esa reescritura, y la prueba real de cuán mantenible es ese código.

Las nuevas funcionalidades

Cinco adiciones, todas pequeñas pero solicitadas desde hace tiempo:

1. --code para insert y upsert: en lugar de importar datos desde archivo, puedes pasar un bloque de código Python (o la ruta a un .py) que define una función rows() o un iterable de filas. Extiende el patrón que sqlite-utils ya usaba para sqlite-utils convert, donde pasas bloques de código como argumento CLI.

2. --type para override del tipo de columna: cuando creas una tabla desde CSV o TSV, puedes forzar el tipo de una columna. Útil para códigos postales o identificadores que parecen números pero deben mantenerse como texto para conservar los ceros iniciales. Una funcionalidad solicitada en 2019 (issue #131), implementada ahora porque Codex la señaló como “fácil” durante una revisión de todos los issues abiertos.

3. Eliminar índices: nuevo método table.drop_index(name) y comando sqlite-utils drop-index, ambos con opción ignore=True/--ignore para no fallar si el índice no existe.

4. Queries desde stdin: sqlite-utils query ahora acepta - en lugar de la query SQL, para leerla desde entrada estándar. Permite echo "select * from dogs" | sqlite-utils query dogs.db -.

5. Cambiar strict mode: table.transform() y el comando sqlite-utils transform ahora aceptan --strict y --no-strict para convertir una tabla de strict a no-strict y viceversa. Inspirado por un post de Evan Hahn que observaba cómo no existe un ALTER TABLE para cambiar strict mode: el mecanismo transform de sqlite-utils, que copia los datos en una nueva tabla, es exactamente lo que se necesita.

El método de trabajo

Willison usó GPT-5.6 Sol xhigh a través de Codex. El prompt más significativo de la sesión fue: «use uv run python -c and manually exercise the new .transform(strict=) option, see if you can find any edge-cases or bugs». Delega al modelo no solo la escritura del código, sino también el testeo exploratorio manual, fuera de los tests automatizados. Esta vez encontró dos bugs menores que los tests unitarios no habían interceptado, y que fueron corregidos en la misma sesión.

Qué significa

La 4.0 fue una reescritura profunda. La 4.1, lanzada cuatro días después, demuestra que esa base de código supera el primer ciclo de desarrollo real: el agente que la escribió no dejó deuda técnica oculta, y un segundo agente (modelo diferente) pudo trabajar sobre ella sin incidentes. El código escrito por un agente se shipea, y el código posterior continúa shipándose.

Willison siempre publica los transcripts completos, permitiendo ver exactamente qué prompts produjeron qué. Este es el hilo que estamos siguiendo: agentes que escriben código que llega a producción, con el costo y las limitaciones documentadas cada vez.