Los gates son una función de pérdida. Estas son las cuatro formas en que fallan.

Un gate es una persona leyendo. Todo lo que hace que una persona lea peor hace peor al gate, y AI-DLC produce mucho para leer.

El noveno principio del whitepaper de AI-DLC dice que las validaciones humanas “actúan como una forma de función de pérdida” (loss function), identificando y podando el trabajo desperdiciado más adelante antes de que ocurra. Es la mejor frase del método. Explica por qué AI-DLC se detiene después de cada etapa y te espera, y por qué esa pausa es ingeniería y no burocracia.

También es donde el método es más débil, y la documentación no lo dice. El gate es una persona, y la IA produce artefactos mucho más rápido de lo que una persona puede leerlos con cuidado. En el rollout que seguí dentro de una gran organización de ingeniería, los gates fallaron de cuatro formas, una y otra vez, y ninguna era un bug de la herramienta.

Este artículo trata de esas cuatro fallas y de los hábitos que las resisten.

Qué hace una función de pérdida en un gate

En machine learning, una función de pérdida mide qué tan equivocada está la salida de un modelo, para que el entrenamiento la corrija. El whitepaper toma prestada la idea. En cada gate, una persona mide qué tan equivocado está el artefacto, para que el workflow lo corrija antes de que la siguiente etapa construya encima.

La razón por la que importa es el efecto compuesto. En AI-DLC cada etapa lee la salida de la anterior como contexto. Un requisito vago no queda contenido en la etapa de diseño. Se multiplica: el diseño codifica la vaguedad como decisión, las Units codifican el diseño y el código codifica las Units. Una ambigüedad que costaba un comentario corregir en el gate de requisitos cuesta un rediseño en el gate de arquitectura y una reescritura en el code review.

La misma decisión equivocada, atrapada en gates distintos

El valor del gate no es atrapar errores. Es atraparlos en la capa más barata.

Dónde se atrapa	Cuánto cuesta corregirla
En el gate de intent y requisitos	Un comentario y un documento regenerado. Minutos.
En el gate de arquitectura	Un diseño nuevo y ADRs nuevos antes de que exista código.
En el code review	Reescribir una Unit que ya pasa sus pruebas.
En producción	Un incidente, y después todo lo anterior.

Qué revisa AI-DLC 2 antes de preguntarte

Una persona en el gate es la última capa, no la única. AI-DLC 2 apila varios chequeos para que, cuando un artefacto llega a ti, los problemas mecánicos ya estén fuera del camino y tu atención pueda ir al criterio.

Chequeos que corren antes y durante un gate en AI-DLC 2

1. 1

   Sensores

   Chequeos determinísticos, como un linter o un type check, que se disparan sobre los archivos que escribe una etapa. Algunos solo avisan, otros bloquean hasta que se corrija.

   +
2. 2

   Agentes revisores

   Dos agentes que solo revisan juzgan requisitos, historias y mockups, o el diseño técnico, y escriben un veredicto READY o NOT-READY con hallazgos. Nunca bloquean. Decide la persona.

   +
3. 3

   Gates de verificación

   Chequeos automáticos de trazabilidad entre fases: cada requisito se convierte en una historia, nada quedó huérfano, los artefactos concuerdan entre sí.

   +
4. 4

   Tu aprobación

   Al final de toda etapa fuera de Initialization: Approve o Request Changes, con tus palabras. Nada avanza hasta que respondas.

Fíjate en lo que hacen los agentes revisores. Ante un NOT-READY adversarial, la etapa vuelve a correr, hasta dos veces por defecto, y lo que siga sin resolver llega a tu gate como hallazgos. Es un buen diseño: saca los problemas obvios antes de que te cuesten atención. También tiene un efecto secundario que vale la pena nombrar. Un gate que llega con una revisión limpia adjunta parece más confiable de lo que es. Un veredicto READY de un agente revisor es la opinión de un modelo sobre el trabajo de otro modelo. Útil, y no es lo mismo que una persona que conoce el dominio diga que sí.

Construction tiene su propia variante. En AI-DLC 2 apruebas cada Unit en un checkpoint verificado, y la verificación corre un comando que autorizaste una vez. Después de eso puedes elegir “Continue automatically” para los checkpoints comunes. La aprobación del plan de cada Unit, la elección del comando de verificación y cada falla siguen volviendo a una persona. El motor traza la línea entre lo que se puede delegar y lo que no. La pregunta es si la persona del otro lado de esa línea todavía está leyendo.

Falla uno: el artefacto parece completo y no dice nada

La primera falla es la más peligrosa porque parece un éxito.

Una persona líder de producto con la que trabajé durante el rollout lo explicó con una analogía que ahora uso en todas partes. Te llega un correo de tu banco. Tiene el logo, los colores correctos, el tono formal. Como todo parece familiar, dejas de revisar el link. La familiaridad apaga tu escepticismo, que es justo con lo que cuenta un correo de phishing.

