Construye una secuencia de cambios con intervención humana | Curso de desarrollo de videojuegos con IA

2055. Identidad de la lección

Módulo: 5.3 — Orquestación de IA
Lección: Construye una secuencia de cambios con intervención humana
Tipo académico: Flujo de trabajo
Tipo de esquema: Mixto
Orden: 2
Tiempo estimado: 35–45 minutos

Esta lección convierte una pasada supervisada de IA en una secuencia operativa explícita. Decidirás qué puede inspeccionar, proponer, ejecutar, validar o escalar la IA, y dónde una persona debe aprobar o poder recuperar el trabajo.

2056. Objetivo de aprendizaje

Después de esta lección, podrás marcar de forma coherente los límites de autoridad Inspeccionar, Proponer, Ejecutar, Validar y Escalar, junto con las condiciones de detención, los puntos de aprobación, una línea base de recuperación previa al cambio y un punto de control de implementación posterior a la ejecución.

2057. Por qué importa

Una secuencia no está realmente supervisada solo porque haya una persona en algún punto del proceso. La supervisión es significativa cuando la autoridad está situada en límites concretos. Sin esos límites, una pasada de IA puede ampliar el alcance sin avisar, reinterpretar una decisión de diseño o continuar cuando la evidencia ya es ambigua. Una línea base de recuperación verificada antes del cambio evita que una implementación incierta sustituya el único estado recuperable conocido. Un punto de control de implementación distinto conserva el estado posterior a la ejecución una vez revisado y antes de iniciar la validación. La secuencia debe proteger tanto la intención del juego como la evidencia asociada específicamente con el cambio que se está revisando.

2058. Conocimientos previos

Debes poder descomponer un cambio en pasadas supervisadas, como se practicó en la Lección 1 del módulo 5.3 — Descomponer un cambio en pasadas supervisadas. También debes poder expresar un objetivo de cambio y criterios de aceptación antes de pedirle una acción a un sistema de IA.

2059. Concepto central

El concepto central es la separación de autoridad: cada pasada debe indicar qué tiene permitido hacer la IA, qué evidencia termina la pasada, qué decisiones requieren inspección o aprobación humana y cómo recuperar la implementación si la validación falla.

Usa cuatro niveles de autoridad y un estado de escalamiento:

Nivel o estado	Lo que puede hacer la IA	Decisión que requiere una persona
Inspeccionar	Leer el contexto pertinente e informar sus hallazgos	Confirmar que el alcance inspeccionado es suficiente
Proponer	Sugerir un plan, parche o prueba	Aprobar, modificar o rechazar la propuesta
Ejecutar	Aplicar un cambio aprobado explícitamente dentro del alcance e informar los archivos realmente modificados	Inspeccionar el diff, resolver cualquier desviación y autorizar el punto de control de implementación
Validar	Ejecutar las comprobaciones acordadas e informar resultados asociados al cambio	Aceptar la evidencia, pedir una investigación o rechazar el cambio
Escalar	Detenerse y presentar incertidumbre, conflicto, fallo o una violación de autoridad	Decidir la siguiente acción o revisar la secuencia de cambio

Validar no es Ejecutar. Ejecutar cambia el proyecto; Validar reúne evidencia sobre ese cambio. Escalar no es un nivel de permiso. Es el estado de detención obligatorio cuando la autoridad asignada es insuficiente o la evidencia no permite continuar.

La IA no obtiene más autoridad solo porque una pasada anterior haya tenido éxito. Cada nueva pasada necesita su propio límite. Una propuesta es una recomendación aún no implementada: no constituye un estado del proyecto ni demuestra que el cambio funcione.

Usa dos artefactos de recuperación distintos. Antes de Ejecutar, una persona verifica una línea base de recuperación previa al cambio con nombre y su instrucción de restauración; solo entonces autoriza la ejecución. Esta línea base conserva el estado del proyecto anterior a la implementación. Después de Ejecutar, la IA informa los archivos realmente modificados y cualquier desviación; una persona inspecciona el diff y autoriza un punto de control de implementación con nombre antes de Validar. Este punto de control conserva el estado posterior a la ejecución que ya fue revisado. Restaurar la línea base abandona la implementación y devuelve el proyecto al estado previo verificado. Restaurar el punto de control de implementación devuelve el proyecto al estado revisado desde el que puede reanudarse la validación. La restauración siempre requiere una decisión humana; no es una acción automática de la IA.

