Qué pasó. Simon Willison publicó el gráfico “Code frequency” de GitHub del proyecto Datasette, mostrando un aumento visible de la actividad de commits en el último período. Willison lo vincula explícitamente con la llegada de los modelos Opus 4.8, GPT-5.5, Fable 5 y GPT-5.6 Sol: el pico final del gráfico corresponde a cuando comenzó a usar estos modelos como coding agents.

Por qué te importa. Es la continuación de la historia sqlite-utils: como contábamos el 5 de julio, Willison había publicado un release candidate escrito casi enteramente por Claude Fable, documentando costos y número de prompts. Ahora documenta el impacto a largo plazo con un dato verificable: la frecuencia de commits en GitHub, que cualquiera puede comprobar. No es una impresión, es una métrica pública que muestra cuánto código se modifica con el tiempo. Para quien se potencia con IA, es un ejemplo de cómo medir el efecto de la adopción: no solo “me parece que voy más rápido”, sino “aquí está el gráfico de cambios antes y después”.

Si quieres probarlo. El gráfico “Code frequency” está disponible para cada repositorio público en GitHub: ve a github.com/<usuario>/<repo>/graphs/code-frequency y verás adiciones y eliminaciones por semana. En tu proyecto, ¿el pico corresponde a la adopción de agentes?

En detalle

El contexto: de sqlite-utils a Datasette. A principios de julio Willison había contado que reescribió gran parte de sqlite-utils 4.0rc2 con Claude Fable, gastando 149 dólares y documentando cada paso. Esa historia terminaba con un release candidate funcional y un primer dot-release que confirmaba: el código escrito por el agente aguanta en producción. Ahora la narrativa se traslada a Datasette, otro proyecto open source de Willison, y cambia la herramienta de medida: ya no el costo de un único release, sino la evolución de la actividad de desarrollo en el tiempo.

Qué dice el gráfico. El gráfico “Code frequency” de GitHub muestra dos curvas: líneas añadidas (verde) y líneas eliminadas (rojo) para cada semana. Willison señala un pico de actividad al final, que se alinea temporalmente con la adopción de Opus 4.8, GPT-5.5, Fable 5 y GPT-5.6 Sol. Es un indicador tosco — cuenta líneas de código modificadas, no la calidad o el impacto de los cambios — pero es público y verificable: cualquiera puede abrir el link y ver el mismo gráfico. No es un benchmark sintético: es trabajo real en un proyecto que existe desde 2017 y tiene un historial de commits consistente.

Cuánta confianza darle. El propio Willison escribe “out of curiosity” y presenta el gráfico como una ilustración, no como una demostración rigurosa. El pico podría reflejar otros factores: una fase del proyecto, un refactoring amplio, features que tocan muchos archivos. No sabemos qué porcentaje del código en ese pico fue escrito directamente por el agente y cuál fue modificado por Willison después del primer borrador. El gráfico no dice nada sobre calidad: más líneas modificadas pueden significar más valor entregado, u más pasos para llegar al mismo resultado. Pero como señal de tendencia — “la actividad de desarrollo aumentó en el período en que adopté estos modelos” — es un dato honesto y verificable.

Qué NO concluir. Esto no es una prueba controlada: no hay grupo de control, no hay una baseline normalizada para la complejidad de las features. No puedes tomar el gráfico y decir “los agentes duplican la productividad”, porque no estás midiendo productividad: estás midiendo volumen de cambios. Pero es un ejemplo de cómo un profesional documenta el impacto en su trabajo con métricas ya disponibles, en lugar de depender solo de impresiones. Para quien está adoptando agents de coding, la lección práctica es: mira tus gráficos de commits, tus tiempos de cierre de issues, el número de pull requests abiertas. Si el impacto existe, debería aparecer ahí, no solo en el relato.