Un documento de requisitos generado hace lo mismo. Tiene las secciones correctas, los títulos correctos, los criterios de aceptación en el formato correcto. Reconoces la forma de un buen documento y tu cerebro lo marca como bueno. Después lo lees de verdad, frase por frase, y no hay nada. Relleno plausible con forma de spec.

La estructura de un documento es fácil de enseñarle a un modelo. El contenido de tu dominio no. Entonces el modelo produce de forma confiable la parte que revisas de un vistazo, y de forma poco confiable la parte que solo revisas leyendo.

Falla dos: quien revisa está cansado

La segunda falla es aritmética. El agente genera un documento de requisitos, un conjunto de historias, un diseño de dominio y una lista de Units en minutos. Una persona necesita tiempo de verdad para leer cada uno con cuidado, y la atención se acaba mucho antes que los documentos.

En el rollout, el límite estaba en alrededor de una hora. Alguien de ingeniería describió el momento con precisión después de una Inception larga: cuando llegaron los últimos documentos, ya no le quedaba cabeza para revisarlos, y paró, porque si no iba a empezar a aprobar cualquier cosa. Esa es la versión honesta. La mayoría de la gente no para. Sigue haciendo clic en Approve, y el gate sigue registrando una decisión que nadie tomó.

Falla tres: quien revisa no conoce el dominio

La tercera falla sorprendió más de lo que debía. Los ingenieros y la gente de producto con el conocimiento más profundo del dominio tardaban más en los gates. Interrogaban cada afirmación, discutían con el agente y reescribían sus criterios de éxito. Las personas con menos conocimiento del dominio eran más rápidas. Aceptaban la primera salida.

Es lo contrario de la historia de siempre, de que la IA ayuda más a los juniors. En un gate, cuanto menos sabes, más confías, porque no tienes con qué comparar la salida. Los investigadores lo llaman sesgo de automatización, y está documentado en los estudios de factores humanos desde los años 90: la gente confía de más en las salidas automatizadas, sobre todo cuando parecen autorizadas.

La consecuencia práctica para AI-DLC es sobre quién está en qué gate. Un ingeniero junior puede correr un workflow. Un ingeniero junior no debería ser el único aprobador de un documento de requisitos en un dominio al que llegó el mes pasado. Dale tiempo a la gente para aprender el dominio antes de convertirla en gate, y hasta entonces junta a quien opera con poco dominio con alguien que revisa con mucho.

Falla cuatro: la décima aprobación

La cuarta falla es la confianza que se calibra con el historial. El agente acertó las primeras nueve veces hoy, así que el décimo artefacto recibe un vistazo. Nada del décimo es distinto. Tu atención sí.

Esta es difícil de ver desde adentro, y por eso necesita una respuesta mecánica en lugar de buenas intenciones. Sellar por agotamiento no es un defecto de carácter. Es lo que hace la atención bajo repetición, y la única defensa es un hábito que obligue a una lectura de verdad, sin importar cómo salieron las nueve anteriores.

La regla de una frase

Este es el hábito. Antes de aprobar cualquier artefacto, di en una frase con qué te compromete y por qué está bien. En voz alta, en el chat o a la persona de al lado.

Si puedes decirla, lo leíste. Si no puedes, no terminaste, y la respuesta es seguir leyendo o preguntarle al agente, no hacer clic en Approve. Suena trivial. Es el control más barato que conozco para convertir un sello en una decisión otra vez, porque no puedes resumir un documento que leíste por encima sin darte cuenta de que lo leíste por encima.

Preguntas que vuelven real un gate

1. 01

   Haz que el artefacto explique sus compromisos.

   Un resumen en las palabras del agente te muestra lo que cree que construyó. Compáralo con lo que creías haber pedido.

   Escribe esto

   Before I approve: in one sentence, what does this document commit us to? Then list every assumption in it that did not come from my answers.

2. 02

   Cuestiona los criterios de éxito.

   Los agentes tienden a definir el éxito como la existencia de un artefacto. El éxito es un resultado para el negocio. Si el criterio es un entregable, es el criterio equivocado.

   Escribe esto

   The success criterion you wrote is a deliverable. Rewrite it as an outcome we can measure after release.

3. 03

   Pide la segunda opinión en un contexto limpio.

   En la misma sesión, el agente defiende las decisiones que tomó. Con solo el artefacto delante, las critica.

   Escribe esto

   /clear, then load only the artifact and ask: Produce a critique of this as if you hadn't written it.

4. 04

   Detente cuando notes que estás aprobando más rápido.

   El archivo de estado hace que pausar no cueste nada. Una aprobación hecha en la segunda hora de una sesión vale menos que una hecha mañana a primera hora.

   Escribe esto

   Stop here. Commit what is approved, and we continue this stage in the next session.

El ritmo es una decisión de diseño, no una soft skill

Las cuatro fallas empeoran con la velocidad. Por eso las contramedidas más eficaces del rollout fueron de ritmo, no de herramientas.

