¿Qué es AI-DLC? El ciclo de desarrollo guiado por IA, visto desde dentro de un rollout

En AI-DLC la IA conduce y la persona decide. Todo lo demás en el método existe para que la segunda mitad de esa frase siga siendo cierta.

AI-DLC, el AI-Driven Development Life Cycle, es un método para construir software en el que un agente de IA planifica el trabajo, hace las preguntas y escribe todos los artefactos, de los requisitos al código, mientras las personas aprueban o rechazan el resultado en gates entre un paso y otro. AWS lo publicó en julio de 2025. En septiembre de 2026 lanzó AI-DLC 2, un motor de workflow instalable que corre dentro de Claude Code, Kiro, Codex, Cursor, opencode y GitHub Copilot.

Esa es la definición. El resto de esta guía es la parte que la documentación no cuenta.

Escribo sobre Spec-Driven Development desde hace un año, y construí una fintech de 13 apps en 70 días especificando antes de generar. En los últimos meses también estuve dentro de una gran organización de ingeniería donde AI-DLC pasó de los squads piloto a un programa de formación para las personas que lo van a llevar a todos los equipos. Estuve en las sesiones. Vi lo que se rompió. Todo lo que sigue sale del método público, de la release actual y de ese rollout, sin los nombres.

AI-DLC es un método, no una herramienta

Empieza por lo que todo el mundo entiende mal primero. AI-DLC es una forma de organizar el trabajo de software alrededor de un agente de IA. AWS lo describe como metodología, y los análisis independientes coinciden. El texto de TT PSC lo resumió en una línea: la contribución de AI-DLC “no es la generación de código en sí”, es “un modelo operativo controlado en el que la IA participa en Inception, Construction y Operations, mientras los humanos siguen siendo responsables de las decisiones”.

La herramienta llegó después. La primera versión abierta, en noviembre de 2025, era un conjunto de archivos de reglas para Amazon Q y de steering files para Kiro. AI-DLC 2 lo convirtió en un motor con comando propio, aidlc, que instala el workflow dentro del agente de código que ya usas. AWS llama harness a cada uno de esos agentes: Claude Code es uno, Cursor es otro. Puedes practicar el método sin el motor. No puedes sacarle valor al motor sin el método.

AI-DLC 2 en números

5

fasesde Initialization a Operation

33

etapascada una con un agente líder

14

agentes11 especialistas, 2 revisores, 1 composer

7

harnessesClaude Code, Kiro, Codex, Cursor y más

La IA hace las preguntas y tú decides

El corazón del método es una inversión. En el desarrollo asistido por IA de siempre, la conversación la empiezas tú. Escribes el prompt, la IA ayuda en una tarea, y el proceso alrededor sigue siendo el que tu equipo ya tenía. En AI-DLC empieza la IA. Le das una intención, y ella propone el plan, pregunta lo que necesita saber, redacta el artefacto y se detiene a esperar tu aprobación antes de seguir.

El whitepaper usa una app de navegación para explicarlo. Tú fijas el destino. La app te da los giros. Sigues mirando la calle y puedes tomar otra ruta, pero dejaste de leer el mapa.

Desarrollo asistido por IA

1. 01Tú escribes el prompt y la IA responde
2. 02La IA ayuda en una tarea a la vez
3. 03El proceso es el que se hizo para humanos
4. 04Las decisiones quedan en el historial del chat

AI-DLC

1. 01Tú declaras una intención y la IA hace las preguntas
2. 02La IA propone el plan y la descomposición
3. 03El proceso se rehace alrededor de la velocidad de la IA
4. 04Las decisiones quedan en archivos versionados en el repo

Esto cambia lo que significa hacer bien tu trabajo. Ya no ganas escribiendo el prompt perfecto. Ganas respondiendo las preguntas correctas con el contexto correcto, y negándote a aprobar lo que no sabes explicar.

Por qué AWS dice que no se puede atornillar IA a Scrum

El primer principio del whitepaper es reimaginar en lugar de adaptar. El argumento es simple y creo que es correcto. Scrum se diseñó para un equipo de personas que necesita dos semanas para entregar un incremento que funcione, así que sus rituales tienen el tamaño de ese ritmo: planning, daily, review, retro. Un agente entrega el mismo incremento en horas. Si mantienes los rituales de dos semanas, el agente pasa la mayor parte de su vida esperando una reunión.

