El hueco después de que aparece el código
Un modelo puede producir una función que se ve correcta en local. La arquitectura de un juego no es un problema local. Una cámara, un blob de save, un manager de diálogo y un medidor de supervivencia comparten el mundo. Si no puedes nombrar al dueño de un dato, el parche más rápido suele ser el incorrecto: escribir el valor otra vez desde un lugar nuevo y cómodo.
Por eso la Academy trata “¿quién diseña el sistema?” como pregunta de primer orden. Dirigir IA no es lo mismo que pedirle que “haga que funcione.” Hacer que funcione sin ownership es cómo terminas con dos fuentes de verdad, un test en verde y un jugador que ve el número equivocado en pantalla.
El ownership de estado es un documento de diseño
El ownership de estado es una respuesta en lenguaje claro: este módulo puede escribir este campo; otros pueden leerlo; nadie más puede inventar una copia paralela. Cuando esa frase falta, un socio de IA optimiza el prompt que tiene delante. El prompt rara vez incluye los sistemas vecinos.
Los casos verificados de CONTRABAND existen porque esa clase de error apareció en un juego comercial publicado — no porque hiciéramos falta una metáfora. Los textos públicos se quedan en incidentes evidenciados. Este ensayo no los vuelve a contar. Nombra la disciplina que obligaron: conocer al dueño antes de aceptar el parche.
Especificar trabajo sin autorizar una reescritura
Una instrucción útil para un socio de implementación IA es chica y acotada: cambia este comportamiento, en este módulo, bajo estos invariantes, con esta comprobación de aceptación. Una instrucción dañina es “arregla el bug” con todo el repositorio en alcance. La segunda invitación es cómo los sistemas vecinos se reescriben por conveniencia.
Cursor y herramientas parecidas hacen fácil esa invitación. Pegas un stack trace y aceptas una reescritura que “se ve más limpia.” Limpio no es lo mismo que owned. Si el parche mueve lógica a un helper que ahora también escribe estado del HUD, no simplificaste el juego. Escondiste un segundo dueño.
No necesitas ser experto en compiladores para escribir el primer tipo de instrucción. Sí necesitas una imagen del bucle: qué hizo el jugador, qué creyó la simulación, qué mostró la presentación y qué archivo puede zanjear la discusión. Los resultados de aprendizaje del curso incluyen decir esa imagen en voz alta. Las 170 lecciones gratis de este sitio son donde se practica.
Tests que fallan por la razón correcta
Un test que solo revisa un mock conveniente se queda en verde mientras el sistema frente al jugador está mal. La arquitectura incluye decidir qué se le permite probar a una regresión. La plantilla de casos de la Academy pide una regresión que atrape la misma clase de error. Es un dispositivo de enseñanza sobre ownership, no una afirmación de que la suite privada de CONTRABAND se publica aquí.
Jugar sigue siendo el último juez. Hay implementaciones que pasan tests y fallan al jugar. Si no puedes describir el feel del loop, publicarás una máquina de aspecto correcto que nadie quiere conducir.
Quién puede decidir
Dero Lavigne diseña e implementa el trabajo que la Academy usa como caso comercial. Martinez AI Studios publica ese trabajo y es dueño de la plataforma educativa. La Academy no pretende ser el developer de CONTRABAND, y derolavigne.com no es un segundo checkout. La arquitectura es un rol humano en esa separación: alguien tiene que sostener el sistema en la cabeza lo bastante como para rechazar un parche ingenioso, local e incorrecto.
Si quieres la siguiente capa de método — cómo rechazamos los arreglos solo de síntoma — lee la nota de causa raíz. Si quieres incidentes evidenciados, abre el hub de casos de CONTRABAND. Si quieres el mapa profesional, abre el curso insignia: 170 lecciones ya se leen gratis.