La línea base y el punto de control de implementación son puertas controladas por una persona y artefactos registrados, no niveles adicionales de autoridad de la IA. La evidencia posterior a la implementación —incluidos el registro de archivos modificados, los resultados de validación y la decisión de revisión— debe describir lo que ocurrió realmente, no lo que se había propuesto.

2060. Modelo mental

Usa el modelo INSPECCIONAR → PROPONER → APROBAR LA PROPUESTA → VERIFICAR LA LÍNEA BASE DE RECUPERACIÓN → EJECUTAR → INSPECCIONAR EL DIFF Y AUTORIZAR EL PUNTO DE CONTROL DE IMPLEMENTACIÓN → VALIDAR → ACEPTAR o ESCALAR:

INSPECCIONAR: Establecer los sistemas pertinentes, el comportamiento actual y el alcance aprobado.
PROPONER: Describir el cambio mínimo y las comprobaciones que producirán evidencia sobre ese cambio.
APROBAR LA PROPUESTA: Una persona autoriza, modifica o rechaza la propuesta y su límite de implementación.
VERIFICAR LA LÍNEA BASE DE RECUPERACIÓN: Antes de cualquier edición de implementación, una persona verifica un estado previo al cambio con nombre y una instrucción de restauración usable, y después autoriza Ejecutar. Es una puerta humana, no una pasada de la IA.
EJECUTAR: Aplicar únicamente la implementación aprobada a partir de esa línea base y notificar los archivos realmente cambiados y las desviaciones.
INSPECCIONAR EL DIFF Y AUTORIZAR EL PUNTO DE CONTROL DE IMPLEMENTACIÓN: Una persona comprueba la implementación respecto del alcance aprobado. Si coincide, registra un punto de control con nombre del estado posterior a la ejecución ya revisado, antes de Validar. También es una puerta humana, no un nivel de autoridad de la IA.
VALIDAR: Ejecutar las revisiones y pruebas acordadas, e informar resultados vinculados al cambio solicitado y a los comportamientos que no deben cambiar.
ACEPTAR o ESCALAR: Una persona acepta la evidencia o decide si investiga, revisa la secuencia, restaura el punto de control de implementación o abandona el cambio restaurando la línea base previa.

Una condición de detención debe poder observarse. “Detente si el resultado parece incorrecto” es débil. “Detente si el cambio toca un archivo fuera del alcance aprobado, modifica un valor de ajuste sin criterio de aceptación, no tiene un punto de control recuperable o produce una prueba asociada al cambio que falla” sí es accionable.

2061. Ejemplo concreto

Supón que el cambio es: hacer que un guardia detecte al jugador después de que este cruce un límite de detección.

Una secuencia acotada podría ser:

Paso o puerta	Autoridad de la IA	Condición de detención	Evidencia requerida	Decisión humana
1. Inspeccionar	Inspeccionar	La lógica pertinente está repartida entre sistemas desconocidos o el límite solicitado no está claro	Resumen del comportamiento actual, alcance inspeccionado y preguntas sin resolver	Confirmar el alcance y el resultado esperado para el jugador
2. Proponer	Proponer	La propuesta cambia reglas de detección no relacionadas o inventa una decisión de diseño	Archivos propuestos, criterios de aceptación, comportamientos que no deben cambiar y plan de revisión y pruebas	Aprobar, modificar o rechazar la propuesta
Línea base de recuperación previa al cambio	No aplicable—puerta controlada por una persona	La línea base no existe, no puede restaurarse o no representa el estado anterior a la implementación	Nombre o ubicación de la línea base, resultado de la verificación e instrucción de restauración	Verificar la línea base y autorizar Ejecutar
3. Ejecutar	Ejecutar	Cambia un archivo fuera del alcance, no se puede comprobar un criterio de aceptación o el parche entra en conflicto con el comportamiento existente	Lista de archivos realmente modificados, diff específico del cambio, resultado de la implementación y desviaciones	Inspeccionar el diff; Escalar si existe una desviación o autorizar el punto de control de implementación
Punto de control de implementación	No aplicable—puerta controlada por una persona	La implementación revisada no puede restaurarse o no coincide con el alcance aprobado	Nombre o ubicación del punto de control, instrucción de restauración y diff revisado asociado	Confirmar la recuperación del estado posterior a la ejecución antes de Validar
4. Validar	Validar	Falla una comprobación asociada al cambio, el comportamiento es ambiguo o cambia un comportamiento que debía permanecer igual	Notas de revisión, resultados de pruebas, pasos de reproducción y resultados observados vinculados a este cambio	Aceptar la evidencia o Escalar para modificar, investigar, restaurar o rechazar