El paper nombra los dos fracasos de cada lado. El desarrollo asistido por IA mantiene el proceso viejo y le suma autocompletado, así que nunca cambia la estructura del trabajo. El desarrollo autónomo deja al agente construir solo, lo que todavía no funciona, porque el contexto y las decisiones críticas siguen dependiendo de una persona. AI-DLC queda en el medio: la IA conduce, la persona aprueba.

El vocabulario: Intent, Unit, Bolt

AI-DLC renombró las piezas del trabajo a propósito. El séptimo principio del whitepaper dice que alguien con experiencia debería poder empezar en un día, así que cada término nuevo se corresponde con uno viejo.

Palabras viejas, palabras nuevas

Bolt no es un sprint con otro nombre. Es más corto porque la IA comprime el tiempo de producir un artefacto de días a minutos.

Término de AI-DLC	Qué reemplaza	Qué significa
Intent	Épica de negocio	Una declaración de qué hay que lograr y por qué. El punto de partida que la IA descompone.
Unit	Épica técnica	Una parte autocontenida de la solución que entrega valor medible y se puede construir y desplegar sola.
Bolt	Sprint	Una porción de entrega medida en horas o días, no en semanas. En AI-DLC 2, una porción planificada sobre una o más Units dependientes.
Mob Elaboration	Planning y refinamiento	El equipo y la IA en una sola sesión: la IA propone historias y Units, el equipo las corrige.
Mob Construction	Código, review, pruebas	La IA genera diseño, código y pruebas; los ingenieros aprueban o piden cambios en cada paso.
Deployment Unit	Release candidate	Código, configuración e infraestructura probados en función, seguridad y requisitos no funcionales.

Dos de estos merecen una segunda mirada. La Intent es la única entrada que una persona tiene que acertar, y el método casi no dice cómo acertarla. El hueco es tan grande que tiene su propio artículo. Y en el Mob Elaboration vive la mayor parte del valor y del dolor. Es un ritual, con reglas sobre quién se sienta en la sala, y tiene su propia guía.

Cinco fases y 33 etapas en AI-DLC 2

La primera versión de AI-DLC tenía tres fases: Inception, Construction y Operations. AI-DLC 2 tiene cinco. Sumó Initialization, que arma el workspace en menos de un segundo sin ninguna persona involucrada, e Ideation, que convierte un pedido vago en una iniciativa aprobada antes de escribir cualquier requisito.

El ciclo de vida de AI-DLC 2

1. 0.1 a 0.3

   Initialization

   Arma el workspace, detecta el proyecto, crea el estado. Automático.

   • Workspace Scaffold
   • Workspace Detection
   • State Initialization
   ↓→
2. 1.1 a 1.7

   Ideation

   ¿Vale la pena construir esto, y qué es exactamente?

   • Intent Capture and Framing
   • Market Research
   • Feasibility
   • Scope Definition
   • Team Formation
   • Rough Mockups
   • Approval and Handoff

   ◆ Gate: Gate de verificación 1

   ↓→
3. 2.1 a 2.9

   Inception

   Requisitos, diseño y las Units de trabajo.

   • Reverse Engineering
   • Practices Discovery
   • Requirements Analysis
   • User Stories
   • Refined Mockups
   • Domain Design
   • Units Generation
   • Contract Design
   • Delivery Planning

   ◆ Gate: Gate de verificación 2

   ↓→
4. 3.1 a 3.7

   Construction

   Diseño, código y pruebas, una Unit a la vez.

   • Functional Design
   • NFR Requirements
   • NFR Design
   • Infrastructure Design
   • Code Generation
   • Build and Test
   • CI Pipeline

   ◆ Gate: Gate de verificación 3

   ↓→
5. 4.1 a 4.7

   Operation

   Despliegue, observabilidad y lo aprendido vuelve a Ideation.

   • Deployment Pipeline
   • Environment Provisioning
   • Deployment Execution
   • Observability Setup
   • Incident Response
   • Performance Validation
   • Feedback and Optimization

Dos tipos de checkpoint atraviesan ese mapa, y la diferencia importa. Al final de cada etapa hay un gate de aprobación: respondes Approve o Request Changes, con tus palabras, y nada avanza hasta que respondas. Entre fases hay un gate de verificación: un chequeo automático de que cada requisito se convierte en una historia, nada quedó huérfano y los artefactos concuerdan entre sí. El primero atrapa mal criterio. El segundo atrapa vínculos rotos.

