Cómo trabajo con agentes de código hoy

Hace unos meses empecé a usar agentes para el laburo de código. Un agente es un programa que le da una tarea a un modelo de IA y lo deja trabajar solo: lee el código, lo cambia, corre las pruebas. No lo uso como un copiloto que me sugiere líneas mientras escribo, sino como un equipo que trabaja mientras yo no estoy. Hay algo que aprendí rápido: los agentes no reemplazan al que maneja, lo liberan para manejar mejor.

La división es así. El laburo de grind, el pesado y repetitivo, lo hacen los agentes solos: tareas bien definidas, cambios parecidos entre sí, revisiones automáticas. Los caminos críticos los sigo manejando yo: las decisiones de arquitectura, las cosas que importan de verdad. Ahí uso Cursor, Codex o Claude Code, tres herramientas para programar con IA, pero al volante estoy yo. Lo que cambió es cuánto laburo pesado puedo delegar sin perder el control de lo que sale.

El flujo

Las tareas viven en Linear, la herramienta donde anoto y ordeno el trabajo pendiente. Cada tarea es una issue. Cuando una está lista para que la agarre un agente, le pongo la etiqueta “Ready For Claw”. Esa es la señal de largada.

El que orquesta todo es OpenClaw, un agente que corre de fondo con un heartbeat, un latido periódico: cada tanto se despierta y mira Linear. Si hay tareas “Ready For Claw”, arranca el coder, el agente que escribe código. Si hay PRs en “In Review”, arranca el reviewer, el agente que revisa. Un PR es una propuesta de cambio al código, lista para que alguien la revise antes de que entre. Sin ese heartbeat no pasa nada: es el reloj que pone en marcha todo lo demás.

El coder es Cursor CLI, la versión de Cursor que se maneja desde la terminal escribiendo comandos. Corre headless, sin ventana ni editor abierto, adentro del repo. Levanta la tarea, lee el contexto, y se pone a laburar. Cuando termina, corre los tres chequeos automáticos del repo. El lint busca errores comunes y de formato, el typecheck verifica que los tipos de datos cierren y los tests prueban que el código hace lo que tiene que hacer. 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 que decide si terminó no es el agente: son los tests.

El reviewer es la misma herramienta con otro modelo de IA y otro prompt, las instrucciones que recibe al arrancar. Lee el diff, las líneas exactas que cambiaron, lee las notas de la tarea, y busca bugs, problemas de arquitectura, lógica rota. No detalles de estilo. Si encuentra algo, kickbackea la tarea al coder: se la devuelve con la lista de lo que encontró. Si no, la deja lista para que yo la apruebe. Hay dos reglas de seguridad. Después de tres kickbacks sin resolver, me avisa y para. Y ante cualquier duda, no solo cuando llega al límite de kickbacks, también me avisa. El agente no adivina cuando no está seguro.

Todo el estado persistente, lo que tiene que sobrevivir de una corrida a la siguiente, vive en mi vault de Obsidian personal. Obsidian es la aplicación donde tomo notas, y el vault es la carpeta con todas ellas. Las notas de los agentes van 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 como cualquier otra nota: con la vista de grafo, los backlinks (qué notas apuntan a esta) y la búsqueda. 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 de lo que encontró el reviewer. Cada día tiene su run log, un registro de qué se ejecutó, qué pasó y cuánto tardó. Las decisiones grandes quedan como ADRs, notas cortas que dicen qué se decidió y por qué. Los agentes son amnésicos por naturaleza. Los archivos en disco no.

Y hay dos canales de salida que no hay que confundir. Las notas de Obsidian son contexto detallado para el próximo agente, escritas para que las lea una máquina. Los comentarios de Linear son resúmenes para mí, escritos para que los lea una persona. 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 (lo integro al código principal) y 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 pone el grind y yo pongo 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 y 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.