Productivity

En EP.2, usé hooks para reducir lo que Claude lee. Los resultados de tests solo mostraban fallos, los logs de build solo errores. Decidí medir cuánto había reducido realmente. Primero medir Claude Code registra todas las conversaciones como archivos JSONL. Se acumulan por proyecto bajo ~/.claude/projects/, cada entrada contiene el uso de tokens. Construí un script (analyze-tokens.js) que lee estos datos, los cruza con archivos de sesión diarios, contabiliza turnos, cache_read/write/output por separado y lo convierte todo a costo. ...

Ahora tengo 5 proyectos. shop, blog, code_dungeon, good_game, y un root que los gestiona a todos (ese no es su nombre real). Cada proyecto corre su propia sesión de Claude. El problema es que yo soy uno solo. Si lanzo una tarea en shop y me paso a editar un borrador en blog, no sé cuándo terminó shop. Si inicio Phase 1 en code_dungeon y me voy a ver good_game, code_dungeon podría estar esperando confirmación de permisos y no me entero. Mirar 5 terminales en rotación no es monitoreo. Es solo dolor de ojos. ...

Después de reducir a 9 agentes y poner CLAUDE.md a dieta, los intervalos entre Compacting conversation... se alargaron notablemente. Las mismas tareas, pero aguantaba mucho más que antes. Me sentí bien. Entonces estaba viendo la consola después de pedir una nueva funcionalidad. Los tests corrieron. 30 casos, todos pasaron. Pero Claude estaba mencionando los tests exitosos otra vez. Algo se sentía raro. Le pregunté a Claude. “¿Por qué mencionas otra vez los tests que ya pasaron?” Claude me explicó el concepto de herramientas. Cuando Claude ejecuta un comando de terminal o lee un archivo, todo eso son “llamadas a herramientas”. Y cada vez que una herramienta se ejecuta, su resultado completo se apila en el contexto de la conversación. Resultado de npm test — 30 líneas. Log de Hugo build — 180 líneas. Todo. Los tests pasaron todos sin nada que ver, pero leyó los 30. Para arreglar errores de build, solo necesitaba las últimas 5 líneas, pero cargó las 180. ...

Un amigo me pidió que le construyera una tienda online de cosméticos. En el trabajo solo escribía C, así que era una oportunidad para probar un stack nuevo. Toss Payments para pagos, React para el frontend. “Todos los proyectos de nueva generación en finanzas están yendo a React” — eso me rondaba la cabeza, y Toss Payments era amigable con Node. La dirección se definió rápido. Obviamente, nunca había usado este stack. Tenía ganas, pero el plazo no daba para “estudiar primero, construir después”. Así que probé el vibe coding. ...