La persona no tiene que revisar cada pulsación de tecla. Sí debe aprobar el plan, verificar la línea base de recuperación previa al cambio antes de Ejecutar, inspeccionar el diff resultante, autorizar el punto de control de implementación antes de Validar y decidir qué ocurre cuando la evidencia asociada al cambio es incompleta.

2062. Flujo de trabajo con IA

Escribe la secuencia antes de iniciar una pasada de implementación. Proporciona a la IA el objetivo del cambio, el alcance aprobado, las decisiones prohibidas, las condiciones de detención, la evidencia de revisión y pruebas requerida, el requisito de la línea base de recuperación, el requisito del punto de control de implementación y la respuesta exacta esperada en cada puerta humana.

Un formato útil de instrucción es:

Objetivo: [un cambio observable en el juego]
Alcance aprobado: [sistemas y archivos que la pasada puede inspeccionar o cambiar]
Autoridad de esta pasada: [Inspeccionar, Proponer, Ejecutar o Validar]
No decidir: [decisiones de diseño reservadas para el desarrollador]
Detente y Escala si: [condiciones observables de alcance, autoridad, recuperación o evidencia]
Evidencia requerida: [diff asociado al cambio, notas de revisión, resultado de prueba, informe de comportamiento o pregunta sin resolver]
Línea base de recuperación previa al cambio: [nombre o ubicación, resultado de la verificación e instrucción de restauración requeridos antes de Ejecutar]
Punto de control de implementación: [nombre o ubicación e instrucción de restauración requeridos después de inspeccionar el diff y antes de Validar]
Espera aprobación explícita antes de: [la siguiente pasada o puerta controlada por una persona]

Trata la respuesta de la IA como un informe o una propuesta hasta que el nivel de autoridad asignado permita actuar. Si la respuesta cruza el límite, detén y Escala la secuencia. Pide una pasada más acotada en lugar de aceptar trabajo adicional solo porque parece útil. No comiences Ejecutar hasta que una persona haya aprobado la propuesta y verificado la línea base de recuperación previa al cambio. Después de Ejecutar, la IA debe informar los archivos realmente modificados y cualquier desviación. No comiences Validar hasta que una persona haya inspeccionado ese diff y autorizado un punto de control de implementación con nombre que conserve el estado posterior a la ejecución ya revisado.

2063. Error común

El error común es colocar una única aprobación al final de toda la tarea. Una revisión final no puede recuperar de forma fiable el razonamiento detrás de una ampliación de alcance no aprobada o de una decisión de diseño que pasó inadvertida. Los puntos de aprobación deben aparecer antes de las transiciones importantes: al confirmar el alcance inspeccionado, al aprobar la propuesta, al autorizar Ejecutar desde una línea base de recuperación verificada, y al autorizar el punto de control de implementación y Validar después de inspeccionar el diff.

Otro error es tratar Validar como permiso para cambiar más código. Validar reúne evidencia de revisión y pruebas; no amplía el alcance ni repara silenciosamente la implementación. Si la validación revela un fallo, ambigüedad, un artefacto de recuperación ausente o un cambio en un comportamiento que no debía modificarse, la IA debe Escalar. Una persona decide entonces si restaura el punto de control de implementación e investiga, restaura la línea base previa y abandona la implementación, revisa los criterios o autoriza una nueva pasada de Proponer.

Un tercer error es registrar evidencia genérica, como “el juego funciona”. La evidencia debe estar asociada al cambio solicitado: debe identificar qué se revisó, qué prueba o reproducción se ejecutó, qué comportamiento se observó y si los objetivos explícitamente excluidos permanecieron sin cambios.

2064. Práctica guiada

Crea una secuencia con intervención humana para este cambio ficticio:

Cambio: Añadir una ralentización temporal al movimiento cuando el jugador entre en una zona peligrosa, sin cambiar el comportamiento de daño de la zona.

Escribe la secuencia usando Inspeccionar → Proponer → Aprobar la propuesta → Verificar la línea base de recuperación → Ejecutar → Inspeccionar el diff y autorizar el punto de control de implementación → Validar, con Escalar como estado de detención obligatorio. Para cada pasada de la IA, registra:

El nombre de la pasada.
El nivel de autoridad de la IA: Inspeccionar, Proponer, Ejecutar o Validar.
El alcance exacto que puede usar la IA.
Al menos una condición de detención observable.
La evidencia asociada al cambio que debe mostrar la IA.
La decisión humana que desbloquea la siguiente pasada.

