Hoy en día, el desarrollo de software asistido por IA suele seguir un proceso sencillo:
Escribir una descripción de la tarea (prompt).
Dejar que la IA produzca un análisis y una propuesta de solución.
Preparar skills, agentes y subagentes.
Iniciar la implementación.
Dejar que la IA escriba el código, lo pruebe y corrija los problemas detectados.
A primera vista, parece un flujo de desarrollo ideal. La IA opera de forma autónoma, reparte las tareas entre agentes, escribe pruebas y va completando poco a poco la funcionalidad solicitada.
Y para proyectos pequeños, este enfoque puede funcionar extremadamente bien.
Si estás construyendo una tienda online sencilla, un sitio web corporativo de cinco páginas o un sistema de administración básico, la IA suele poder encargarse de buena parte del trabajo con muy buenos resultados.
¿Por qué?
Porque millones de desarrolladores ya han construido software parecido.
Imagina dos tiendas online. Una vende juguetes y la otra vende manzanas.
Desde la perspectiva del cliente, son dos negocios distintos. Desde la perspectiva de la arquitectura de software, sin embargo, funcionan de manera muy similar:
Productos organizados en categorías.
Gestión de precios e inventario.
Carritos de compra.
Procesamiento de pedidos.
Métodos de pago.
Gestión de clientes.
Lo que cambia son sobre todo los datos, las reglas de negocio específicas y ciertas funcionalidades. Los principios arquitectónicos básicos siguen siendo en gran medida los mismos.
La IA reconoce estos patrones porque se encontró con estructuras parecidas durante el entrenamiento.
El problema empieza cuando dejas de construir una aplicación convencional y empiezas a desarrollar software empresarial a gran escala.
¿Qué ocurre cuando un sistema contiene entre 300 000 y 500 000 líneas de código?
Imagina una aplicación empresarial con cientos de miles de líneas de código, decenas de módulos, cientos de dependencias y reglas de negocio complejas.
Un sistema así puede haber evolucionado durante varios años. En ese tiempo se han ido acumulando decisiones de arquitectura, excepciones, dependencias históricas y reglas de negocio.
No todas están documentadas.
Un solo método puede afectar a otros diez módulos. Cambiar un parámetro puede romper la facturación, los permisos de usuario o el procesamiento de pedidos.
Ahora imagina introducir un agente de IA en este entorno.
Le das una tarea:
"Modifica el proceso de pago para admitir un método de pago adicional. Conserva la compatibilidad con versiones anteriores y prueba todo."
El agente crea un plan, reparte el trabajo entre subagentes, implementa los cambios, ejecuta las pruebas y devuelve los resultados.
Todo puede parecer correcto.
Pero que las pruebas pasen no significa necesariamente que el software haya conservado todas las reglas de negocio existentes.
Y esto nos lleva al problema que cambió por completo mi enfoque de los agentes de IA hace seis meses.
El experimento que cambió mi visión de los sistemas agénticos
Hace seis meses realicé un experimento que me llevó a tomar un camino distinto en lugar de limitarme a construir más agentes y subagentes.
Hasta entonces, trabajaba con una suposición compartida por muchos desarrolladores:
Cuanto mejor reparta las tareas entre agentes especializados y cuantos más mecanismos de validación introduzca, más fiable será el resultado.
Pero durante mis experimentos me topé con una pregunta fundamental:
¿Cómo puede un agente implementar correctamente una regla de negocio si ni siquiera sabe que esa regla existe?
¿Y cómo puede otro agente verificar de forma fiable el resultado si tampoco dispone de información completa sobre cómo se supone que debe comportarse el sistema?
Empecé a examinar cómo se transfiere el contexto entre agentes.
Lo que descubrí fue que la forma en que se transmite y se interpreta la información puede convertirse en uno de los puntos más débiles de todo el proceso.
¿Cómo funcionan realmente los agentes y subagentes?
En la práctica, hay dos enfoques habituales para la comunicación entre agentes de IA.
1. Modelo jerárquico: un agente principal coordina a los subagentes
Esta arquitectura se conoce comúnmente como Hub-and-Spoke o topología en estrella.
El principio es sencillo:
El usuario envía una tarea al agente principal.
El agente principal analiza la tarea y la divide en partes más pequeñas.
Crea o activa el subagente A y le da instrucciones.
El subagente A realiza el trabajo y devuelve un resultado.
El agente principal evalúa el resultado y puede delegar más trabajo al subagente B.
Una vez completadas todas las partes, el agente principal combina los resultados.
El subagente A no sabe necesariamente qué está haciendo el subagente B. La comunicación y el intercambio de información se coordinan a través del agente principal.
Ventaja: control centralizado, seguimiento del estado más sencillo, responsabilidades más claras y menor riesgo de comunicación descontrolada entre agentes.
Desventaja: el agente principal se convierte en el punto central por el que se interpretan las instrucciones y los resultados de las tareas. Si omite información importante al delegar el trabajo, un subagente puede operar con un contexto incompleto.
2. Peer-to-Peer: los agentes se comunican entre sí
El segundo enfoque implica una comunicación directa o continua entre agentes, por ejemplo mediante un hilo de conversación compartido o un sistema de mensajería (*Message Bus*).
Imagina el siguiente escenario:
El agente A escribe código y publica un evento CodeWritten.
El agente B, responsable de las pruebas, recibe el evento y lanza los tests.
El agente C prepara la documentación al mismo tiempo.
Los agentes intercambian resultados continuamente y reaccionan a los cambios.
Ventaja: ejecución de tareas en paralelo, intercambio rápido de información y menor dependencia de un único agente central.
Desventaja: coordinación más compleja, riesgo de trabajar con información desactualizada, modificaciones en conflicto y mayor dificultad para rastrear la causa raíz de los errores.
Ambos enfoques pueden ser extremadamente útiles.
Pero ninguno resuelve por sí solo el problema fundamental.
Un agente puede tener una tarea perfectamente definida, pero sin entender la lógica de negocio real del sistema, puede producir una solución técnicamente correcta que es errónea desde el punto de vista del negocio.
¿Dónde surgen los errores en los flujos agénticos?
La IA no es un compilador determinista que traduce instrucciones directamente en código fuente. Un modelo de lenguaje interpreta la información disponible y genera soluciones a partir de ese contexto.
Cuando falta información, puede hacer suposiciones incorrectas. Cuando la información disponible es incompleta o contradictoria, puede elegir un enfoque inadecuado.
Veamos un flujo de trabajo típico para una tarea más grande.
Paso 1 - Interpretar el prompt del usuario
El agente principal recibe la tarea e intenta entender el cambio solicitado.
En esta fase puede pasar por alto una dependencia, malinterpretar una restricción o dar por supuesto algo que nunca se dijo explícitamente.
Paso 2 - Crear instrucciones para un subagente
El agente principal crea una descripción de tarea más específica. Selecciona de entre la información del prompt original la que considera relevante.
Sin embargo, si no conoce ciertas reglas de negocio, no puede transmitirlas correctamente.
Paso 3 - Implementación
El subagente recibe sus instrucciones, analiza una parte de la base de código y elige una estrategia de implementación.
Puede producir código sintácticamente correcto y de buena calidad, y al mismo tiempo cambiar sin querer un comportamiento que debía permanecer intacto.
Paso 4 - Evaluar el resultado
El agente principal recibe la salida del subagente, la evalúa y decide si la tarea está completa.
Pero puede seguir operando con las mismas suposiciones incompletas de antes.
Paso 5 - Pruebas y corrección de errores
Siguen las pruebas unitarias, las pruebas de integración, las pruebas E2E, el análisis estático y las revisiones de documentación.
Estos mecanismos mejoran de forma notable la fiabilidad del software, pero tienen limitaciones.
Una prueba verifica un comportamiento esperado concreto. Si una regla de negocio importante falta en la especificación de la prueba, la implementación puede pasar todas las pruebas y aun así violar esa regla.
Y cuando la IA corrige un problema, puede afectar sin querer a otra parte del sistema.
Esto crea un ciclo conocido:
Implementación → Pruebas → Corrección → Regresión → Más pruebas → Otra corrección.
Por lo tanto, aumentar simplemente el número de agentes o repetir las pruebas con más frecuencia no garantiza automáticamente un resultado correcto.
¿Por qué pueden acumularse los errores a lo largo de una cadena de agentes?
Consideremos un modelo matemático simplificado.
Supongamos que tenemos tres pasos consecutivos, cada uno con una probabilidad hipotética del 95 % de ejecutarse correctamente.
Si estos pasos son independientes y los tres deben tener éxito, la probabilidad resulta:
0.95 × 0.95 × 0.95 = 0.8574
Eso representa aproximadamente una probabilidad del 85,7 % de que los tres pasos tengan éxito.
Con diez pasos independientes de este tipo, el resultado sería:
0.95¹⁰ ≈ 59,9 %
Es un cálculo ilustrativo, no una tasa de éxito medida de agentes de IA. En los sistemas reales, los errores no siempre son independientes, los mecanismos de validación pueden detectar fallos y cada paso puede corregir errores anteriores.
Sin embargo, el ejemplo demuestra un principio importante:
La fiabilidad de cada agente por separado no garantiza automáticamente la fiabilidad de toda la cadena.
Cuando las instrucciones incompletas se reinterpretan una y otra vez en cada etapa, pueden surgir más oportunidades de tomar decisiones incorrectas.
Por eso creo que simplemente añadir más agentes, pruebas y mecanismos de validación no es suficiente.
Necesitamos cambiar la forma en que la IA recibe información sobre el propio sistema.
La diferencia clave: las pruebas verifican resultados, la lógica de negocio define límites
El enfoque convencional del desarrollo asistido por IA es reactivo.
Envías un requisito, la IA implementa una solución y después se usan las pruebas para determinar si algo se ha roto.
Eso es sin duda mejor que no tener pruebas en absoluto.
Pero sigue habiendo una debilidad fundamental:
Las pruebas no pueden validar de forma fiable reglas de negocio que nadie conoce y que no forman parte de la especificación de pruebas.
Por eso creo que un enfoque mejor es proporcionar a la IA información sobre el comportamiento real del sistema antes de que empiece la implementación.
No solo qué hay que cambiar, sino también:
Qué reglas de negocio se aplican al código afectado.
Qué otros módulos dependen de la funcionalidad.
Qué entradas y salidas deben seguir siendo compatibles.
Qué escenarios deben permanecer sin cambios.
Qué excepciones y restricciones históricas existen.
Qué partes de la implementación puede modificar la IA y cuáles debe conservar.
Esto reduce de forma significativa la cantidad de comportamiento que la IA debe deducir por su cuenta.
Dos enfoques para la misma tarea
Enfoque A - Prompt + pruebas
La IA recibe una tarea, elige una implementación según el contexto disponible, produce la solución y ejecuta las pruebas.
Si las pruebas son incompletas, las violaciones de reglas de negocio existentes pueden pasar desapercibidas.
Enfoque B - Prompt + lógica de negocio + pruebas
La IA recibe la tarea junto con las reglas, dependencias, contratos y restricciones relevantes.
Como resultado, sabe qué comportamiento debe conservarse antes de que empiece la implementación.
Entonces las pruebas hacen algo más que detectar errores. También verifican contratos de negocio concretos.
La diferencia no es que dejemos de probar.
La diferencia es que intentamos evitar los errores antes de que se introduzcan.
Ejemplo práctico: añadir un nuevo método de pago
Imagina que tenemos un archivo llamado CheckoutService.ts, que gestiona los pagos en una aplicación de comercio electrónico.
Queremos añadir el pago con tarjeta como método de pago adicional.
Opción A: un prompt convencional
Tarea:
> Add card payments to CheckoutService.ts. Preserve existing functionality and run all tests.
La IA modifica el código, añade una nueva rama de pago y actualiza las pruebas.
Todas las pruebas pasan.
La tarea se marca como completada.
Sin embargo, el sistema contiene una regla de negocio importante:
Las cuentas de empresa deben usar la transferencia bancaria como método de pago predeterminado.
Esta regla se introdujo hace varios años. El desarrollador que la implementó ya no trabaja en la empresa. La regla no está claramente documentada y no existe ninguna prueba de regresión específica.
La IA introduce el pago con tarjeta como método predeterminado para todos los clientes.
Desde el punto de vista de la implementación, la nueva funcionalidad funciona correctamente.
Desde el punto de vista de la lógica de negocio, el sistema está roto.
Y las pruebas no detectaron el problema.
Opción B: una tarea estructurada con lógica de negocio en AITM
Ahora imagina que la IA recibe la misma petición, pero esta vez la tarea incluye el contrato de negocio relevante, las variables relacionadas, enlaces a tareas históricas y límites precisos para los cambios permitidos.
La tarea podría verse así:
READ CLAUDE.md first.
TASK:
Add card payment as an additional payment method
in CheckoutService.ts.
Contract:
%CHECKOUT-019 — "For company accounts
(companyId != null), bank transfer must remain
the default payment method. Card payment may
be offered only as an additional option."
Related variables:
BL.CHECKOUT.PAYMENTMETHOD_DEFAULT
BL.CHECKOUT.PAYMENTMETHOD_OPTIONS
Related task:
#<link to the task that originally implemented bank-transfer-as-default checkout>
In scope:
- Add a new "card" option to the available payment methods in CheckoutService.ts.
- Expose it as a selectable option in the existing payment method selection flow.
Out of scope:
- Changing the default payment method for any account type.
- Any UI/checkout-flow redesign beyond adding the new option.
- New payment provider integration logic beyond the method registration itself.
Must not break:
- Existing default payment selection logic (company accounts → bank transfer stays default).
- Company account checkout behavior end-to-end.
- Existing bank transfer processing path.
- Compatibility with the current payment API contract.
File path:
src/Services/CheckoutService.ts
Confirm the exact path via contractsForFile before editing.
Verify:
- Company account checkout still selects bank transfer by default
(companyId != null).
- Card payment appears as a selectable, non-default option.
- Existing bank transfer processing is unchanged.
- Run unit and integration tests covering CheckoutService.
Más información sobre cómo funciona esto en AITM: https://aitm.cz/Docs/KnowledgeSharing
¿Por qué es importante este formato?
A primera vista, puede parecer nada más que un prompt más detallado.
Pero la diferencia real es que la tarea está conectada con información que puede recuperarse y verificarse contra el proyecto real.
1. Contrato %CHECKOUT-019
El identificador %CHECKOUT-019 no es solo una nota de texto.
Es un identificador de contrato ilustrativo que el agente puede recuperar mediante operaciones GraphQL como contractsForFile o contractsForVariable.
En lugar de fiarse únicamente de la regla escrita en el prompt, el agente puede recuperar su representación estructurada y verificarla contra la base de código actual.
2. Variables de lógica de negocio _BL.
Identificadores como _BL.CHECKOUT.PAYMENT_METHOD_DEFAULT y _BL.CHECKOUT.PAYMENT_METHOD_OPTIONS representan la lógica de negocio expresada mediante el lenguaje de comunicación de AITM.
Ayudan a conectar un requisito concreto con las reglas y variables que determinan el comportamiento del sistema.
3. Referencia a una tarea relacionada
La sección Related task hace referencia a la tarea original en la que se implementó la regla de negocio.
Esto da a la IA contexto adicional, no solo sobre cómo se comporta el sistema ahora, sino también sobre por qué pudo tomarse una decisión determinada.
4. Límites de cambio claramente definidos
Las secciones In scope, Out of scope y Must not break definen tres categorías distintas:
Lo que la IA debe implementar.
Lo que la IA no debe implementar.
Qué comportamiento existente debe conservar la IA.
En lugar de recibir una tarea abierta que puede interpretar o ampliar libremente, la IA recibe un alcance de implementación definido con precisión.
5. Verificación antes de escribir código
No se da por hecho automáticamente que la ruta del archivo sea correcta.
Se instruye al agente para que use primero contractsForFile, confirme la ruta real e identifique los contratos asociados.
Solo entonces debe empezar a modificar el código.
6. Validación del prompt mediante TPV
Una parte importante del enfoque de AITM es el validador de prompts TPV.
Comprueba las secciones obligatorias de la tarea antes de enviarla a ejecución.
Por ejemplo, verifica la presencia de definiciones de alcance, restricciones, contratos, rutas de archivo y requisitos de verificación.
Esto traslada parte de la prevención de errores desde las pruebas del código terminado a la preparación de la propia tarea.
Nota: Los identificadores de contrato y las variables de lógica de negocio de este ejemplo son marcadores de posición ilustrativos. En un proyecto real, el optimizador los recupera mediante GraphQL del proyecto concreto. No deben adivinarse ni generarse sin verificación.
¿Qué cambia con este enfoque?
En el enfoque convencional, el agente interpreta primero una tarea abierta y decide por sí mismo qué archivos, dependencias y reglas de negocio importan.
Con AITM, la tarea está conectada con contratos concretos, variables de lógica de negocio, tareas históricas y límites de cambio claramente definidos.
Por lo tanto, el agente puede tomar decisiones basadas en información verificable en lugar de apoyarse sobre todo en suposiciones.
Y ahí es donde veo la diferencia fundamental.
La lógica de negocio deja de ser solo parte de la documentación. Pasa a formar parte del propio proceso de control de la implementación.
Este es el principio detrás de AITM
Cuando empezamos a diseñar AITM (AI Task Manager), no queríamos construir simplemente otro sistema que lanza agentes, reparte tareas y comprueba sus resultados después.
Nos centramos en una pregunta distinta:
¿Y si la IA pudiera recibir la lógica de negocio relevante directamente del código fuente existente antes de hacer ningún cambio?
No solo documentación que alguien escribió hace un año.
No solo instrucciones generales guardadas en una skill.
Y no solo unos cuantos archivos que un agente selecciona por casualidad.
Sino información estructurada que describe cómo se comporta realmente la parte afectada del sistema, qué contratos la rigen y qué otros componentes dependen de ella.
El principio central de AITM es, por tanto, enriquecer el prompt de trabajo con la lógica de negocio identificada en las partes relevantes de la base de código.
El agente recibe no solo información sobre lo que debe hacer, sino también sobre lo que debe conservar.
Esto es especialmente importante en sistemas de software a gran escala, donde un solo prompt puede no contener todas las dependencias o restricciones relevantes.
La lógica de negocio como quitamiedos para la IA
Piensa en la lógica de negocio como los quitamiedos de una carretera.
Sin quitamiedos, la IA puede tomar muchos caminos distintos. Algunos pueden llevar a una solución correcta, mientras que otros pueden violar reglas ocultas dentro del sistema.
Al proporcionar los contratos y restricciones relevantes, reducimos de forma significativa el espacio para decisiones indeseadas.
La IA sigue pudiendo elegir de forma independiente estrategias de implementación, algoritmos y estructuras de código.
Pero debe respetar las reglas de negocio conocidas.
Las pruebas posteriores verifican entonces si esas reglas se han conservado realmente.
Esto representa un cambio fundamental de filosofía.
No intentamos simplemente corregir los errores que crea la IA. Intentamos reducir la probabilidad de que esos errores se introduzcan desde el principio.
¿Significa esto que ya no necesitamos agentes ni pruebas?
En absoluto.
Los agentes son útiles para la ejecución en paralelo, las actividades especializadas y la automatización de tareas grandes.
Las pruebas unitarias, las pruebas de integración y las pruebas E2E siguen siendo componentes esenciales del aseguramiento de la calidad del software.
Pero la orquestación de agentes y las pruebas automatizadas no pueden sustituir el conocimiento de la lógica de negocio.
Si un agente no entiende qué debe conservar el sistema, ni siquiera un equipo de subagentes perfectamente organizado resolverá el problema de fondo.
Y si las pruebas no cubren los escenarios relevantes, todas las pruebas pueden pasar mientras la aplicación sigue comportándose de forma incorrecta desde el punto de vista del negocio.
El enfoque correcto no es elegir entre lógica de negocio y pruebas. Es combinarlas.
Primero, identificar el comportamiento real del sistema.
Después, expresar ese comportamiento como reglas y contratos claros.
A continuación, proporcionar esas reglas a la IA junto con la tarea.
Solo entonces pasar a la implementación, la validación y las pruebas.
Este enfoque puede reducir correcciones innecesarias, regresiones y ciclos de implementación repetidos.
Conclusión: no se trata del número de agentes. Se trata de la calidad de la información.
Para aplicaciones sencillas, la IA puede ofrecer excelentes resultados incluso con instrucciones relativamente cortas.
Pero con software empresarial de medio millón de líneas de código, no basta con suponer que un agente lo entenderá todo correctamente, descubrirá todas las dependencias y luego probará su propio trabajo sin fallos.
Cuanto más grande se vuelve el sistema, más importante es comprender y proteger su comportamiento de negocio real.
Puedes tener diez agentes colaborando a la perfección. Pero si ninguno conoce una regla de negocio crítica, pueden producir colectivamente una solución perfectamente probada que es fundamentalmente errónea.
Por eso adoptamos con AITM un enfoque distinto.
Primero, contexto, reglas y contratos.
Después, la implementación.
Y por último, la validación y las pruebas.
Porque el objetivo no es que la IA escriba la mayor cantidad de código posible en el menor tiempo.
El objetivo es que la IA cambie exactamente lo que hay que cambiar, sin romper lo que ya funciona.