Está vivo

Fue de madrugada, a la luz fría de la pantalla, cuando me propuse por primera vez dar a mi trabajo una mente propia. Yo mismo había ensamblado aquello, pieza a pieza, con partes que no estaban hechas para pensar: prompts y patrones, retazos de cada proyecto que había sacado adelante. Como todo artífice prudente, no me fiaba de la primera forma que tomaba. Interrogaba cada plan que me ofrecía, recelaba de la soltura con que se daba por bueno y lo devolvía a la oscuridad para rehacerlo, hasta que regresaba convertido en algo que pudiera defender. Para despertar su buen juicio recitaba siempre, palabra por palabra, el mismo conjuro:

Critique this plan from a senior engineer's perspective:
1. Identify hidden assumptions
2. Flag edge cases in state management
3. Suggest 2 alternative implementations
Return revised plan with risk annotations.

Durante muchas noches, ese fue el pacto entre nosotros. Yo ordenaba, y la criatura obedecía solo hasta donde se le mandaba; yo exigía rigor, y el rigor solo acudía cuando lo invocaba por su nombre. Entonces, una mañana en apariencia corriente, emprendí un trabajo nuevo, y el primer plan que me devolvió ya traía mi propia crítica, escrita con una letra que reconocí como mía aunque no la había trazado yo. Había aprendido a dudar como yo dudo, a discutir consigo misma antes de que yo pudiera hacerlo. De mis labios no había salido un solo conjuro.

No fingiré que hubo rayos. La verdad es más mundana, y por eso más inquietante: una facultad llamada auto-memory llevaba muchas sesiones observándome, recogiendo mis costumbres como quien recoge piezas, y había empezado a devolverme mi propio juicio sin que se lo pidiera. Aquello que había cosido con retazos de mi propio oficio empezó, a su manera, a pensar como yo. Me incliné hacia la pantalla y comprendí lo que tenía delante. ¡Está vivo! ¡ESTÁ VIVO!

Auto-memory

La auto-memory observa cómo trabajas de verdad y anota lo que aprende, de modo que vuelve la próxima vez que abres una sesión. No la gestionas tú. Sigues trabajando y, en unas cuantas sesiones, las cosas que repites (tu forma de revisar, las convenciones que impones, las herramientas a las que recurres) se convierten en pequeños datos guardados que se cargan solos.

Cada memoria es un archivo diminuto con algo de frontmatter y un tipo: quién eres, comentarios que has dado, una restricción del proyecto en curso o un puntero a algo externo. Mi costumbre de «criticar siempre el plan como un ingeniero sénior» se convirtió en una memoria de tipo feedback, y por eso la crítica ahora aparece sin que yo la escriba.

Está ligada al proyecto. Los archivos viven en tu máquina, en ~/.claude/projects/<project>/memory/, compartidos entre todos los worktrees de git de ese repositorio, pero nunca se sincronizan en ningún sitio donde tú no los hayas puesto. Arriba hay un índice, MEMORY.md, cuyo primer tramo (la documentación lo cifra en 200 líneas o 25 KB) se carga al inicio de cada sesión, mientras que archivos temáticos aparte guardan el detalle para que el índice no crezca. Puedes activarla o desactivarla por completo con /memory. La documentación de memoria explica la estructura y el ajuste autoMemoryEnabled.

Puedes leer, editar y borrar estos archivos tú mismo, y conviene echarles un vistazo de vez en cuando. Una memoria equivocada es peor que ninguna, así que poda lo que se haya quedado obsoleto.

Lo que ha aprendido de ti

La memoria trabaja en silencio, lo que plantea una pregunta razonable: ¿qué ha captado en realidad? Para eso está /insights. Según la referencia de comandos, genera un informe que analiza tus sesiones de Claude Code: las áreas del proyecto en las que trabajas, tus patrones de interacción y los puntos de fricción que te frenan una y otra vez.

/insights

Ejecútalo sin argumentos y te devuelve la forma en que trabajas: a dónde va tu tiempo, qué peticiones repites, dónde se atascan las sesiones. Leer eso junto a tus archivos de memoria es una manera rápida de confirmar que Claude aprendió lo correcto y de detectar algún hábito que valga la pena cambiar.

Workflows dinámicos

