Skip to main content
multi-agentai-automationsoftware-development

OpenSpec: Primero la Especificación, Luego el Ejército de Agentes

Ha surgido un patrón práctico para el desarrollo multiagente: primero una especificación detallada, luego un plan y finalmente la ejecución por subagentes. Para los negocios, esto es vital porque reduce el caos en I+D, simplifica la regeneración de código y hace que la automatización con IA sea más predecible.

Contexto Técnico

Lo que me llamó la atención no fue otro framework más, sino un patrón de trabajo muy práctico: write spec - plan - subagent-driven development. La esencia es simple y, sinceramente, dolorosamente familiar. Si la generación de código se descarrila, lo que te salva no es un nuevo prompt, sino una especificación viva que puedes abrir para reconstruir la solución casi desde cero.

En este caso, se utiliza un archivo change_spec.md como pilar, que reside junto al código. No es un documento para cumplir un requisito, sino la fuente de la verdad: qué cambiamos, qué limitaciones existen, qué consideramos un resultado exitoso. Cuando la base de código se "ensucia" o los agentes desvían la solución, puedo volver a la especificación y regenerar la rama sin adivinanzas.

Me gustó especialmente la estimación de tiempo: una tarea grande requiere 2-3 días para la especificación y solo 0.5-1 día para la generación de código. Es decir, el 70-80% del esfuerzo no se lo lleva la programación, sino la formalización de la tarea. Suena casi ofensivo, hasta que te enfrentas a un sistema multiagente que hace perfectamente rápido lo incorrecto.

Técnicamente, esto se parece mucho a una jerarquía normal. Un agente o una persona crea la especificación mediante brainstorming, luego un planificador la divide en pasos, y después los subagentes se encargan de partes específicas: backend, frontend, pruebas, validación. Considero este enfoque más maduro que intentar meter todo el proyecto en un único contexto largo y esperar que el modelo "lo entienda por sí solo".

Otro punto fuerte aquí es la descomposición. Si la especificación se vuelve demasiado grande, no hay que seguir añadiendo sin fin, sino dividirla por sus límites naturales: intake, analysis, execution, validation. Y es aquí donde la multiagencia comienza a aportar valor, en lugar de simplemente quemar tokens para un diagrama bonito.

Qué Cambia Esto para el Negocio y la Automatización

Para el negocio, la conclusión es clara: la principal incertidumbre en los proyectos de IA no reside en el modelo, sino en la definición de la tarea. Si no tienes una especificación viva, ninguna automatización con IA será estable. Tendrás una serie de demos, tras las cuales el equipo odiará en silencio la palabra "agente".

Lo veo en proyectos donde nos piden crear un agente de IA para procesos internos. Casi siempre, el primer avance real no ocurre tras cambiar el modelo, sino después de que extraemos de la mente de las personas los criterios de éxito, las excepciones, los roles, las limitaciones de datos y las reglas de escalada. Una vez que todo esto se plasma en una estructura de especificación adecuada, la arquitectura de la solución de IA se vuelve mucho más serena.

¿Quiénes ganan? Los equipos con ciclos largos de I+D, mucha ambigüedad y errores costosos: desarrollo de productos, plataformas internas, integraciones complejas, procesos empresariales. ¿Quiénes pierden? Aquellos que esperan magia instantánea y consideran la especificación una burocracia. Los multiagentes sin una buena especificación se convierten fácilmente en una forma cara de paralelizar la confusión.

No aconsejaría meter una configuración multiagente en todos los casos. Si un solo agente con buenas 'tool calls' puede resolver la tarea, a menudo es suficiente. Pero cuando el contexto se hincha, hay muchas etapas y el resultado necesita ser reconstruible, el enfoque 'spec-first' empieza a ser rentable muy rápidamente.

En Nahornyi AI Lab, solemos construir estas soluciones con una combinación práctica: una especificación viva, un planificador, ejecutores aislados, control de artefactos y un ciclo claro de revisión humana. Esto ya no es "jugar con LLMs", sino una implementación de IA en el desarrollo y en los procesos operativos donde la repetibilidad es clave.

Soy Vadym Nahornyi de Nahornyi AI Lab, y veo estos patrones no como un observador, sino como alguien que construye regularmente automatizaciones con IA, pipelines de agentes y arquitecturas de IA personalizadas para tareas reales. Si quieres discutir tu caso, solicitar automatización con IA, el desarrollo de un agente de IA a medida o una automatización con n8n, contáctame. Analizaremos dónde realmente necesitas un enjambre de agentes y dónde basta con una especificación clara y una buena implementación.

Compartir este articulo