1983. Identidad de la lección
1984. Objetivo de aprendizaje
Después de esta lección, podrás transformar una solicitud ambigua de una funcionalidad de juego en un brief de sistema acotado que especifique límites, autoridad sobre el estado y las decisiones, invariantes, entradas, salidas y objetivos excluidos.
1985. Por qué importa
La IA puede producir mucha implementación en poco tiempo, pero la rapidez no vuelve seguro un diseño impreciso. Cuando una funcionalidad no tiene límites claros, un cambio asistido por IA puede modificar sistemas no relacionados, duplicar la autoridad sobre un dato o cumplir literalmente la solicitud mientras contradice el comportamiento deseado del juego. Un brief acotado ofrece al desarrollador y a la IA un objeto concreto que pueden inspeccionar. También hace más precisa la revisión: puedes comprobar si el cambio respeta el contrato, en lugar de juzgar un parche grande por su apariencia.
1986. Conocimientos previos
Capacidad de entrada canónica: Puedes describir una funcionalidad de juego en términos de su comportamiento previsto, el estado relevante, las reglas y la respuesta observable, y distinguir esa solicitud de funcionalidad de su implementación.
También necesitas los prerrequisitos del curso y un vocabulario básico de sistemas de juego, funcionalidades, estado, reglas y respuesta observable. No necesitas preparar archivos de un proyecto ni configurar un motor específico.
1987. Concepto central
Un sistema es más seguro y más fácil de inspeccionar al modificarlo cuando sus responsabilidades y sus límites están explícitos. Un brief acotado es un requisito previo de diseño, no una prueba de que el repositorio o la tarea de implementación estén preparados para cambios asistidos por IA; la siguiente lección evalúa el contexto del repositorio, la visibilidad de las dependencias, los mecanismos de validación y las restricciones de ejecución.
Un brief útil define cinco elementos:
- Límite: ¿Qué comportamiento controla este sistema y qué comportamiento queda fuera?
- Autoridad (ownership): ¿Qué componente tiene el control autoritativo de cada dato de estado o decisión?
- Invariantes: ¿Qué debe seguir siendo cierto en todo momento, sin importar la implementación?
- Entradas y salidas: ¿Qué información cruza el límite del sistema y qué resultados observables produce?
- Objetivos excluidos: ¿Qué no resolverá deliberadamente el sistema en esta iteración?
La responsabilidad general de un componente indica qué función cumple; la autoridad identifica cuál componente puede establecer o cambiar de forma válida un estado o una decisión. No son lo mismo.
El objetivo no es anticipar cada detalle de código. Es restringir las decisiones que una implementación puede tomar sin poner en riesgo la intención del diseño.
1988. Modelo mental
Usa el brief BOINS antes de pedir a una IA que implemente o revise un sistema:
| Parte | Pregunta | Ejemplo de respuesta |
|---|---|---|
| B — Boundary / Límite | ¿Qué controla este sistema? | Calcula si un guardia comienza a sospechar. |
| O — Ownership / Autoridad | ¿Qué componente tiene el control autoritativo? | El sistema de sospecha tiene autoridad sobre el valor de sospecha; la interfaz solo lo muestra. |
| I — Invariants / Invariantes | ¿Qué debe ser siempre cierto? | La sospecha se mantiene entre 0 y 100. |
| N — Named inputs and outputs / Entradas y salidas | ¿Qué cruza el límite? | Entradas: evento observado y contexto. Salida: estado actualizado y notificación. |
| S — Scope exclusions / Exclusiones de alcance | ¿Qué queda fuera explícitamente? | No elige animaciones ni genera refuerzos. |
La responsabilidad de mostrar un valor puede pertenecer a la interfaz, pero la autoridad sobre ese valor pertenece al sistema que puede establecerlo según sus reglas. Un brief es sólido cuando otro desarrollador puede distinguir un cambio aceptable de uno inaceptable sin tener que adivinar tu intención.
1989. Ejemplo concreto
Solicitud ambigua:
“Haz que los guardias reaccionen mejor cuando vean al jugador.”
La solicitud mezcla detección, reacción, presentación y posiblemente dificultad del encuentro. Una IA podría implementar razonablemente un temporizador de detección, una alerta de interfaz, una animación, un estado de persecución o todo a la vez.
Una versión acotada resulta más útil:
Sistema: Evaluación de sospecha del guardia.
Límite: Convierte eventos confirmados de observación en un valor de sospecha y en un evento de cambio de nivel.
Autoridad: Este sistema tiene autoridad sobre el valor de sospecha de un guardia. El sistema de percepción tiene la responsabilidad de decidir si un evento de observación es válido, pero no puede establecer directamente el valor de sospecha. La capa de presentación tiene la responsabilidad de controlar iconos, texto y animaciones, pero no posee autoridad sobre el valor.
Entradas: Identificador del guardia, evento de observación, intensidad del evento y tiempo transcurrido para el descenso del valor.
Salidas: Valor de sospecha entre 0 y 100; un evento de cambio cuando el valor cruza un umbral configurado.
Invariantes: La sospecha nunca sale del rango 0–100; el código de presentación no puede asignar directamente la sospecha; un evento inválido o ausente no aumenta la sospecha.
Objetivos excluidos: No se añaden animaciones, comportamiento de persecución, generación de refuerzos, rediseño del nivel ni reajuste de dificultad.
Evidencia de aceptación: Una prueba o inspección demuestra que las observaciones válidas aumentan la sospecha, el descenso la reduce según la regla definida, los cruces de umbral emiten un evento correspondiente y la interfaz no puede convertirse en la autoridad del valor.
El brief no impone nombres de clases ni una API concreta del motor. Sí restringe el comportamiento y las relaciones de autoridad que importan.
1990. Flujo de trabajo nativo de IA
Usa la IA como crítica de la especificación antes de usarla como colaboradora de implementación:
- Escribe tú la primera versión del brief.
- Pide a la IA que enumere ambigüedades, autoridades ausentes, responsabilidades mezcladas y posibles ampliaciones de alcance. Pídele que cite la frase exacta que origina cada observación.
- Revisa el brief decidiendo qué observaciones importan en esta iteración. No aceptes automáticamente todas las sugerencias.
- Pide a la IA que proponga comprobaciones de aceptación derivadas únicamente de los límites, invariantes, entradas, salidas y exclusiones finales.
- Compara esas comprobaciones con tu brief. Elimina cualquier comprobación que introduzca una funcionalidad no aprobada.
La decisión sobre el límite y la autoridad sigue siendo humana. La IA puede revelar ambigüedades, pero no decide el alcance del producto por ti.
1991. Error común
El error más frecuente es confundir el nombre de una funcionalidad con el límite de un sistema. “Reacciones de los guardias” o “mejoras del inventario” describe un resultado deseado, no qué controla el sistema ni qué queda dentro del alcance. También es un error usar “responsabilidad” para referirse a la autoridad sobre un estado: un componente puede tener la responsabilidad general de mostrar o procesar información sin ser la fuente autoritativa de esa información. Otro error es escribir exclusiones vagas, como “mantenerlo sencillo”. Una exclusión útil nombra una responsabilidad tentadora que el sistema no asumirá, por ejemplo: “no modifica el estado de las animaciones”.
1992. Práctica guiada
Convierte esta solicitud en un brief BOINS:
“Añade un sistema de resistencia para que el movimiento sea más táctico.”
Completa esta plantilla compacta de BOINS:\n\n- Límite:\n- Autoridad sobre el estado:\n- Invariantes:\n- Entradas:\n- Salidas:\n- Objetivos excluidos:\n- Evidencia de aceptación:\n- Cambio seguro: Nombra un cambio propuesto que el contrato permita y cita el elemento de BOINS que lo autoriza.\n- Cambio rechazado: Nombra un cambio tentador que quede fuera del contrato y cita el elemento de BOINS que exige rechazarlo.\n\nUsa estas restricciones:
- El brief debe definir una única autoridad para la resistencia.
- Debe distinguir las reglas de resistencia de la presentación del movimiento.
- Debe incluir al menos dos invariantes.
- Debe indicar qué ocurre cuando no hay resistencia suficiente para intentar una acción.
- Debe nombrar al menos tres objetivos excluidos.
Después toma una decisión de límite: elige si la resistencia pertenece al sistema de movimiento o a un sistema de recursos separado. Expón la decisión y justifícala con base en la autoridad sobre el estado y la seguridad del cambio.
1993. Validación / evidencia
Tu evidencia es un brief de sistema de una página que contenga:
- Un límite con al menos una responsabilidad vecina excluida.
- Una autoridad explícita para el estado autoritativo.
- Al menos dos invariantes comprobables.
- Entradas y salidas nombradas con claridad.
- Al menos tres objetivos excluidos concretos.
- Una decisión sobre la ubicación del sistema y su justificación.\n- Un cambio seguro propuesto que el contrato permita, justificado mediante un elemento específico de BOINS.\n- Un cambio tentador que deba rechazarse por quedar fuera del alcance, justificado mediante un elemento específico de BOINS.
Otra persona o una futura IA colaboradora debe poder identificar un cambio seguro y otro fuera de alcance a partir del brief, sin preguntarte qué querías decir.
1994. Ideas clave
- La implementación asistida por IA es más segura cuando el contrato de diseño se puede inspeccionar antes de modificar el código.
- Los límites evitan que un sistema absorba responsabilidades no relacionadas.
- La autoridad identifica la fuente que puede establecer el estado y tomar las decisiones correspondientes; la responsabilidad describe una función o deber más general.
- Las invariantes convierten la intención de diseño en condiciones comprobables.
- Las exclusiones de alcance protegen la iteración contra ampliaciones silenciosas.
1995. Siguiente lección
Continúa con 5.1 L2 — Evalúa la preparación para la IA antes de implementar.
1996. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué afirmación define mejor el límite de un sistema?
Mostrar respuesta y explicación
Respuesta: El comportamiento que controla el sistema y el comportamiento vecino que excluye
Por qué: Un límite establece qué controla el sistema y qué queda fuera. El nombre de una funcionalidad, un detalle de implementación o un efecto visual no define por sí solo esa responsabilidad.
¿Cuál es una invariante de un sistema de sospecha?
Mostrar respuesta y explicación
Respuesta: El valor de sospecha se mantiene entre 0 y 100
Por qué: Una invariante es una condición que debe mantenerse cierta independientemente de la implementación. Mantener el valor dentro del rango definido se puede comprobar directamente.
¿Cuál es el mejor uso de la IA antes de comenzar la implementación?
Mostrar respuesta y explicación
Respuesta: Pedirle que revele ambigüedades y derive comprobaciones del brief
Por qué: La IA resulta útil como crítica de la especificación: puede identificar ambigüedades y sugerir comprobaciones. El desarrollador sigue teniendo la responsabilidad de decidir el alcance y aceptar los cambios.
¿Por qué debe incluir objetivos excluidos un brief de sistema?
Mostrar respuesta y explicación
Respuesta: Para evitar que responsabilidades vecinas tentadoras amplíen la iteración
Por qué: Los objetivos excluidos hacen explícito el alcance. Evitan que el sistema, el desarrollador o la IA absorban silenciosamente responsabilidades relacionadas pero no aprobadas.