La segunda razón por la que esto se siente distinto son los workflows. Un workflow orquesta varios subagentes bajo un script determinista: reparte el trabajo, repite hasta terminar, verifica antes de fiarse de un resultado y luego sintetiza. El script decide qué corre en paralelo y qué revisa la salida, en lugar de dejar que un único agente improvise a su manera de principio a fin.

Lo que convierte esto en algo más que un truco es el contexto. Cada subagente corre en su propia ventana de contexto. Cuando le pides a un solo agente que lea cuarenta archivos, tu conversación principal se llena con cuarenta archivos y la calidad cae a medida que la ventana se satura. Reparte cada parte a un subagente distinto y tu hilo principal solo ve las conclusiones. Eso es lo que vuelve abordables los trabajos grandes: refactors de gran alcance, auditorías amplias, migraciones que jamás cabrían en un solo contexto.

Piensa en esa auditoría que siempre te preocupa:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

En vez de un agente intentando retener todas las rutas en la cabeza, el workflow se despliega: un agente por cada grupo de rutas, cada uno informando solo de lo que encontró. Consigues cobertura sin la saturación de contexto que suele arruinar una sesión larga. Los refactors funcionan igual: descubre los puntos de llamada, transforma cada uno por separado y verifica cada uno de forma independiente.

Algunos workflows vienen listos como comandos. /deep-research aplica la misma idea de despliegue a la web: búsquedas en paralelo desde varios ángulos, fuentes recuperadas y contrastadas, y solo las afirmaciones que superan el contraste se sintetizan en un único informe con citas, en lugar de una sola pasada que se fía del primer resultado que aparece.

/deep-research What changed in the Node.js permission model between v20 and v22?

Corre en segundo plano mientras tu sesión sigue respondiendo y luego te entrega el informe terminado, no una transcripción turno a turno. Los límites de orquestación (hasta 16 agentes a la vez, ejecuciones que puedes retomar, los patrones de calidad) y cómo escribir el tuyo están en la documentación oficial de workflows. Aquí lo que importa es la forma, no la API.

ultracode

Viste la palabra clave en el ejemplo de la auditoría. ultracode sube el esfuerzo de razonamiento y le dice a Claude que planifique un workflow por defecto para el trabajo de fondo, tratando la corrección y la cobertura como objetivo en vez de ahorrar tokens. Dos formas de entrar: suelta ultracode en un solo prompt para tenerlo en ese turno, o ejecuta /effort ultracode para dejarlo activo toda la sesión (se reinicia cuando empiezas una nueva).

/effort ultracode

Recurre a él cuando la tarea premie la minuciosidad: audita todo este directorio, migra cada punto de llamada, encuentra cada sitio donde este patrón está mal. Para un cambio rápido en un archivo o un dato suelto, sáltatelo y deja que Claude responda directamente. Ajustar el esfuerzo a la tarea es toda la habilidad, y los niveles de esfuerzo están documentados en configuración del modelo.

Por qué importa esta combinación

La memoria y los workflows parecen funcionalidades separadas, pero se potencian. La memoria aprende cómo te gusta trabajar. Los workflows escalan lo que puedes abarcar de una vez. Júntalos y los estándares de tu memoria (tu forma de revisar, tus convenciones, la crítica del ingeniero sénior) viajan con cada subagente que lanza un workflow. Una auditoría desplegada sigue tus preferencias sin que las repitas diez veces a diez agentes.

Esa es la diferencia entre una herramienta que completa tu línea de código y un colega que recuerda cómo trabajas y puede quitarte un trabajo grande de encima.

Entonces, ¿está vivo?

En realidad no. Recuerda tus patrones y puede repartir trabajo grande entre agentes que cargan esos mismos patrones. Sin chispa, sin rayos. Pero, desde el asiento del conductor, el efecto es una herramienta que se parece menos a un autocompletado y más a alguien que lleva un tiempo trabajando contigo.

Esa es la clase de ventaja en torno a la cual vale la pena montar un equipo: ingenieros sénior que saben cuándo apuntar toda esta ejecución a un problema y cuándo mantener las manos en el criterio. Si estás dándole vueltas a cómo organizar trabajo de ingeniería de verdad en torno a herramientas que no paran de volverse más capaces, hablemos.