El martes pasado le pedí a Claude Code que refactorizara un servicio. El plan estaba claro, el prompt era bueno, y me dije a mí mismo que lo vigilaría trabajar y revisaría el diff en 15 minutos.
Miré la franja una hora después. Claude Code tenía 18 minutos de tiempo en primer plano. Twitter (bueno, X) tenía 27 minutos. Slack tenía 11. La revisión de código de verdad ocurrió en los últimos 4 minutos, en un estado de pánico leve, porque había prometido el diff antes de comer.
Este es el problema del rastreador de tiempo para desarrolladores en un solo párrafo. La IA hace el trabajo. Se supone que tú supervisas. En la práctica, "supervisar" significa "mirar un indicador de progreso durante 2 minutos, aburrirte, ponerte a hacer scroll, perder 40 minutos y volver para encontrar el trabajo hecho y sin revisar". Un buen rastreador te dice que esto pasó. Uno excelente te dice que pasa todos los martes.
La mayoría de los rastreadores existentes no categorizan el flujo de trabajo del desarrollador, así que no pueden contarte esto. Ven "Chrome" y "Slack" y "tu editor" como cubos planos. Eso se pierde la forma real de cómo funciona el día de un desarrollador en 2026.
Cómo es el día de un desarrollador ahora
La composición del tiempo de pantalla de un desarrollador ha cambiado mucho en los últimos dos años. Un día típico para mí, por app, se ve más o menos así:
Ghostty — 4h 04m (terminal — Claude Code lives here too)
Octoweb — 1h 34m (browser — docs, GitHub, Hacker News)
Break — 41m (Timex break overlay)
Firefox Dev Ed — 39m (the work browser)
Slack — 27m
Chrome — 27m (work meetings, Notion, AI vendor consoles)
loginwindow — 12m (the lock screen — yes, we track it)
Spark Desktop — 6m (email)
Ese es un martes real de nuestros logs internos. La forma es más o menos: 60% trabajo de terminal/IDE, 25% navegador-como-herramienta, 10% comunicación, 5% la pantalla de bloqueo entre sesiones.
Lo interesante no son los totales. Es la subdivisión dentro del tiempo de terminal. De esas 4 horas en Ghostty, ¿cuánto fue Claude Code haciendo preguntas y esperando respuestas? ¿Cuánto fui yo tecleando comandos de verdad? ¿Cuánto fui yo leyendo la salida? Un rastreador honesto para desarrolladores tiene que poder distinguir esas cosas.
Cómo ve Timex las herramientas de IA basadas en terminal
Ghostty (y iTerm2, Terminal.app, Warp, Alacritty — la misma idea) publica su título de ventana en macOS de una forma útil. La mayoría de los terminales modernos reflejan el prompt actual del shell o el comando en ejecución en la barra de título. Claude Code, cuando es el proceso activo, fija el título a algo como:
~/Work/dev/muvon/timex — claude-code (Sonnet)
Esa es la fila que Timex guarda. El título de ventana es el discriminador entre "estoy tecleando en un shell" y "Claude Code está corriendo". La misma app, títulos distintos, trabajo muy distinto.
Una consulta SQL contra la base de datos local de SQLite lo hace concreto:
-- Real coding (claude-code in title) vs everything-else terminal time, today
SELECT
CASE WHEN window_title LIKE '%claude-code%' THEN 'Claude Code'
WHEN window_title LIKE '%codex%' THEN 'Codex CLI'
WHEN window_title LIKE '%git%' THEN 'git'
ELSE 'shell' END AS bucket,
SUM(1) AS seconds
FROM activity_samples
WHERE date(ts, 'unixepoch', 'localtime') = date('now', 'localtime')
AND app_name = 'Ghostty'
GROUP BY bucket
ORDER BY seconds DESC;
Puedes ejecutar esa consulta tú mismo contra ~/Library/Application Support/io.muvon.timex/timex.sqlite. La salida para mí el martes pasado fue:
Claude Code 8412 (2h 20m)
shell 5217 (1h 27m)
Codex CLI 408 (7m)
git 188 (3m)
Dos horas y veinte minutos de tiempo de Claude Code. De los cuales había estado conscientemente involucrado en quizá 40 minutos de revisión significativa. Esa brecha — entre el tiempo de reloj gastado en la herramienta de IA y la implicación activa con la herramienta de IA — es la cosa cuyo tamaño la mayoría de los desarrolladores subestiman.
Cursor, el caso del IDE-como-IA
Cursor aparece como su propia app (Cursor), así que es más fácil de ver a nivel de app. Lo más difícil es separar "Cursor con Composer ejecutando un agente" de "Cursor como editor de código". Ambos tienen títulos de ventana que reflejan el archivo actual.
Por ahora, Timex ve Cursor como un solo cubo. La división agente-vs-editor no es algo que el título de ventana exponga de forma fiable (Cursor no actualiza el título con el estado del agente). Si quieres ver ese desglose, tienes que combinar los datos de Timex con las propias estadísticas de uso de Cursor de su panel de ajustes. Puede que añadamos una integración específica de Cursor en la v1.1 — pero solo si hay una API pública limpia desde la que leer, y todavía no la hay.
Codex CLI: la misma idea que Claude Code
El Codex CLI de OpenAI sigue el mismo patrón que Claude Code — corre dentro de un terminal, actualiza el título con el modelo y el directorio de trabajo. La consulta SQL de arriba lo filtra directamente.
Si estás haciendo un test A/B de Claude Code contra Codex CLI (cosa que muchos desarrolladores que conozco están haciendo ahora mismo), aquí es donde los datos se vuelven útiles. Toma el tiempo registrado de la semana pasada, divídelo según qué herramienta estaba activa, y verás algo así:
Claude Code (Sonnet 4.7) — 6h 12m total, 4h actively engaged
Codex CLI — 3h 41m total, 2h 50m actively engaged
"Actively engaged" aquí significa no-ocioso. El ratio de Codex suele ser más alto en mis datos porque Codex tiende a hacer más preguntas de aclaración, lo que te mantiene en el bucle. Las ejecuciones automáticas más largas de Claude Code dejan más margen para que te vayas a la deriva hacia Twitter. Para tareas enfocadas y bien acotadas, eso está bien. Para cualquier cosa abierta, es un lastre.
Las ejecuciones del agente de Octomind
Octomind es otra bestia. Cuando lanzas una ejecución de agente, se va y trabaja en segundo plano mientras tú haces otra cosa. Octomind aparece en Timex como el tiempo que pasaste mirando su dashboard, no el tiempo que el agente estuvo corriendo en algún servidor.
Ese es el comportamiento correcto. Si el agente trabaja de forma autónoma, no consume tu atención. Si estás mirando fijamente el dashboard esperándolo, eso sí es tu atención, y aparece correctamente.
El patrón que se repite una y otra vez en mis datos: el tiempo de dashboard de Octomind se correlaciona casi a la perfección con la ansiedad. Las ejecuciones que reviso cada cinco minutos son las ejecuciones en las que no confío del todo en el prompt. Las ejecuciones que lanzo y me olvido son las que funcionan. Los datos me están enseñando cuándo alejarme.
Las pestañas del navegador y el mito de la "investigación"
El rastreador de pestañas del navegador, cuando le concedes el permiso de Accesibilidad, captura el título de la pestaña activa. Para los desarrolladores este es el feed más interesante de todos.
El martes pasado, mi tiempo de Octoweb (navegador) de 1h 34m se desglosaba más o menos así:
github.com/muvon/... 45m
docs.anthropic.com 18m
news.ycombinator.com 12m
stackoverflow.com 11m
twitter.com (or whatever) 6m
docs.python.org 4m
... long tail ...
Lo que quiero señalar aquí: fíjate en que Hacker News + Twitter + Reddit no son el titular. El titular es GitHub y las docs. La narrativa que me cuento a mí mismo ("el día fue una distracción") no encaja con los datos ("el día fue mayormente productivo con algo de scroll"). Sin los datos a nivel de pestaña, ambas son igual de plausibles. Con ellos, una de las dos es verdad.
La otra cosa que quiero señalar: recorté la cola larga. Hay ahí unos 18 minutos que son puro cambio de contexto — Gmail durante 30 segundos, luego de vuelta a GitHub, luego Notion durante un minuto, luego de vuelta. Ese microcoste es lo que la mayoría de los desarrolladores se pierde al estimar su propio tiempo de concentración. No es la gran pestaña en Twitter — es la docena de comprobaciones de 30 segundos.
El SQL de "qué entregué"
Si solo vas a ejecutar una consulta contra la base de datos de Timex, ejecuta esta:
-- Longest contiguous focused-on-real-coding block in the last 7 days
SELECT
date(ts, 'unixepoch', 'localtime') AS day,
app_name,
window_title,
COUNT(*) AS duration_seconds
FROM activity_samples
WHERE is_idle = 0
AND app_name IN ('Ghostty', 'Cursor', 'Xcode', 'Visual Studio Code', 'Zed')
AND ts > strftime('%s', 'now', '-7 days')
GROUP BY day, app_name, window_title
HAVING duration_seconds > 600
ORDER BY duration_seconds DESC
LIMIT 20;
Eso te da las 20 sesiones de programación enfocada de más de 10 minutos más largas de la última semana, agrupadas por en qué estabas trabajando realmente (título de ventana). La salida es brutalmente honesta. La semana en la que me sentí productivo pero la consulta volvió con solo 6 sesiones de más de 10 minutos fue la semana que tuve que admitir que en realidad fue una semana cargada de reuniones con la ilusión de concentración.
Lo que los desarrolladores de verdad quieren saber
Mi percepción está calibrada contra los días que tenía antes de Claude Code, cuando "en el editor durante 6 horas" significaba "escribí código durante 6 horas". Por eso vuelvo una y otra vez a los datos en lugar de fiarme de ella. Así ya no funciona el flujo de trabajo. "En el editor durante 6 horas" podría significar:
- 2 horas de Claude Code supervisado que produjeron 700 líneas
- 1 hora de deriva sin supervisión mientras Claude Code estaba corriendo
- 1,5 horas de revisión de código y ediciones
- 30 minutos de pelea con git
- 1 hora de cambio de contexto para volver al trabajo
La primera y la tercera son las partes que producen código entregado. La segunda es la parte que tiene que bajar. Los datos me muestran cuál es cuál. Mi percepción por sí sola no puede.
Los límites honestos
Unas cuantas cosas que este tipo de rastreador no puede contarte:
No puede medir la calidad de lo que se entregó. 4 horas de Claude Code y una PR limpia es genial. 4 horas de Claude Code y una PR que hay que reescribir el sprint que viene es un impuesto. El rastreador solo ve el tiempo, no el resultado.
No puede ver el trabajo que ocurre en tu cabeza. La media hora paseando por el apartamento pensando en la arquitectura, antes de sentarte y escribir lo correcto — eso no está en los datos. Los datos ven "loginwindow + idle". Te equivocarías al leer eso como "desperdiciado".
No puede categorizar sin pistas del título de ventana. Si el prompt de tu shell no muestra qué herramienta está corriendo, Timex ve "Ghostty" y nada más. La granularidad es función de los datos que tus herramientas exponen.
Lo que sí puede hacer es darte la imagen más precisa que es posible actualmente de cómo se desglosa realmente el día de un desarrollador — incluyendo las partes que no quieres ver, como los 27 minutos en Twitter mientras Claude Code estaba trabajando.
Si usas alguna de Claude Code, Codex CLI, Cursor u Octomind — y te gustaría ver cómo es tu día real a través de estas herramientas — hazte con la prueba. La franja de color es honesta de una forma difícil de rebatir.