La segunda regla fundamental para trabajar con agentes de IA: dividir una solicitud grande en una granularidad menor, con verificación tras cada paso, produce mejores resultados que un único prompt gigante.
Si se intenta una funcionalidad nueva grande, es mejor dividirla en Tasks más pequeñas, por varias razones.
Una de las cosas más importantes que mencionar es cómo se comporta el coste del desarrollo de software a lo largo del tiempo. El libro Code Complete tiene un conocido gráfico que muestra cuánto más cara resulta la corrección de un bug según la fase de desarrollo en que se detecte: durante el análisis el coste es casi cero, pero una vez que el software está en producción en casa del cliente, el coste es un orden de magnitud superior, o más. Con la velocidad a la que la IA genera código hoy, hay que tener aún más cuidado en diseñar la arquitectura por adelantado, porque la refactorización es justamente lo que la IA no gestiona especialmente bien. El mejor enfoque es ceñirse a los estándares descritos en los libros de código limpio y usar patrones consolidados para la estructura y la lógica de negocio: los libros son una de las fuentes de mayor calidad de las que un modelo de IA aprendió las buenas prácticas durante el entrenamiento, por lo que es lo que mejor entiende. Para la IA también es importante mantener el código dividido en capas claras, incluso en un monolito: así el agente se orienta mucho más fácilmente por el código.
Volvamos a cómo dividir correctamente las Tasks. Supongamos que la Task es: construir un nuevo formulario de satisfacción del cliente. ¿Qué fases harán falta?
- UI — el formulario, sus campos y el evento de envío.
- Lógica de negocio — validación del formulario, vinculación de la solicitud a la cuenta del cliente, prioridad de la solicitud.
- Estructura de datos — cómo viajan los datos al BE y de vuelta al FE.
- BE — validación y lógica de negocio de nuevo, ahora en el lado del backend.
- Capa de datos — mapeo de la estructura de datos a la base de datos.
- Persistencia de los datos, más la estructura correspondiente que fluye de vuelta del BE al FE.
Para la IA no importa realmente por dónde se empiece; lo que importa es describir correctamente cada paso. Para la persona usuaria, lo más práctico es empezar o bien por la base de datos o bien por el frontend.
Con eso quedan cubiertas todas las Tasks. La pregunta ahora es: ¿cuál es la diferencia entre una Task grande y varias más pequeñas?
Con una sola Task, la ventaja es un contexto compartido (caché) entre pasos: el agente nunca tiene que volver a buscar nada. Pero a lo largo de más turnos, esa ventaja se invierte: cuanto más tiempo se permanece en un mismo contexto, más tokens se reenvían y se reprocesan en cada turno posterior, de modo que el coste por turno sigue creciendo con el tamaño del contexto; en una Task larga y de muchos turnos, eso puede sumar una cantidad apreciable.
Si en cambio se dividen las Tasks, la IA solo hace su parte concreta, que puede probarse de forma independiente al final, detectando errores incluso antes de empezar a trabajar en la siguiente parte. Se consumen menos tokens en total, y poder verificar cada paso de forma independiente permite detectar alucinaciones o desviaciones del requisito mucho antes que tras terminar una única Task gigante. Las Tasks más pequeñas tampoco exigen al modelo mantener la atención en cada detalle a la vez.
¿Por qué importa tanto esto a los modelos de IA? Tienen una capacidad limitada para mantener la prioridad entre un gran número de instrucciones a la vez. Si se escribe "añade una funcionalidad nueva, refactoriza la lógica antigua y corrige tres bugs relacionados" en un único prompt, el modelo construye su propio orden de prioridad, que podría no coincidir con el deseado. El resultado: una parte de la Task se hace de forma brillante, otra se queda corta, y nadie lo nota hasta que se rompe en producción.
Esta es exactamente la razón por la que AITM divide las solicitudes grandes en Tasks encadenadas en lugar de dejar que se ejecuten como una sola pasada continua.
Cómo se ve esto en la práctica: un chat de IA normal frente a AITM
Un agente de IA normal (chat/copiloto de IDE): se le da un prompt largo y el agente se pone a trabajar en un único contexto continuo. Si se equivoca en un detalle al 80 % del camino, no se descubrirá hasta revisar todo el diff, mientras tanto el trabajo sobre los puntos posteriores siguió avanzando sobre una base rota.
AITM: la misma solicitud se divide en Chat/Brainstorm en llamadas de Task encadenadas e independientes con dependencias: la Task B solo puede empezar cuando la Task A ha recorrido toda la Pipeline y se ha fusionado. Si la Task A falla en la revisión o en las pruebas, la Task B no arranca sobre una base rota: espera. Entretanto, el Watchdog evalúa por sí mismo el fallo de la Task A: si puede analizar el error y proponer una corrección, la Task se reinicia automáticamente con un prompt que describe exactamente ese error y la corrección propuesta; si el error no está claro o no se puede resolver sin una decisión humana, la Task se detiene y espera a que la persona usuaria decida cómo debe proceder. Además, tras fusionarse la última Task de la cadena, se ejecuta un paso Chain-audit: una comprobación final determinista (no de IA) que revalida los Contracts afectados por toda la cadena.
La diferencia que ve la persona usuaria: con un agente normal, al final se obtiene un diff grande y opaco. Con AITM, se obtienen varias Tasks más pequeñas, con nombre, comprobadas de forma independiente y con su propio historial, y se sabe exactamente dónde falló algo si no salió según lo previsto.