Para cada puerta de recuperación, indica como autoridad de la IA No aplicable—puerta controlada por una persona y registra el nombre o la ubicación del artefacto, el estado que conserva, cómo funciona la restauración y quién autoriza la continuación.

Tu secuencia debe incluir todos estos límites:

La IA debe Escalar si la ralentización altera el daño, el retroceso u otro efecto no aprobado.
Una persona debe aprobar la propuesta de implementación antes de Ejecutar.
Antes de Ejecutar, una persona debe verificar una línea base de recuperación previa al cambio con nombre y su instrucción de restauración. Restaurarla debe devolver el proyecto al estado anterior a la implementación de la ralentización.
Ejecutar debe informar los archivos realmente modificados y cualquier desviación respecto de la propuesta aprobada.
Después de Ejecutar, una persona debe inspeccionar el diff y autorizar un punto de control de implementación distinto y con nombre antes de comenzar Validar.
El punto de control de implementación debe incluir una instrucción de restauración, corresponder al alcance revisado del cambio y devolver el proyecto al estado posterior a la ejecución desde el que puede reanudarse la validación.
La IA debe Escalar si el comportamiento resultante no puede distinguirse de un cambio permanente en las estadísticas del jugador.
Validar debe incluir una revisión del diff asociado al cambio y pruebas o comprobaciones reproducibles para la ralentización y para verificar que el comportamiento de daño no cambió.
Una persona debe decidir si una validación fallida es un defecto de código, un problema de criterios de aceptación, una acción de recuperación o una cuestión de diseño.

No escribas código de implementación. El ejercicio evalúa decisiones de orquestación, límites de autoridad, capacidad de recuperación y calidad de la evidencia, no sintaxis.

2065. Validación / evidencia

Tu trabajo está completo cuando otro desarrollador puede seguir la secuencia sin adivinar quién tiene la autoridad ni cómo recuperar la implementación. Comprueba que:

Cada pasada de la IA tiene exactamente una etiqueta de autoridad: Inspeccionar, Proponer, Ejecutar o Validar.
Escalar se usa de forma coherente como estado de detención, no como sinónimo informal de Validar ni como permiso adicional de ejecución.
Las líneas base de recuperación y los puntos de control de implementación se identifican como puertas o artefactos controlados por una persona, no como niveles de autoridad de la IA.
Cada transición importante tiene una puerta de aprobación humana con nombre.
Ejecutar no puede comenzar sin una propuesta aprobada y una línea base de recuperación previa al cambio, con nombre, verificada y provista de una instrucción de restauración usable.
Después de Ejecutar, se informan los archivos realmente modificados y las desviaciones antes de que una persona autorice el punto de control de implementación.
Después de inspeccionar el diff y antes de Validar, se registra un punto de control de implementación distinto, con nombre y una instrucción de restauración usable.
La secuencia establece que restaurar la línea base abandona la implementación, mientras que restaurar el punto de control de implementación devuelve el proyecto al estado posterior a la ejecución ya revisado.
La evidencia de revisión identifica el diff o el comportamiento asociado al cambio, en lugar de hacer una afirmación genérica.
Las pruebas o comprobaciones reproducibles están asociadas al comportamiento solicitado y a los comportamientos que explícitamente deben permanecer sin cambios.
Las condiciones de detención describen evidencia observable y no intuiciones.
El alcance aprobado excluye comportamientos no relacionados.
Escalar conduce a una decisión humana, una restauración o una nueva pasada aprobada; no a un reintento automático ni a una ampliación silenciosa del alcance.
La aceptación final depende del comportamiento declarado, los comportamientos que no deben cambiar, la evidencia de revisión y los resultados de las pruebas.

Una secuencia sólida permite responder, para cualquier acción propuesta: “¿Puede la IA hacer esto ahora, qué evidencia asociada al cambio se necesita y qué estado recuperable permite continuar o volver atrás con seguridad?”.

2066. Puntos clave

La intervención humana implica límites explícitos de autoridad, no solo una persona al final.
Inspeccionar, Proponer, Ejecutar y Validar son autoridades distintas; Escalar es el estado de detención ante incertidumbre, conflicto, fallo o exceso de autoridad.
Ejecutar requiere una línea base de recuperación previa al cambio ya verificada; después de Ejecutar y de inspeccionar el diff, se necesita un punto de control de implementación distinto y con nombre antes de Validar.
La evidencia de revisión y pruebas debe estar asociada al cambio solicitado y a los comportamientos que no deben cambiar.
Una pasada exitosa no autoriza automáticamente la siguiente.

2067. Siguiente lección

Continúa con 5.3 L3 — Auditar un fallo de orquestación.