Cómo trabajo con agentes de código hoy

Hace unos meses empecé a usar agentes para el laburo de código. No como un copiloto que me sugiere líneas, sino como un equipo que trabaja mientras yo no estoy. Pero hay algo que aprendí rápido: los agentes no reemplazan al driver. Te liberan para ser un mejor driver.

La división es así. Para el laburo de grind, tareas bien definidas, cambios repetibles, reviews automáticos, los agentes corren solos. Para los caminos críticos, las decisiones de arquitectura, las cosas que importan de verdad, sigo siendo yo el que maneja. Uso Cursor, Codex, o Claude Code, pero al volante estoy yo. Lo que cambió no es quién hace el trabajo. Es cuánto laburo pesado puedo delegar sin perder el control de lo que sale.

El flujo

Las tareas viven en Linear. Cuando una issue está lista para que la agarre un agente, le pongo el label “Ready For Claw”. Esa es la señal de largada.

El que orquesta todo es OpenClaw, corriendo un heartbeat periódico. Cada tick mira Linear. Si hay tareas “Ready For Claw”, arranca el coder. Si hay PRs en “In Review”, arranca el reviewer. Sin heartbeat no pasa nada. Es el scheduler real que conecta las piezas.

El coder es Cursor CLI corriendo headless en el repo. Levanta la tarea, lee el contexto, y se pone a laburar. Cuando termina, corre lint, typecheck y tests. Si pasan, abre un PR y mueve la issue a “In Review”. Si fallan, deja registro de qué rompió y la deja en “In Progress” para el próximo intento. El agente no decide si terminó. Lo decide la suite de tests.

El reviewer es la misma herramienta con otro modelo y otro prompt. Lee el diff, lee las notas de la tarea, y busca bugs, problemas de arquitectura, lógica rota. No nits de estilo. Si encuentra algo, kickbackea la tarea al coder con los findings. Si no, la deja lista para mi approval. Hay dos reglas de seguridad. Después de tres kickbacks sin resolución me avisa y para. Y ante cualquier duda, no solo el límite de kickbacks, también me avisa. El agente no adivina cuando no está seguro.

Todo el estado persistente vive en mi vault de Obsidian personal, en una carpeta Agent Notes/ al lado del proyecto, no adentro del repo de código. Eso me importa. El contexto vive junto al proyecto, no embebido, y lo navego con graph view, backlinks y search como cualquier otra cosa en mi vault. La estructura:

Agent Notes/
  tasks/LINEAR-ID.md    ← historial por tarea
  runs/YYYY-MM-DD.md    ← log diario de qué corrió
  decisions/adr-NNN.md  ← decisiones arquitectónicas

Cada tarea tiene su nota con el historial de intentos y findings. Cada día tiene su run log con qué se ejecutó, qué pasó, cuánto tardó. Las decisiones grandes quedan como ADRs. Los agentes son amnésicos por naturaleza. El filesystem no.

Y hay dos canales de output que no hay que confundir. Las notas de Obsidian son contexto detallado para el próximo agente, machine-readable. Los comentarios de Linear son resúmenes para mí, human-readable. Cada acción del agente escribe en los dos.

Mi parte es la de siempre. Reviso los PRs que el reviewer aprobó, mergeo lo que está bien, manejo los casos ambiguos. Y para todo lo que es camino crítico me siento a laburar yo directamente con Claude Code, Cursor o Codex. El agente maneja el grind. Yo manejo el juicio.

Por qué funciona

Tres cosas que lo sostienen.

Persistencia. Los agentes olvidan todo al terminar una sesión. El sistema no. Cada intento queda escrito: qué se hizo, qué falló, qué decidió el reviewer. El próximo agente arranca con contexto real, no desde cero.

Verificación externa. El agente no se autoasigna el “listo”. Los tests, el lint, el typecheck son los que dicen si el trabajo está bien. Sin esa señal externa, los agentes shipean con confianza total aunque el código esté roto.

División de responsabilidades. El coder codea, el reviewer revisa, yo apruebo. Cada uno tiene un rol claro y no se pisa con el otro. El reviewer nunca reescribe, solo reporta. Yo nunca mergeo sin pasar por el flujo, aunque pueda.