El punto ciego de AI-DLC: de dónde sale la Intent
AI-DLC convierte una intent en software con disciplina de verdad, y asume que la intent era correcta. Casi nunca lo es. Por qué los errores del principio se multiplican, por qué el workflow por defecto se salta la fase pensada para atraparlos, y el ritual de upstream que cierra el hueco: cinco preguntas, un triaje de complejidad, un índice curado de fuentes y un resultado como criterio de éxito.
AI-DLC convierte una intent en software con disciplina de verdad. Nada en el método comprueba si valía la pena construir esa intent.
Todo workflow de AI-DLC empieza con una Intent: la declaración de qué hay que lograr y por qué. El método, tal como AWS lo presentó, la define en una frase. El agente la descompone en Units, las piezas independientes en las que se divide el trabajo, las Units se vuelven código, y una docena de gates humanos revisa cada paso del camino. Es una máquina cuidadosa. También es una máquina que asume que la primera entrada era correcta.
De esa suposición salió la mayor parte del dolor que vi. En el rollout que seguí dentro de una gran organización de ingeniería, los equipos que sufrieron con AI-DLC casi nunca sufrieron con el agente. Sufrieron porque lo que entró arriba era vago, viejo o apuntaba al resultado equivocado, y el método lo procesó fielmente hasta el final.
El whitepaper es honesto sobre la división del trabajo. Las personas fijan el destino. La IA da las indicaciones. Lo que no dice es cómo un equipo llega a un destino que valga el viaje. Ese es el hueco del upstream, y este artículo trata del ritual que lo cierra.
Los errores en la intent se multiplican
En un workflow de AI-DLC, cada fase lee la salida de la anterior como contexto. Los requisitos se construyen a partir de la intent. Las historias, a partir de los requisitos. Las Units, a partir de las historias. El código, a partir de las Units. Esa cadena es lo que hace que el método sea trazable. También es lo que hace caro un mal comienzo.
Una intent vaga no produce código vago. Produce código seguro de sí mismo. El agente llena cada hueco que encuentra con la respuesta estadísticamente más probable, y cada fase siguiente trata esa respuesta como un hecho decidido. Para cuando el error aparece en un code review, ya quedó codificado en requisitos, historias, un modelo de dominio y unos cuantos miles de líneas de implementación.
El whitepaper llama a cada revisión humana una función de pérdida (loss function): un punto donde una decisión equivocada se poda antes de crecer. Lleva esa lógica hasta el final y la intent es la función de pérdida más valiosa de todo el ciclo, porque es la que tiene más trabajo colgando después. Una decisión equivocada en la intent se corrige más barato en la propia intent. Cada gate posterior cobra más por la misma corrección.
AI-DLC 2 sumó Ideation, y la mayoría de las corridas se la salta
AWS vio el hueco con claridad. AI-DLC 2 sumó una fase entera antes de la Inception (la fase en la que se deciden requisitos y diseño), llamada Ideation, con siete etapas: Intent Capture and Framing, Market Research, Feasibility and Constraints, Scope Definition, Team Formation, Rough Mockups y Approval and Handoff.
Intent Capture está bien diseñada. El agente de producto pregunta por el problema de negocio, el cliente, las métricas de éxito, el disparador de la iniciativa y quién tiene autoridad de decisión. Cada línea relevante de la declaración de intent resultante lleva una etiqueta que dice de dónde salió: tu descripción original, una respuesta concreta que diste, una regla guardada del equipo o una suposición. Las suposiciones hay que confirmarlas de forma explícita, y confirmar una mantiene la etiqueta. No convierte una conjetura en un hecho. Esa es exactamente la disciplina que necesita el upstream.
Ahora mira qué workflows la corren de verdad.
Qué perfiles de AI-DLC 2 corren Ideation
| Perfil de workflow | Ideation |
|---|---|
| Feature, Enterprise | Las siete etapas |
| MVP | Una versión liviana: intent, factibilidad, alcance, mockups |
| Proof of concept | Solo una captura mínima de intent |
| Classic, Express, Bugfix, Refactor, Infrastructure, Security patch, Workshop | Se salta entera |
Tiene sentido para un bugfix, donde el problema es el bug. Tiene menos sentido para los muchos equipos que empiezan con Classic porque es el valor por defecto y se parece a la versión 1. En esas corridas, la intent es la frase que escribiste después de /aidlc, más lo que el agente deduzca de tu repositorio.
Y ni siquiera la fase completa de Ideation puede hacer la parte más difícil. Estructura lo que alguien en la sala sabe. No descubre lo que nadie sabe. Si el PM no está seguro de que valga la pena resolver el problema, siete etapas bien diseñadas van a producir una intent perfectamente etiquetada para un problema incierto.
Cinco preguntas antes del primer prompt
Los equipos a los que les fue bien tenían algo listo antes de que empezara AI-DLC: un documento de entrada. Algunos lo llamaban six-pager, por la costumbre de Amazon de escribir memorandos narrativos. El nombre no importa. Las preguntas sí.
La intent tiene que responder cinco preguntas
- Obligatorio:¿Cuál es el problema?Escrito como algo que duele hoy, no como una feature a construir.
- Obligatorio:¿Para quién?Un usuario o grupo de clientes real. 'Los usuarios' no es una respuesta.
- Obligatorio:¿Qué resultado esperamos?Qué va a ser distinto cuando esto llegue a producción.
- Obligatorio:¿Cuáles son las restricciones?Plazos, regulación, sistemas que no se pueden tocar, presupuesto y lo que queda explícitamente fuera del alcance.
- Obligatorio:¿Cómo vamos a saber que funcionó?Una métrica que se mueve, no un entregable que pasa a existir. Más sobre esto abajo.
Nada de esto es nuevo. Es pensamiento de producto, y la buena gente de producto siempre lo hizo. Lo que cambió es el costo de saltárselo. Cuando un equipo de personas construía a partir de un ticket vago, la vaguedad se resolvía despacio, en cien conversaciones pequeñas. Cuando un agente construye a partir de una intent vaga, resuelve la vaguedad al instante, por su cuenta, y anota el resultado como si alguien lo hubiera decidido.
Aquí también es donde Spec-Driven Development se gana su lugar como el escalón previo a AI-DLC. Un equipo que practicó escribir specs, con el porqué, el qué y el alcance negativo explícito, ya sabe responder estas cinco preguntas. Un equipo que no lo practicó va a encontrar las preguntas más difíciles que el código.
Deja que el tamaño del problema decida cuánto hace la IA
Una de las mejores ideas que vi en el rollout vino de quienes usaban las herramientas de upstream, no de quienes las construían. Una persona de producto y una de diseño, que las probaron temprano, pidieron un paso de triaje antes que nada: clasificar el problema primero y después decidir cuánto puede hacer el agente.
El triaje no cambia cuántas preguntas hace el agente. Cambia lo que el agente tiene permitido generar por su cuenta.
Triaje de complejidad antes de la intent
| Complejidad | Qué hace el agente | Qué hace la persona |
|---|---|---|
| Baja | Corre el discovery de punta a punta y entrega un borrador de intent. | Lo lee y lo aprueba o lo corrige. |
| Media | Guía sección por sección, con una revisión después de cada una. | Responde y aprueba cada sección antes de la siguiente. |
| Alta, muchos stakeholders | Solo facilita. Organiza la conversación y nunca genera estructura por su cuenta. | Es dueña de cada decisión. El agente toma notas. |
El anti-pattern aquí es el atajo en la dirección contraria. El agente clasifica el problema como de alta complejidad, alguien fuerza la clasificación para conseguir más rápido un borrador autónomo completo, y el borrador sale con agujeros del tamaño de los stakeholders a los que nadie consultó. Esos agujeros entran al ciclo como una intent vaga, y ya sabes lo que pasa después.
Dale al agente un índice curado, no toda la wiki
Toda empresa tiene una wiki llena de documentos. Algunos están vigentes. Muchos no. Un agente con acceso a todo no puede distinguirlos, y va a construir tu intent sin ningún problema sobre una decisión que la empresa revirtió hace dos años.
Lo vi pasar en vivo. Durante una demo de un agente de discovery de upstream, trajo un documento de 2022 al contexto de un proyecto actual. La persona de producto que conducía la demo conocía el dominio, lo notó y lo corrigió. Alguien con menos contexto lo habría aprobado, porque se veía exactamente como un documento relevante.
La solución que usó el equipo no tiene glamour y funciona: un índice curado por área de la wiki, mantenido a mano, que enumera las fuentes que el agente puede tratar como confiables. El agente lee el índice primero y solo sigue enlaces desde ahí. Armar el índice es trabajo aburrido. También es la condición previa para confiar en cualquier cosa que el agente escriba en el upstream, por la misma razón por la que un buen AGENTS.md importa en el downstream: el agente es tan bueno como el contexto que eliges darle.
Un criterio de éxito es un resultado, nunca un artefacto
Este fue el error más común que vi cometer al agente, y el que más chances tiene de pasar frente a alguien que revisa cansado.
En una sesión en vivo, una persona de producto estaba dando forma a la intent de un backoffice interno que iba a reemplazar una herramienta paga de un proveedor. El agente redactó los criterios de éxito y escribió, en esencia, que el éxito era que la documentación estuviera completa. La persona lo frenó y lo discutió. La documentación era el entregable de este paso. El éxito de la feature era recortar el costo del proveedor y responder a un movimiento que había hecho un competidor. Que exista un documento no es un resultado de negocio.
Tenía razón, y el agente aceptó la corrección. Pero mira lo plausible que era la versión equivocada. “Documentación completa” y “épica creada” son cosas que un equipo produce, así que parecen avance. Miden actividad. Una intent cuyo criterio de éxito es un artefacto va a producir un ciclo optimizado para producir ese artefacto.
Criterios de artefacto (recházalos)
- 01La documentación está completa
- 02La épica está creada en el tracker
- 03La API está desplegada
- 04Las pantallas coinciden con los mockups
Criterios de resultado (pide estos)
- 01El contrato con el proveedor se puede cancelar
- 02El abandono del checkout baja en mobile
- 03Bajan los tickets de soporte sobre reembolsos
- 04El onboarding toma un día en lugar de cinco
La misma sesión dejó dos lecciones más chicas. Primero, el agente deduce trabajo a partir de palabras clave. El competidor se había mencionado al pasar, así que el agente empezó un benchmark competitivo que nadie necesitaba. Di explícitamente qué queda fuera del alcance, o el agente va a inventar alcance a partir de tu vocabulario. Segundo, cuando esa búsqueda de benchmark falló por un error de red, el agente dijo que no iba a inventar datos. Eso es una buena señal. Si el tuyo fabrica un análisis de mercado cuando una fuente no responde, tienes un problema más grande que la intent.
La completitud le gana al formato
Las herramientas de upstream suelen producir un documento de resumen prolijo, y la suposición natural es que el resumen es la entrada del downstream. Un equipo aprendió lo contrario. El resumen que generó su proceso de upstream había recortado contexto que tenía el ticket original, y dedicaron bastante tiempo a recuperarlo durante la Inception.
La lección que anotaron: AI-DLC no necesita un formato específico como entrada. Necesita la información más completa disponible. Si el ticket original tiene más detalle que el resumen, dale el ticket. Dale los dos. Registra qué documentos le pasaste, para que la próxima persona sepa lo que sabía el agente. Un resumen se escribe para comunicar una decisión a personas. No se escribe para preservar cada restricción que va a necesitar un agente.
Convincente no es lo mismo que correcto
Alguien de producto en el rollout explicó el riesgo del discovery generado por IA con una analogía que repito siempre. Cuando te llega un correo de tu banco, lo miras con cuidado. ¿El enlace está bien? ¿El logo está torcido? Un six-pager generado es el caso opuesto. Se parece tanto a uno real que dejas de tener cuidado. Y después lo lees de verdad y te das cuenta de que no hay nada.
Cuanto mejor es el formato, menos lee la gente. Por eso la intent necesita la firma de una persona con nombre y conocimiento del dominio antes de que empiece cualquier cosa en el downstream. En las sesiones que vi, las personas más senior interrogaban cada afirmación del agente y tardaban más. Las menos experimentadas aceptaban el primer borrador y seguían. Para un equipo sin esa experiencia, armen pares: una persona conduce la sesión y otra que conoce el dominio aprueba el resultado.
El ritual de upstream antes de que empiece AI-DLC
Entrada
Un problema que alguien cree que vale la pena resolver
- TRIAGEClasifica el problema
La complejidad baja, media o alta decide cuánto puede generar el agente por su cuenta.
- SOURCESApunta el agente a fuentes curadas
Un índice de documentos confiables, no toda la wiki. Adjunta el material más completo que tengas.
- FIVEResponde las cinco preguntas
Problema, para quién, resultado esperado, restricciones con lo que queda fuera explícito y una métrica de resultado.
- SIGNAlguien dueño del dominio firma la intent
Alguien que detectaría una regla vieja o un artefacto disfrazado de criterio de éxito.
Salida
Una intent que vale la pena descomponer. Ahora la Inception tiene algo real con qué trabajar.
La intent es la primera mitad de una spec
Si leíste otras cosas que escribo, ya ves hacia dónde va esto. La intent es la capa de arriba de una spec: el porqué y el qué, antes del cómo. En el workflow de Spec-Driven Development que uso, esa capa es el documento de requisitos de producto, y se aprueba antes de tomar cualquier decisión de diseño. Cómo escribir una spec cubre el formato en detalle.
AI-DLC 2 se acerca a eso con Ideation, y las etiquetas de origen en cada afirmación son una buena idea. Pero una fase que se puede saltar no es un hábito, y el workflow por defecto la salta. El hábito tiene que vivir en el equipo. Si tu gente no puede responder las cinco preguntas por su cuenta, el método las va a responder por ti, y va a responder con el promedio de todo lo que leyó.
Preguntas frecuentes
¿Qué es una Intent en AI-DLC?
Una Intent es la entrada inicial de un workflow de AI-DLC: una declaración de alto nivel de qué hay que lograr y por qué, ya sea un objetivo de negocio, una feature o un resultado técnico. La IA la descompone en Units de trabajo. En AI-DLC 2, cada Intent también tiene su propia carpeta en el repositorio, donde se guardan todos los artefactos, decisiones y registros de auditoría de ese trabajo.
¿Cuál es la diferencia entre una Intent y una Unit?
La Intent es el porqué: una declaración de propósito. Una Unit es una parte del cómo: una pieza autocontenida de la solución, derivada de la Intent, que se puede construir y desplegar sola. Una Intent suele producir varias Units.
¿AI-DLC necesita un PRD o un six-pager?
El método no exige un documento específico. Necesita la información más completa disponible sobre el problema, en el formato que use tu equipo.
En la práctica, los equipos que llegaban con un documento de entrada estructurado, respondiendo problema, usuarios, resultado, restricciones y métrica de éxito, tuvieron mucho menos retrabajo que los equipos que escribían una frase después del comando.
¿La fase de Ideation corre en todos los workflows de AI-DLC 2?
No. Feature y Enterprise corren las siete etapas de Ideation, MVP corre una versión liviana y Proof of concept corre una captura mínima de intent. Classic, que es el valor por defecto cuando no eliges un perfil, se salta Ideation entera, igual que Express, Bugfix, Refactor, Infrastructure, Security patch y Workshop.
¿Qué tan larga debería ser una intent?
Lo necesario para responder las cinco preguntas con honestidad. Para una tarea chica, un párrafo. Para una iniciativa entre equipos, unas cuantas páginas. La extensión no es la prueba. La prueba es si alguien sin contexto puede decir qué problema estás resolviendo, para quién y cómo vas a saber que funcionó.
¿Cuál es el error más común en una intent generada por IA?
Un criterio de éxito que es un artefacto en lugar de un resultado: 'documentación completa' o 'épica creada' en lugar de una métrica de negocio que se mueve. El segundo más común es información vieja sacada de una wiki sin curar.
A dónde ir ahora
AI-DLC es excelente para convertir una buena intent en buen software, e indiferente a si la intent era buena. Esa parte sigue siendo tuya. Haz el triaje del problema, cura las fuentes, responde las cinco preguntas y pon a alguien que conozca el dominio a firmar antes de que arranque la máquina.
La newsletter
Don’t Code, Specify. Cada semana, agentes de IA en producción de verdad. Sin hype: lo que funcionó y lo que se rompió.
Suscríbete en Substack (se abre en una pestaña nueva)