Cada etapa tiene un agente líder. AWS trae 14: 11 especialistas de dominio (producto, diseño, entrega, arquitectura, plataforma AWS, compliance, DevSecOps, desarrollo, calidad, pipeline y despliegue, operaciones), dos revisores que juzgan requisitos y diseño técnico, y un composer que arma rutas a medida. El principio de diseño es “Small Mob, Broad Agents”: pocos agentes amplios en lugar de decenas de especialistas angostos, porque una cadena de especialistas angostos es waterfall con mejor marketing.

La mayoría de las etapas corre inline, en tu conversación con el agente. Cuatro no. Reverse Engineering es un pipeline de dos pasos (un agente de desarrollo recorre el código, un agente de arquitectura escribe la síntesis). Practices Discovery y Code Generation corren como subagents despachados. User Stories corre como mob, con los agentes de diseño, desarrollo y calidad escribiendo en paralelo. Todo queda en una carpeta por intent dentro de tu repo, con un archivo de estado y un log de auditoría de solo agregado que registra 108 tipos de evento.

La decisión de diseño más importante de AI-DLC 2 no aparece en ese mapa. La ruta la decide un motor determinístico, código común, y no el modelo. El modelo piensa dentro de cada etapa. El motor decide qué etapa sigue, una Unit solo cuenta como verificada mediante un comando de chequeo que una persona aprobó, los revisores son otros agentes, y las herramientas del modelo no pueden reescribir el estado del workflow. La versión 1 confiaba en que el agente siguiera reglas escritas en prosa, y el slop nace justamente de esa confianza: un modelo que elige su propia ruta y se corrige su propia tarea. La versión 2 le quitó esos poderes.

Los detalles de qué cambió entre versiones, y de qué parches caseros dejó obsoletos AI-DLC 2, están en AI-DLC 2: qué cambió.

Un bugfix no necesita 33 etapas

El décimo principio del whitepaper original es el que yo conservaría si solo pudiera conservar uno: nada de workflows rígidos. Un bugfix no necesita modelado de dominio. Una feature nueva sí. La IA propone la profundidad y la persona la ajusta.

AI-DLC 2 convirtió ese principio en 11 perfiles de workflow. Eliges uno por nombre, o describes el trabajo y el motor te sugiere uno.

Perfiles de workflow en AI-DLC 2

Para lo que no encaja en ninguno, /aidlc compose le pide al agente composer una ruta a medida y espera tu aprobación.

Perfil	Etapas	Úsalo para
Classic	18 / 33	La ceremonia de la versión 1: Inception y Construction, una aprobación por etapa. El valor por defecto si no eliges nada.
Express	10 / 33	Requisitos ya claros. El camino más corto a código y pruebas.
Feature	33 / 33	Una feature de producción por todo el ciclo.
Enterprise	33 / 33	Trabajo regulado o de alto riesgo. Profundidad máxima y los guards más estrictos.
MVP	23 / 33	Un primer incremento real, sin la fase de Operation.
Proof of concept	8 / 33	¿Esto funciona siquiera?
Bugfix	9 / 33	Un defecto conocido, una corrección enfocada, una prueba de regresión.
Refactor	10 / 33	Cambia la estructura, conserva el comportamiento.
Infrastructure	13 / 33	Ambientes, IaC, pipelines, costo.
Security patch	10 / 33	Una CVE o una vulnerabilidad puntual.
Workshop	26 / 33	Una sesión de formación facilitada.

Y hay una duodécima respuesta que la tabla no muestra: no usar AI-DLC. En el rollout que seguí, un ingeniero corrió el ritual completo para cambiar una sola línea de código. El playbook interno pronto ganó una regla nueva, aportada por alguien del piloto: si ya sabes exactamente qué escribir, escríbelo. AI-DLC se paga cuando el trabajo necesita descomposición y decisiones de más de una persona. Por debajo de eso, la ceremonia cuesta más de lo que ahorra.

Los gates son el método

Quítale todo a AI-DLC y queda un loop. La IA produce un artefacto. Una persona lo revisa. El siguiente paso usa el artefacto revisado como entrada. El whitepaper llama a cada revisión humana una función de pérdida (loss function): atrapa la decisión equivocada donde dar marcha atrás es barato, antes de que se multiplique en todo lo que viene después.

