La IA no acelera el desarrollo por sí sola: la arquitectura de trabajo detrás de KIRA

Problema y motivación

Cuando una tarea se distribuye entre varios agentes, la capacidad de ejecución puede crecer, pero también aparecen nuevos riesgos:

La investigación disponible coincide con esta preocupación. SWE-bench muestra que resolver problemas reales de software exige comprender cambios relacionados entre funciones, clases y archivos, además de interactuar con entornos de ejecución y contextos extensos. No es una simple tarea de generación de código.

El estudio MAST sobre sistemas multiagente identificó fallas en tres grupos especialmente relevantes: especificación y diseño del sistema, desalineación entre agentes, y verificación o terminación de tareas. La conclusión práctica es clara: agregar agentes no corrige una arquitectura de trabajo débil; puede amplificarla.

• interpretaciones diferentes del mismo requerimiento;
• actividades duplicadas o sin responsable claro;
• tareas marcadas como terminadas sin evidencia suficiente;
• correcciones que pierden el contexto del problema original;
• decisiones dispersas entre conversaciones;
• cierres prematuros sin un criterio de aceptación verificable.

Pregunta de diseño

¿Cómo coordinar agentes especializados en varias aplicaciones, sin que la continuidad dependa de la memoria de una conversación y manteniendo en una persona la autoridad sobre el alcance, la prioridad, la aceptación y la decisión final?

KIRA se diseña para responder esa pregunta desde la orquestación, no desde la promesa de autonomía total.

Evidencia que orienta el diseño

Cuatro ideas provenientes de la literatura guiaron los criterios del producto:

Estas fuentes no validan KIRA ni prueban que una configuración concreta sea superior. Sí respaldan la necesidad de diseñar roles, estados, correcciones, trazabilidad y supervisión como partes del sistema.

• El software real necesita contexto y verificación. SWE-bench evidencia que los problemas reales requieren comprender dependencias y comprobar si los cambios resuelven el caso planteado.
• Los sistemas multiagente fallan también por diseño. MAST documenta fallas de especificación, coordinación y cierre, no únicamente limitaciones del modelo.
• La interacción humana debe facilitar la corrección. Las guías de Amershi y colaboradores proponen hacer visibles los estados, permitir correcciones eficientes y apoyar al usuario cuando el sistema se equivoca.
• La responsabilidad y la supervisión deben estar definidas. NIST recomienda diferenciar roles, documentar el alcance y establecer procesos de supervisión humana durante el ciclo de vida de la IA.

Criterios de diseño aplicados

1. Separar aplicaciones sin fragmentar el gobierno

Cada producto necesita su propio contexto, identificadores, backlog y tablero. La separación evita mezclar decisiones entre aplicaciones; el gobierno común permite leer el conjunto desde un solo entorno.

2. Convertir cada solicitud en una asignación verificable

Una instrucción abierta no basta. La unidad de trabajo debe conservar responsable, estado, criterio de aceptación y evidencia esperada. El agente recibe una tarea acotada; la persona mantiene la intención y el criterio.

3. Hacer visible el flujo

KIRA utiliza tableros Kanban y vistas de tabla para mostrar tareas, fixes y observaciones. El objetivo no es decorar el proceso, sino detectar trabajo bloqueado, duplicado, devuelto o sin cierre.

4. Separar ejecución y calidad

Quien construye no debería declarar por sí solo que el resultado está listo. El flujo incorpora una validación QA que puede aprobar o devolver la incidencia con observaciones y evidencia. La devolución no reinicia el proyecto: genera un ciclo controlado de corrección.

5. Conservar trazabilidad

Asignaciones, responsables, incidencias, evidencias, devoluciones y cierres deben permanecer vinculados. Si una ventana de contexto termina, el proyecto continúa porque el estado relevante pertenece al sistema de trabajo.

6. Integrar mediante API

La API permite consultar y actualizar asignaciones y estados. Esto habilita la coordinación con agentes sin obligar a que toda la operación dependa de interacción manual en una interfaz.

7. Mantener una autoridad humana explícita

La persona responsable define alcance, prioridad, criterios de aceptación y decisión final. Los agentes ejecutan tareas; no asumen responsabilidad organizacional ni reemplazan el juicio sobre riesgo, calidad o despliegue.

El artefacto: KIRA

KIRA organiza el trabajo en una arquitectura conceptual de cinco capas:

El ciclo no es estrictamente lineal. Cuando QA devuelve una incidencia, esta regresa a la orquestación como un fix con contexto, responsable y evidencia pendiente. Esa ruta de error es tan importante como el camino exitoso.

• Entrada: aplicaciones, requerimientos y backlog.
• Orquestación: registro multiaplicación, asignaciones, estados, tableros, API y trazabilidad.
• Ejecución: agentes especializados que desarrollan por etapas y adjuntan evidencia.
• Control: validación QA, aprobación o devolución según criterios de aceptación.
• Entrega gobernada: cierre trazable y evolución hacia una gestión integral de despliegues.

Riesgos y controles

• Requerimiento ambiguo: Definición funcional y criterio de aceptación antes de asignar
• Desalineación entre agentes: Alcance acotado, responsable visible y estado compartido
• Falso cierre: Validación QA y evidencia antes de aprobar
• Pérdida de contexto: Historial persistente de incidencias, decisiones y correcciones
• Terminación prematura: Estados y condiciones explícitas de cierre
• Crecimiento desordenado: Separación por aplicación y gobierno común
• Sesgo de automatización: Decisión final y capacidad de detener o devolver en manos humanas

Forma de evaluación

La evaluación disponible es funcional y técnica. KIRA ya permite organizar múltiples aplicaciones, administrar asignaciones y estados, utilizar vistas Kanban y de tabla, integrar agentes mediante API, ejecutar un flujo de QA y conservar historial de incidencias, responsables, evidencias y cierres.

Todavía no presento métricas de productividad, reducción de errores o velocidad porque no existe una medición controlada suficiente para sostener esas afirmaciones. El siguiente paso es instrumentar indicadores comparables, por ejemplo:

El objetivo no es demostrar que “más agentes siempre es mejor”, sino identificar bajo qué condiciones la orquestación produce entregas más previsibles y controlables.

• tiempo desde asignación hasta validación QA;
• porcentaje de aceptación en el primer ciclo;
• tasa de devoluciones y reaperturas;
• tareas sin responsable o sin evidencia;
• completitud de la trazabilidad;
• tiempo de resolución de fixes.

Limitaciones

KIRA se encuentra en evolución. Su diseño no constituye evidencia causal de mejora de productividad y todavía requiere evaluación sistemática. La calidad sigue dependiendo de la definición funcional, del modelo utilizado, del contexto disponible y de la revisión humana.

La plataforma tampoco sustituye el repositorio de código, las pruebas automatizadas, la seguridad, la integración continua ni los controles de despliegue. Los coordina desde la perspectiva del trabajo y la trazabilidad; no elimina la responsabilidad técnica de cada etapa.

Conclusión accionable

Antes de añadir otro agente a un flujo de desarrollo, conviene responder siete preguntas:

Si estas respuestas no son visibles, el problema no es la falta de inteligencia del modelo. Es la falta de arquitectura de trabajo.

La IA puede ampliar la capacidad de ejecución. La dirección, la calidad y la responsabilidad siguen siendo humanas.

• ¿Qué rol cumple?
• ¿Qué información recibe?
• ¿Qué resultado debe entregar?
• ¿Cómo se valida?
• ¿Qué evidencia debe conservar?
• ¿Qué ocurre cuando falla?
• ¿Quién tiene la decisión final?