Una lista de tareas no es un plan de ejecución

A los proyectos de software rara vez les falta una lista de tareas. Jira, una hoja de cálculo, un archivo Markdown, la foto de una pizarra que nadie puede leer una semana después. Lo que suele faltar es un plan de ejecución. Durante mucho tiempo funciona porque el plan está en la cabeza de las personas. Alguien simplemente sabe que la integración de pagos no puede empezar antes de estabilizar el modelo de pedidos y que «listo» significa que se comprobaron los números.

Los agentes hacen visible esa carencia. Un agente no absorbe el plan no escrito en las conversaciones de pasillo. Recibe lo que le das, y una lista de tareas es sorprendentemente poco.

Lo que una lista no dice

Una lista de tareas responde a una pregunta: ¿qué tiene que pasar? Un plan de ejecución debe responder a varias más:

• Orden. ¿Qué depende de qué y qué puede ejecutarse en paralelo?
• Entradas. ¿Qué necesita saber este trabajo antes de empezar: qué decisión, qué contrato, qué archivos?
• Salidas. ¿Qué produce que consumirá otro trabajo?
• Listo. ¿Qué evidencia demuestra que terminó y quién o qué la comprueba?

Con personas, gran parte se negocia conversando. Con agentes, lo negocia quien distribuye el trabajo: normalmente yo, copiando contexto entre sesiones e intentando recordar qué rama esperaba a cuál. Esa es la parte que intento hacer explícita.

La dirección con la que estoy experimentando

El flujo que estoy explorando en mis proyectos es así:

producto, recorridos y pantallas → PRD → especificación técnica → grafo de ejecución → trabajo de los agentes → verificación → integración

Los primeros pasos son trabajo normal de producto y arquitectura, y siguen siendo decisiones humanas. El paso interesante está en medio: convertir una especificación aprobada en un grafo donde cada nodo es una unidad de trabajo con sus dependencias, el contexto que puede ver, lo que debe producir y los criterios que debe cumplir.

Este es un ejemplo conceptual. Ilustra la forma; no es un archivo de un sistema en funcionamiento:

- id: order-status-api
  depends_on: [order-model]
  context: [tech-spec#orders, decisions/0007-status-names]
  produces: [GET /orders/{id}/status]
  done_when:
    - contract tests pass
    - status names match the decision record

- id: status-notifications
  depends_on: [order-status-api]
  context: [tech-spec#notifications]
  produces: [notification on status change]
  done_when:
    - integration test covers the status → notification path

No hay nada sofisticado aquí. Lo importante es que las relaciones, los límites y la definición de terminado estén en algo que una herramienta pueda leer, en lugar de en mi memoria. Eso es lo que llamo ingeniería de grafos en este contexto: hacer explícitas las relaciones y el estado de ejecución. El término también se usa de otras formas. LangChain lo usa para construir agentes como grafos de nodos y aristas; no se trata de una disciplina nueva, GraphRAG ni una base de datos de grafos.

Tres grafos, tres preguntas

Algo que confundía mis propias notas: no existe un grafo. Hay al menos tres y responden a preguntas distintas.

• Un grafo de funcionalidades pregunta: ¿qué necesita el producto y qué capacidades se apoyan en otras?
• Un grafo de dependencias de proyectos pregunta: ¿qué partes del código dependen de cuáles? Nx, por ejemplo, construye un grafo de proyectos a partir del repositorio y un grafo de tareas al ejecutarlas, y los usa para determinar qué afecta un cambio.
• Un grafo de ejecución pregunta: ¿qué trabajo viene después, con qué contexto y cómo sabemos que terminó?

Mezclarlos produce planes que parecen rigurosos y no responden bien a ninguna pregunta. Una funcionalidad puede tocar cinco proyectos; una tarea puede existir solo para verificar otra.

Cuándo no usar un grafo

Sinceramente, la mayor parte del tiempo.

Si el trabajo son tres pasos, una persona y una tarde, una lista de comprobación es la herramienta adecuada. Un grafo tiene un coste: alguien debe escribirlo, mantenerlo alineado con la realidad y decidir qué ocurre cuando está equivocado. Si el plan cambia cada hora, un grafo se convierte en una forma muy estructurada de estar desactualizado.

Las situaciones en las que creo que compensa son más concretas:

• cuando el trabajo se divide entre varios agentes o sesiones y nadie tiene la visión completa;
• cuando las dependencias son reales y equivocarse sale caro;
• cuando «listo» requiere evidencia, no una casilla marcada.

Lo estoy probando en mis proyectos y aún no sé dónde está la línea entre una estructura útil y un segundo producto que mantener. Seguiré escribiendo sobre esta pregunta: ¿cuándo resuelve un grafo la coordinación real y cuándo basta una lista simple?