Esa lectura es correcta, y esconde el punto más débil del método. El gate es tan bueno como la persona parada en él, y la IA produce artefactos más rápido de lo que una persona puede leer con cuidado. Lo que vi romperse, en orden de frecuencia:

Cómo fallan los gates en la práctica

• ✗Anti-pattern:
  El artefacto parece completo y no dice nada.Un documento de requisitos bien formateado parece real. Alguien de producto en el rollout lo comparó con un correo falso de tu banco: el formato familiar apaga el escepticismo.
• ✗Anti-pattern:
  Quien revisa está cansado.Después de una hora leyendo documentos generados, la gente aprueba sin leer. Las sesiones de más de una hora convirtieron los gates en sellos.
• ✗Anti-pattern:
  Quien revisa no conoce el dominio.Los seniors interrogaban cada afirmación y tardaban más. Los juniors aceptaban la primera salida. Cuanto menos sabes, más confías.
• ✗Anti-pattern:
  La décima aprobación del día.La confianza se calibra con el historial. El agente acertó nueve veces, así que la décima recibe un vistazo.

La solución es más de ritmo que de herramienta. Sesiones de una hora. Pausas entre gates; el archivo de estado hace que pausar no cueste nada. El manager presente en los primeros mobs para frenar la prisa por aprobar. Y una regla para toda persona que revisa: antes de aprobar, di en una frase qué hace el artefacto y por qué está bien. Si no puedes, no terminaste de leer. El argumento completo, con las contramedidas, está en los gates son una función de pérdida.

AI-DLC necesita Spec-Driven Development antes

Aquí está mi principal desacuerdo con cómo se suele presentar AI-DLC. Los equipos oyen hablar de él, se entusiasman con los agentes y las fases, e intentan saltar del autocompletado a un ciclo de 33 etapas. No funciona, y la razón no es la herramienta.

AI-DLC asume que tu gente ya sabe especificar. Cada gate le pide a una persona que juzgue una spec: requisitos, historias, diseño, el plan de cada Unit. Un equipo que nunca practicó escribir specs no puede juzgar una. Entonces el agente produce artefactos plausibles basados en sus propias suposiciones, las personas los aprueban porque se ven bien, y el código que sale por el otro lado hay que arreglarlo a mano. La ejecución que debía cargar el agente vuelve a las personas. Eso es más lento que escribir el código tú mismo.

El modelo va a satisfacer cualquier especificación que le des, buena o mala. Estadísticamente cae en cualquier punto entre la mejor y la peor versión de lo que quisiste decir. Especificar bien es la única palanca que mueve esa distribución, y por eso veo Spec-Driven Development como el escalón previo a AI-DLC, no como su competidor.

El camino del copiloto a AI-DLC

1. 1

   Scrum con copiloto

   "Autocompletado dentro del proceso que ya tienes."

   → Escribes más rápido. Misma estructura.

2. 2

   Scrum con SDD dentro de la tarea

   "Mantén el sprint, pero especifica antes de dejar que el agente construya."

   → El equipo aprende a escribir y juzgar specs.

3. 3

   SDD con agente supervisado

   "El agente construye desde la spec; tú verificas contra ella."

   → La spec se vuelve contrato, no papeleo.

4. 4

   Gestión y ejecución agénticas

   "El agente planifica y descompone; las personas deciden en los gates."

   → Aquí AI-DLC empieza a pagarse.

5. 5

   Full agéntico, en bolts

   "Horas por porción, no paquetes de dos semanas."

   → La cadencia para la que se diseñó el método.

La mayoría de los equipos que conozco están en el escalón uno o dos y creen que están cerca de la cima, porque ya entregan más rápido que el año pasado. El argumento completo, y cómo saber en qué escalón estás, está en AI-DLC vs Spec-Driven Development.

No adoptes AI-DLC en bloque

AI-DLC es el framework público más completo para construir con agentes. Aun así no le diría a un equipo que lo adopte.

Adoptarlo en bloque es anunciar “ahora hacemos AI-DLC”. La gente va a leer el paper y a ver las charlas, e intenta reproducir un método diseñado por una empresa con otra escala, otra cultura y otro stack. Estudian en lugar de construir. Y cuando no encaja, se culpan a sí mismos o al método.

