Dos enfoques del SDLC agéntico
Se empiezan a perfilar dos enfoques del SDLC agéntico. Se apoyan en los mismos agentes de código y sin embargo sitúan el centro de gravedad en dos lugares distintos.
Un workflow dejado libre
En las prácticas publicadas en torno al SDLC con Claude Code, Anthropic deja deliberadamente mucha libertad al desarrollador. El workflow no se impone y la documentación del proyecto sigue siendo relativamente libre en su estructura.
Esta flexibilidad se apoya en gran medida en las capacidades del modelo: explorar un codebase, comprender el contexto, elaborar un plan, producir el código, probar y luego iterar con el desarrollador. La calidad del resultado depende entonces mucho de la capacidad del modelo para reconstruir el contexto, y de la del desarrollador para guiarlo.
Un SDD integrado en un SDLC
Un enfoque SDD integrado en un SDLC, como BMAD y su variante Niji ARC™, desplaza mucho más claramente el centro de gravedad. La especificación pasa a ser uno de los principales soportes del delivery.
| Dimensión | Workflow libre | SDD integrado en el SDLC |
|---|---|---|
| Centro de gravedad | El modelo y el desarrollador | La especificación |
| Workflow | No impuesto | Organizado mediante workflows y skills |
| Documentación del proyecto | Estructura relativamente libre | Referente común: necesidades, recorridos, arquitectura, decisiones, criterios de aceptación, pruebas, RUN |
| Quién contribuye | Principalmente el desarrollador, con el modelo | Negocio, Product Builder, dirección de proyecto, diseñador, arquitecto, desarrolladores, QA |
| Dónde descansa la calidad | En la capacidad del modelo y del usuario para reconstruir el contexto | En un marco compartido |
| Punto fuerte | Aprovechar rápido los avances de los modelos, gran autonomía del desarrollador | Coherencia y continuidad del delivery |
La especificación, un referente común del proyecto
En este segundo enfoque, la especificación se convierte en un referente común del proyecto, más allá del simple contexto destinado a los agentes. Reúne:
- las necesidades de negocio;
- los recorridos;
- la arquitectura;
- las decisiones técnicas;
- los criterios de aceptación;
- las pruebas;
- las restricciones de RUN.
Negocio, Product Builder, dirección de proyecto, diseñador, arquitecto, desarrolladores y QA pueden así trabajar a partir de una misma materia, que también pueden explotar los agentes. Cada uno contribuye desde su rol, y lo que produce uno alimenta directamente el trabajo de los demás, personas y agentes por igual.
Es el principio que aplicamos con Niji ARC™: la especificación es el producto, y los agentes generan el código, las pruebas y la documentación directamente a partir de ella. El papel del Product Builder en este sistema se detalla en nuestra reflexión sobre el tamaño de las squads de IA.
Workflows y skills: organizar la construcción colectiva
Una materia compartida no basta: hay que organizar además cómo se construye. Es el papel de los workflows y los skills, que definen quién contribuye, en qué momento, con qué nivel de contexto y con qué controles.
Cada rol interviene desde su perímetro: negocio, producto, diseño, arquitectura, desarrollo, QA. Los workflows hacen explícitas estas contribuciones en lugar de dejarlas a la iniciativa de cada uno.
Las contribuciones se secuencian a lo largo del ciclo, desde la expresión de la necesidad hasta la puesta en producción, con etapas identificadas de principio a fin.
Cada agente y cada colaborador recibe el contexto útil para su etapa, procedente del referente común, sin tener que reconstruirlo.
Puntos de validación jalonan el recorrido: criterios de aceptación, pruebas, revisiones. La materia producida en una etapa solo pasa a ser la base de la siguiente una vez controlada.
Aplicamos la misma lógica de roles, skills y workflows a los profesionales del dato con el framework MAD.
La diferencia se ve al industrializar
La diferencia se hace especialmente visible cuando se busca industrializar.
Un workflow muy libre permite aprovechar rápidamente los avances de los modelos y conserva una gran autonomía para el desarrollador. Para un desarrollador o un equipo pequeño, es una ventaja real.
Un SDLC más estructurado busca, por el contrario, que una parte mayor de la calidad, la coherencia y la continuidad del delivery descanse en un marco compartido, y no solo en la capacidad del modelo y del usuario para reconstruir el contexto.
Tres preguntas para situar tu contexto. ¿Cuántas personas y roles contribuyen al mismo producto? ¿Cuál es la vida útil del producto, y quién lo mantendrá en RUN? Cuando un colaborador cambia de proyecto, ¿el contexto queda en el referente o en la cabeza de alguien?
Del coding agéntico al delivery agéntico
Lo que está en juego ya no es únicamente la eficacia del coding agéntico. Pasa a ser el de un delivery de software agéntico, en el que personas y agentes contribuyen al mismo sistema de referencia, cada uno desde su rol.
Los modelos seguirán progresando. La cuestión de sobre qué referente construyen juntos personas y agentes se planteará sea cual sea el modelo utilizado.
Para recordar. Un workflow libre aprovecha la potencia del modelo. Un SDLC estructurado hace de la especificación un referente común donde personas y agentes contribuyen, cada uno desde su rol.
