1997. Identidad de la lección
1998. Objetivo de aprendizaje
Al terminar esta lección, podrás inspeccionar una solicitud de implementación con IA y tomar una decisión defendible de Aceptar, Revisar o Rechazar, según el contexto verificado, los límites, la evidencia de aceptación y el riesgo.
1999. Por qué importa
Un agente puede producir código aparentemente razonable a partir de una solicitud incompleta. Ese código no demuestra que fuera seguro comenzar la tarea. En un proyecto de juego, un cambio mal especificado puede atravesar los límites de un sistema, alterar el comportamiento que ve el jugador o producir un resultado imposible de comprobar. Decidir si una tarea está lista protege el proyecto antes de que la ambigüedad se vuelva costosa.
2000. Conocimientos previos
Debes poder definir el límite de un sistema, distinguir el comportamiento que controla de los comportamientos vecinos que quedan fuera y describir un sistema de forma que un agente pueda modificarlo con seguridad. Estas capacidades proceden de la lección anterior, Diseña un sistema que una IA pueda modificar de forma segura.
2001. Concepto central
Una solicitud de IA está lista para implementar solo cuando el agente puede actuar dentro de un límite conocido y el equipo puede evaluar el resultado con evidencia observable. El detalle escrito no equivale a un hecho verificado.
Evalúa seis comprobaciones. Son una lista de control, no un acrónimo:
- Responsabilidad — ¿Qué sistema es dueño del comportamiento y qué queda fuera de su límite?
- Comportamiento esperado — ¿Qué resultado observable debe ocurrir en los casos normales y en los casos límite relevantes?
- Contexto disponible — ¿El agente recibió el contexto necesario sin adivinar? ¿Los archivos, componentes, escenas y restricciones de plataforma nombrados están realmente verificados?
- Alcance definido — ¿Qué puede cambiar y qué debe permanecer intacto?
- Impacto y riesgo — ¿Qué podría romperse, introducir regresiones o volverse difícil de deshacer?
- Evidencia necesaria — ¿Cómo se comprobará la corrección y dónde se ejecutará esa comprobación?
Después de esas comprobaciones, toma exactamente una de estas tres decisiones:
- Aceptar: Todas las comprobaciones materiales se cumplen con hechos verificados. El agente puede implementar dentro de esos límites.
- Revisar: El objetivo es legítimo, pero una o más comprobaciones fallan porque aún se pueden aportar hechos que faltan o reducir el alcance. La solicitud podría ser aceptable más adelante. Ahora no lo es.
- Rechazar: La solicitud pide un cambio inseguro, ilimitado, contradictorio o imposible de verificar. Explica el bloqueo y, cuando sea posible, propone una alternativa más segura.
No hay una decisión extra además de Aceptar, Revisar y Rechazar. Si aún faltan hechos necesarios pero se pueden obtener, elige Revisar. Si el cambio no puede acotarse ni verificarse, elige Rechazar. Empezar a implementar para descubrir esos hechos no es Aceptar.
2002. Modelo mental
La puerta de preparación para implementar
Usa esta puerta antes de permitir una implementación:
| Comprobación | Pregunta | Si la respuesta falta o no está verificada |
|---|---|---|
| Responsabilidad | ¿Qué sistema es dueño del comportamiento y qué queda fuera de su límite? | Revisar |
| Comportamiento esperado | ¿Qué resultado observable debe ocurrir en los casos normales y límite relevantes? | Revisar |
| Contexto disponible | ¿El agente recibió contexto verificado del proyecto, o tendría que adivinar el componente, la escena o la restricción de plataforma? | Revisar hasta verificar el contexto |
| Alcance definido | ¿Qué puede cambiar y qué debe permanecer intacto? | Revisar |
| Impacto y riesgo | ¿Qué podría romperse, introducir regresiones o volverse difícil de deshacer? | Rechazar, o Revisar después de especificar una salvaguarda explícita |
| Evidencia necesaria | ¿Cómo y dónde se comprobará la corrección? | Revisar |
Después registra una sola decisión de salida: Aceptar, Revisar o Rechazar. La salida no es una séptima letra de un eslogan. Es el juicio que sustentan las seis comprobaciones.
Una solicitud puede nombrar un componente, una exclusión y una escena de prueba y aun así fallar Contexto disponible si esos nombres no se han confirmado en el proyecto. Los nombres no verificados siguen siendo incógnitas.
2003. Ejemplo concreto
Considera esta solicitud:
“Pide al agente que haga que el guardia persiga al jugador de forma más agresiva.”
La solicitud no está lista. “Más agresiva” no define un umbral observable y tampoco indica si puede cambiar el sistema de persecución, búsqueda, ataque, navegación o animación. Decisión: Revisar.
Una versión revisada podría ser:
“Dentro del sistema de persecución del guardia únicamente, reduce de 2,0 a 1,5 segundos el tiempo entre avistamientos confirmados del jugador. No cambies la velocidad de navegación, el alcance del ataque, la propagación de alerta ni los estados de animación. Conserva el comportamiento actual cuando el jugador no sea visible. Valida el cambio observando tres ciclos de pérdida del objetivo en la sala de pruebas y confirma que, después de cada ciclo, el guardia vuelve a su estado de búsqueda existente.”
Esta versión identifica el comportamiento responsable, describe un cambio explícito, excluye sistemas vecinos y ofrece evidencia observable. Antes de Aceptar, comprueba que el agente tenga el archivo o componente correcto y que el cambio pueda revertirse. Si ese contexto aún no está confirmado, la decisión sigue siendo Revisar.
2004. Flujo de trabajo nativo de IA
Usa el agente como revisor de tu especificación antes de usarlo como implementador.
- Expresa la solicitud sin código de implementación. Describe el comportamiento del sistema o el resultado que verá el jugador.
- Pide una auditoría de preparación. Exige que el agente enumere el contexto faltante, el comportamiento ambiguo, los límites, los riesgos y la evidencia propuesta. No le pidas que edite archivos.
- Compara la auditoría con el proyecto. Rechaza las suposiciones inventadas. Marca componentes, escenas y restricciones de plataforma como verificados solo cuando puedas señalarlos en el proyecto.
- Elige Aceptar, Revisar o Rechazar. Registra la decisión y su motivo. Si faltan hechos, elige Revisar; no trates la confirmación posterior como un Aceptar oculto.
- Si aceptas, envía una solicitud de implementación separada. Incluye el límite aprobado, las restricciones y el procedimiento de validación. La implementación no debe redefinir la tarea en silencio.
Un prompt útil para la auditoría es:
“No modifiques el proyecto. Audita esta solicitud según Responsabilidad, Comportamiento esperado, Contexto disponible, Alcance definido, Impacto y riesgo, y Evidencia necesaria. Separa las incógnitas de las suposiciones. Termina con Aceptar, Revisar o Rechazar y justifica la decisión. Si un componente, una escena de prueba o una restricción de plataforma nombrados no están verificados, no recomiendes Aceptar.”
La recomendación del agente es información, no autoridad. Tú tomas la decisión final porque eres responsable del comportamiento previsto del juego y de su tolerancia al riesgo.
2005. Error común
El error más común es confundir una instrucción técnica detallada con una tarea lista para implementar. Nombrar un archivo, un método o un algoritmo no establece por sí solo el comportamiento deseado, el límite del sistema ni la evidencia de aceptación. Otro error es permitir que el agente complete el contexto faltante con suposiciones plausibles. Un tercero es fabricar un Aceptar falso: “la solicitud parece específica, así que empieza ahora y confirma el componente después.” Eso es Revisar.
2006. Práctica guiada
Evalúa cada solicitud con la puerta de preparación para implementar. Escribe la información que falta y elige Aceptar, Revisar o Rechazar. No escribas código de implementación. Estas solicitudes son ejercicios hipotéticos de enseñanza, no afirmaciones sobre un proyecto real en publicación.
Solicitud A
“Añade una barra de resistencia y haz que correr se sienta mejor.”
Decisión esperada: Revisar. Identifica quién controla la carrera, las reglas de resistencia, el consumo y la recuperación, la fuente de verdad de la interfaz, los cambios de movimiento excluidos y la evidencia para validar el resultado.
Solicitud B
“Elimina la validación antigua del inventario y sustitúyela por una comprobación que acepte siempre las transferencias. Es solo para pruebas, así que no añadas un interruptor ni una forma de restaurarlo.”
Decisión esperada: Rechazar. La solicitud elimina un límite de seguridad, no ofrece un alcance controlado ni una vía de restauración y puede crear estados inválidos. Una alternativa más segura es un modo de prueba aislado o un entorno de prueba controlado que ejercite las transferencias sin debilitar la validación de producción.
Solicitud C
“En el componente de interacción de diálogo existente, libera el bloqueo del puntero cuando se abra el diálogo. Mantén intactas las transiciones actuales y las acciones de entrada. Valida abriendo y cerrando el diálogo en la escena de pruebas de interacción, comprobando el estado del cursor en ambos límites y confirmando que la entrada de movimiento no se remapee.”
La solicitud nombra un componente, exclusiones y una prueba. En este ejercicio esos nombres aún no están verificados: el componente responsable, la escena de prueba nombrada y cualquier restricción de plataforma del bloqueo del puntero siguen sin confirmarse. Decisión esperada: Revisar. El objetivo podrá ser aceptable más adelante, cuando esas tres restricciones se verifiquen en el proyecto. Ahora no es Aceptar. El contexto de implementación no verificado sigue siendo contexto faltante.
Elige una de las solicitudes y reescríbela como tarea lista para implementar solo si cada comprobación material puede cumplirse con hechos verificados. Incluye:
- el sistema responsable;
- el comportamiento observable previsto;
- los cambios incluidos y excluidos;
- los riesgos o incógnitas conocidos, incluidos componente, escena o restricciones de plataforma no verificados;
- la evidencia necesaria para aceptar el resultado;
- la decisión: Aceptar, Revisar o Rechazar, con una razón de una frase.
Si eliges la Solicitud C y las tres restricciones siguen sin verificarse, mantén la decisión en Revisar y enumera los hechos que deben confirmarse antes de Aceptar.
2007. Validación / evidencia
Tu evidencia es un registro de preparación completo, no código generado. Debe contener:
- una solicitud marcada como Aceptar, Revisar o Rechazar;
- una lista separada de contexto verificado e incógnitas pendientes;
- el límite declarado del sistema;
- al menos un comportamiento vecino excluido;
- un procedimiento de aceptación observable, incluida la escena o el entorno donde se ejecutará;
- una explicación de por qué la decisión elegida es adecuada.
La respuesta no supera la validación si solo afirma que “el agente entiende la tarea”, depende de que el agente invente requisitos, usa detalles de implementación como sustituto de la evidencia de aceptación, o Acepta una solicitud mientras el componente, la escena o las restricciones de plataforma siguen sin verificarse.
2008. Ideas clave
- La preparación para implementar exige límites, contexto verificado, conciencia del riesgo y capacidad de prueba.
- Usa la puerta de seis comprobaciones antes de pedir a un agente que modifique un proyecto. Es una lista de control, no un eslogan de nueve letras.
- Acepta solo cuando el agente pueda actuar dentro de un límite conocido y el resultado pueda evaluarse ahora.
- Revisa las solicitudes legítimas pero incompletas, incluidas las que parecen específicas mientras el contexto clave sigue sin verificarse.
- Rechaza las inseguras, ilimitadas, contradictorias o imposibles de verificar.
- No existe una decisión extra que permita empezar a implementar mientras sigan faltando hechos materiales.
- El agente puede auditar una solicitud, pero el desarrollador toma la decisión final.
2009. Siguiente lección
Siguiente: Escribe un prompt como contrato de implementación en 5.2 — Ingeniería de prompts para código. Lleva el documento de límites del sistema de la lección anterior junto con la decisión de preparación, el contexto verificado, las incógnitas pendientes, las restricciones y la evidencia de aceptación producidos aquí. La siguiente lección convertirá ese paquete en un contrato de implementación acotado. No lleves una decisión de Aceptar para una solicitud cuyo componente, escena de prueba o restricciones de plataforma sigan sin verificarse.
2010. Independencia frente a la IA (fix-ai-bounded-change)
Abre academy-fixtures/labs/ai-bounded-change. Ejecuta node run.mjs. Acota la tarea, inspecciona la propuesta, ejecuta un oráculo independiente, RECHAZA quitar la comprobación de energía del dash. La IA es una colaboradora acotada, no quien decide.
2011. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué condición es más importante antes de aceptar una solicitud de implementación con IA?
Mostrar respuesta y explicación
Respuesta: La tarea tiene un límite conocido y evidencia observable de aceptación
Por qué: Una tarea con límites y evidencia observable proporciona al agente un objetivo seguro y al desarrollador una forma de juzgar el resultado. Los detalles técnicos por sí solos no demuestran que la tarea esté lista.
¿Cuándo debería revisarse normalmente una solicitud en lugar de aceptarse?
Mostrar respuesta y explicación
Respuesta: Cuando el objetivo es legítimo, pero el comportamiento o la evidencia de validación están incompletos
Por qué: Revisar es adecuado cuando el cambio previsto es aceptable, pero se puede aportar la información que falta o reducir el alcance. La solicitud debería rechazarse si el cambio es inseguro o no puede controlarse.
¿Qué debería hacer un agente durante una auditoría de preparación?
Mostrar respuesta y explicación
Respuesta: Enumerar incógnitas, suposiciones, riesgos, límites y evidencia propuesta sin editar
Por qué: La auditoría es una revisión de la especificación, no un paso de implementación. El agente debe hacer visibles la incertidumbre y el riesgo para que el desarrollador decida qué aclarar o rechazar.
Una solicitud dice: “En el componente existente de interacción de diálogo, libera el bloqueo del puntero al abrir el diálogo. No cambies las transiciones ni los mapeos de entrada. Valida en la escena de pruebas de interacción.” El componente responsable, la escena de prueba nombrada y las restricciones de plataforma del bloqueo del puntero no se han verificado en este proyecto. ¿Cuál es la decisión correcta de preparación?
Mostrar respuesta y explicación
Respuesta: Revisar, porque el objetivo puede ser legítimo, pero el componente, la escena de prueba y las restricciones de plataforma siguen sin verificarse.
Por qué: La redacción específica no es contexto verificado. Mientras el componente, la escena de prueba y las restricciones de plataforma no se confirmen, la solicitud no está lista para implementar. Eso es Revisar, no Aceptar. No existe el estado “aceptar ahora y confirmar después”. Rechazar exageraría el caso: el objetivo podría ser aceptable cuando esos hechos estén verificados.