Trátalo como la góndola de un supermercado. Llévate lo que resuelve un problema que de verdad tienes: artefactos que viven en el repo, gates entre pasos, porciones medidas en horas, la costumbre de dejar que la IA pregunte. Deja el resto. Escribe qué te llevaste, qué dejaste y por qué.

AI-DLC 2 es la prueba de que esa es la postura correcta. Los equipos que adoptaron la versión 1 construyeron capas encima: archivos de estado, retrospectivas, construcción en paralelo, reglas propias. AI-DLC 2 entregó la mayor parte de eso como funciones nativas. La plomería casera quedó obsoleta en una release. Lo que sobrevivió fue el criterio que esos equipos habían codificado: sus reglas contra el vibe coding, su ritual para darle forma a una intención, su sentido de cuándo no usar el método. El argumento está en no adoptes AI-DLC, róbale.

Qué pasa cuando un equipo real lo usa

La documentación describe el método. El rollout agregó esto.

El throughput sube desde el primer día y el cycle time empeora antes de mejorar. El agente produce código al instante, así que los cambios mergeados por dev se disparan. Pero nadie rediseñó el code review para el volumen nuevo, entonces los cambios se acumulan esperando a una persona, y el tiempo entre el primer commit y el despliegue sube antes de bajar. Esa curva en J es lo más predecible de un rollout de AI-DLC, y la razón más común por la que un manager lo mata antes de tiempo. Más en por qué AI-DLC te hace más lento primero.

La context window es una restricción de diseño, no un detalle. Una Inception en un repositorio real llena buena parte de una ventana de un millón de tokens. Los equipos aprendieron a limpiar el contexto en cada gate, nunca en medio de una fase, y a retomar desde el archivo de estado. La calidad caía de forma visible cuando la ventana pasaba de tres cuartos. El código legado lo empeora, porque el agente tiene que hacer ingeniería inversa de lo que existe antes de proponer nada. Todo eso está en AI-DLC en brownfield.

Producto no necesita quedarse en todo el mob. Después de la ingeniería inversa el agente hace una lista larga de preguntas, y la mayoría son técnicas. El patrón que funcionó: los ingenieros responden las técnicas y producto se suma para las dudas de negocio. La guía de Mob Elaboration tiene el resto del ritual.

Las reglas que sostuvieron la calidad eran pequeñas y específicas. Nunca edites a mano el código generado; vuelve al diseño. Empieza las preguntas exploratorias con “Do not update any documents.” Pide la crítica en un contexto limpio, porque el agente defiende lo que escribió. Están reunidas en seis reglas contra el vibe coding dentro de AI-DLC.

Y el trabajo cambia. Los squads se achican hacia pods de un ingeniero y un PM. Ingenieros de backend entregan front-end. El ingeniero sigue siendo dueño del código en producción, porque cuando se rompe de madrugada no es al agente al que llaman. Las matrices de competencias que premian escribir código empiezan a premiar lo equivocado. Eso es del squad al pod, y el lado de la medición está en después de los story points.

Cómo empezar sin perder un trimestre

Una primera corrida de AI-DLC que te enseña algo

Entrada

Un equipo que ya escribe specs y quiere probar AI-DLC

↓

1. REPOHaz que un agente pueda leer el repositorio

   Un AGENTS.md o CLAUDE.md corto con el stack, los patrones, las librerías prohibidas y un ejemplo de cada uno. El código legado sin esto produce adivinanzas.

   ↓
2. PICKElige una feature real, no una corrección de una línea

   Algo que necesite descomposición y decisiones de más de una persona. Lo bastante chico para terminarlo en una semana.

   ↓
3. INSTALLInstala el motor en el agente que ya usas

   aidlc config para tu harness, después aidlc doctor. El setup completo en Claude Code tiene su propia guía.

   ↓
4. RUNCorre el perfil Classic o Feature

   Classic es la ceremonia de la versión 1 y el comienzo más suave. Sesiones de una hora y contexto limpio en los gates.

   ↓
5. MEASURELee el throughput junto al cycle time

   Espera la curva en J. Decide después de unas cuatro semanas si estás aprendiendo o trabado.

↓

Salida

Una feature entregada con el método, y una lista honesta de qué conservar, cambiar o dejar.