Mantén las sesiones de aprobación en alrededor de una hora. Divide una Inception larga en dos sesiones, en días distintos, en lugar de una maratón de tres horas. Nunca encadenes Inception y Construction en la misma sentada para ganar tiempo: las decisiones aprobadas por un equipo cansado en la Inception se vuelven retrabajo en Construction, y el retrabajo cuesta más de lo que habría costado una segunda sesión. Y pon al manager en los primeros mobs con la tarea explícita de pedir la pausa, porque un equipo presionado para parecer productivo no la va a pedir solo.

Nada de esto hace más lento el método de una forma que importe. AI-DLC guarda el estado en archivos, así que un workflow en pausa sigue exactamente donde se detuvo. Lo único que pierdes al pausar es la ilusión de que aprobar más rápido era avanzar más rápido.

Human in the loop, human on the loop

Debajo de todo esto hay una pregunta más grande: ¿cuánto debería aprobar una persona, en definitiva?

Kief Morris trazó la distinción con claridad en Humans and Agents in Software Engineering Loops. Una persona in the loop aprueba cada paso. Una persona out of the loop está haciendo vibe coding. Una persona on the loop diseña y mejora el sistema dentro del cual corren los agentes, el harness, y supervisa los resultados en lugar de cada acción. La guía de AIDLC de Augment Code lo plantea como la decisión central de operación: in the loop para decisiones de alto riesgo, on the loop para trabajo validado y bien acotado.

Human in the loop

1. 01Aprueba cada etapa y cada artefacto
2. 02Correcto para trabajo de alto riesgo, ambiguo o regulado
3. 03Se desarma cuando el volumen de artefactos supera la atención

Human on the loop

1. 01Diseña los gates, las reglas y los chequeos dentro de los que corren los agentes
2. 02Supervisa los resultados e interviene en las fallas
3. 03Solo es seguro cuando los chequeos pueden cargar la confianza que quitaste

AI-DLC 2 ya te deja hacer ese paso en un lugar acotado: elegir “Continue automatically” para los checkpoints comunes de Construction es pasar de in the loop a on the loop en esa parte del trabajo. Es el movimiento correcto cuando la Unit tiene un comando de verificación de verdad, pruebas que significan algo y sensores que atrapan los problemas mecánicos. Es el movimiento equivocado cuando lo único entre el agente y tu rama principal es una persona cansada que dejó de leer hace una hora.

Esa es la regla general, y es la misma que está detrás de harness engineering: te ganas el derecho a aprobar menos haciendo que el sistema chequee más. El entusiasmo no cuenta como verificación.

Preguntas frecuentes

¿Qué significa human on the loop?+

Una persona on the loop supervisa los resultados de un proceso automatizado y diseña las reglas y los chequeos dentro de los que corre, en lugar de aprobar cada paso individual. Una persona in the loop aprueba cada paso.

En términos de AI-DLC, aprobar cada etapa es in the loop. Dejar que los checkpoints verificados de Construction avancen solos mientras tú te ocupas de los planes y las fallas es on the loop.

¿Cuál es la diferencia entre un gate de aprobación y un gate de verificación en AI-DLC?+

Un gate de aprobación cierra toda etapa fuera de Initialization y espera a que una persona responda Approve o Request Changes. Un gate de verificación corre entre fases y es automático: chequea que los artefactos sean trazables y consistentes, por ejemplo que cada requisito se convierta en una historia. Uno chequea criterio, el otro chequea vínculos.

¿Puedo desactivar los gates de aprobación en AI-DLC 2?+

En parte. En Construction puedes dejar que los checkpoints comunes de Unit corran solos. La aprobación del plan de cada Unit, la elección del comando de verificación y cada falla siguen requiriendo a una persona, y el guard de presencia humana no se puede bajar para un solo workflow. El alcance que eliges también decide qué etapas corren, y una etapa que no corre no tiene gate.

¿Los agentes revisores reemplazan el review humano?+

No. AI-DLC 2 tiene dos agentes que solo revisan y escriben un veredicto READY o NOT-READY con hallazgos, y ante un NOT-READY adversarial la etapa vuelve a correr hasta dos veces por defecto. Nunca bloquean, y la decisión es de la persona. Son buenos atrapando problemas obvios, y sus veredictos limpios pueden hacer que un artefacto débil parezca más confiable de lo que es.

¿Cuánto debería durar una sesión de aprobación?+

Alrededor de una hora. En el rollout que seguí, las aprobaciones después de la primera hora leyendo documentos generados se volvieron sellos. Divide las Inceptions largas en varias sesiones. El archivo de estado hace que la pausa no cueste nada.

¿Quién debería aprobar un gate de AI-DLC?+

Alguien que conozca el dominio lo suficiente para discutirle al agente. Quien revisa con poco dominio acepta la primera salida; quien revisa con mucho dominio la interroga. Hasta que una persona conozca el dominio, júntala con alguien que lo conozca.

A dónde ir ahora

El whitepaper tiene razón: un gate es una función de pérdida, y es el lugar más barato para atrapar una decisión equivocada. Pero una función de pérdida que dejó de medir es solo una demora. Mantén las sesiones cortas, haz que el agente declare sus supuestos, usa la regla de una frase, y pasa un gate de in the loop a on the loop solo cuando haya verificación de verdad detrás.