Medir una semana de IA
La semana pasada hice una maratón de 7 días con IA — un experimento para revisar, con datos reales, cómo estoy usando estas herramientas.
DevTrack lo registró todo.
Los números
~74.700 líneas añadidas. Más de 4.200 comandos ejecutados. ~7.300 líneas eliminadas. ~67.000 líneas netas.
Para dimensionarlo: el código completo de mi proyecto de tesis de grado no supera las 100 líneas.
Mi trabajo estuvo distribuido principalmente entre TypeScript, Python y Markdown. Y acá aparece algo que no esperaba: Markdown fue uno de los lenguajes más frecuentes de la semana.
Lo que dice el Markdown
Al principio lo leí como un dato menor. Después entendí que no lo era.
Una parte enorme de mi proceso ha evolucionado hacia externalizar pensamiento — documentar arquitectura, conectar ideas, sostener contexto entre sesiones. Eso pasa casi todo en Markdown. No es código que corre, pero es código que piensa.
Hay algo en eso que todavía no sé cómo nombrar exactamente. Pero está pasando y los datos lo confirman.
El patrón de tiempo
La correlación entre tiempo de inmersión y producción fue absurdamente alta. Las sesiones largas no disminuyeron rendimiento — lo aumentaron más allá de lo lineal.
Los bloques más productivos ocurrieron consistentemente entre las 4:00 PM y las 9:00 PM, con pico claro alrededor de las 7:00–8:00 PM.
Eso no es una intuición. Es el patrón que apareció día tras día, repetido con suficiente consistencia como para dejar de tratarlo como coincidencia.
Por qué importa medirlo
Tenía intuiciones sobre todo esto. La sensación de que algunas sesiones eran cualitativamente distintas. Que había un umbral mental que, una vez cruzado, cambiaba la naturaleza del trabajo.
El problema es que las intuiciones no escalan. Se distorsionan con el tiempo, se mezclan con el estado de ánimo, no se pueden compartir de forma honesta.
Los datos sí.
DevTrack existe para eso: registrar líneas escritas, archivos editados, comandos ejecutados, tiempo activo. Todo local, todo en SQLite, sin cuenta, sin nube. El dashboard es una interfaz web que levantas cuando quieres ver los números.
Lo que cambió después de medir
Ver los datos cambia la relación con el trabajo.
Cuando sabes a qué hora funcionas mejor, puedes proteger ese tiempo. Cuando ves que las sesiones largas no te destrozan sino que te potencian, dejas de interrumpirlas. Cuando el Markdown aparece en tus métricas como lenguaje principal, empiezas a tomarte en serio la documentación como parte del proceso productivo y no como overhead.
Medir no es lo mismo que optimizar. No se trata de exprimir más horas o más líneas. Se trata de entender el patrón real y trabajar a favor de él en lugar de contra él.
Las sesiones en pantalla
Esto es lo que se ve cuando DevTrack registra una sesión real.
27 de abril: trabajo en dos bloques. Mañana de exploración, tarde de ejecución. El pico de tarde superó al de mañana — el contexto acumulado en la primera mitad del día se convirtió en velocidad en la segunda.
11 de mayo: sesión nocturna continua. 221 líneas al arrancar a las 18h. 4.370 a las 19h. 2.336 a las 20h. Caída sostenida desde ahí hasta cero a las 23h.
Las dos horas de pico — 19h y 20h — concentraron el 78% del output total de la sesión en 120 minutos.
El patrón es el mismo en ambas: hay un punto de inflexión. Antes de ese punto, el trabajo existe pero es lento. Después, escala. La pregunta que DevTrack ayuda a responder es cuándo ocurre ese punto y qué condiciones lo favorecen.
Instalación
DevTrack es open source y gratuito.
GitHub: github.com/Fedgutcor/DevTrack
git clone https://github.com/Fedgutcor/DevTrack
cd DevTrack
pip install -r requirements.txt
python devtrack.py
Si te sirve y quieres apoyar para que siga activo, puedes invitar un café.
Pull requests bienvenidas. Issues también.