El setup concreto, con los comandos, está en AI-DLC con Claude Code. Si tu equipo todavía no especifica, empieza un escalón antes con cómo escribir una spec, o con un kit más liviano como pi-sdd-kit, y vuelve cuando escribir y juzgar specs se sienta normal.

Qué suman los análisis independientes

AWS escribió el método, así que lee a quienes no lo escribieron. La guía de AIDLC de Augment Code mapea los nombres que compiten por el mismo cambio (el AI-DLC de AWS, el agentic software development de Forrester, el ADLC de Cycode) y plantea la elección real como human in the loop contra human on the loop. Wiz lo lee como un problema de seguridad: la velocidad es el activo y el riesgo a la vez, con cerca de un quinto de los paquetes sugeridos por la IA apuntando a dependencias que no existen. Mission Cloud suma la idea de una spec viva, que un agente mantiene sincronizada con el código. El playbook de SDLC AI-native de Anthropic describe la misma cadena de artefactos versionados desde otro proveedor. Todos convergen en lo mismo que me enseñó el rollout: la IA no es la parte difícil. Las personas en los gates sí. Mi versión de campo del ciclo completo, escrita en el orden en que lo adoptas, es el playbook de agentic SDLC.

Preguntas frecuentes

¿Qué significa AI-DLC?+

AI-Driven Development Life Cycle, el ciclo de vida de desarrollo guiado por IA. Es un método de desarrollo de software que AWS publicó en julio de 2025, en el que un agente de IA planifica el trabajo y produce los artefactos mientras las personas los aprueban o rechazan en los gates. La implementación open source está en github.com/awslabs/aidlc-workflows.

¿AI-DLC es solo para AWS?+

No. El método no depende del proveedor, y AI-DLC 2 corre dentro de Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode y GitHub Copilot con el mismo motor.

Quedan las huellas de AWS: uno de los 14 agentes es especialista en plataforma AWS, y vienen servidores MCP opcionales de AWS. En otra nube los ignoras o los reemplazas.

¿AI-DLC reemplaza a Scrum o a Agile?+

Reemplaza los rituales, no los valores. Los sprints se vuelven bolts medidos en horas, el planning se vuelve Mob Elaboration y la daily se reduce a unos minutos. Kanban encaja mejor que los sprints.

Los equipos que intentaron mantener sprints de dos semanas alrededor de un agente vieron al agente esperando al calendario.

¿Cuál es la diferencia entre AI-DLC y Spec-Driven Development?+

Spec-Driven Development es una práctica: escribe la spec, deja que el agente construya desde ella, verifica contra ella. AI-DLC es un ciclo completo que asume que tu equipo ya hace eso, y le suma fases, gates, agentes y rituales de equipo. SDD es el prerrequisito, no la alternativa.

¿Qué es un Bolt en AI-DLC?+

Un Bolt es la porción de entrega que reemplaza al sprint: trabajo medido en horas o días en lugar de semanas. En AI-DLC 2 es una porción planificada sobre una o más Units dependientes, y el orden de construcción sigue el grafo de dependencias entre Units.

¿Necesito Kiro para usar AI-DLC?+

No. Kiro fue la primera casa de los steering files de AI-DLC, pero AI-DLC 2 trata siete harnesses como de primera clase, incluidos Claude Code, Cursor y Codex.

¿AI-DLC es gratis?+

Sí. Los workflows son open source bajo la licencia MIT-0. Pagas el modelo que usa tu agente, y una corrida de AI-DLC lee y escribe mucho contexto, así que vigila la cuenta de tokens en las primeras corridas.

¿Cuándo no usar AI-DLC?+

Cuando ya sabes exactamente qué cambiar. Una corrección de una línea, un typo, un ajuste de configuración. El método se paga cuando el trabajo necesita descomposición y decisiones de más de una persona. Por debajo de eso, usa un perfil más liviano como Bugfix o Express, o simplemente escribe el código.

A dónde ir ahora

AI-DLC es la respuesta pública más clara hasta ahora a la pregunta que se hace todo líder de ingeniería: cómo construir software con agentes sin perder el control de lo que llega a producción. La respuesta no son los agentes. Son los gates, los artefactos y las personas capaces de juzgarlos. Pon a tu equipo a especificar primero, llévate del método lo que encaje y mide con honestidad cuando la curva se hunda.