Aprender AI-DLC creando un juego, parte 2: prueba de concepto

Parte 2 de la serie de AI-DLC con un juego: la prueba de concepto pasa en el build de escritorio para Linux y en el build web alojado en Amplify (Chrome, Firefox, iPad), con una imagen de build propia de Godot 4.7.2 y el plugin sin cambios; las cuatro etapas del plan aprobadas, con la aprobación del plan desactivada para un poc y 12 de 12 objetivos cumplidos

Esta es la parte 2 de una serie sobre aprender AI-DLC creando un juego, World Rift Conflict, en Godot con un backend en AWS. La parte 1 cubrió la configuración y la primera etapa del primer trabajo. Esta parte termina ese trabajo: una prueba de concepto.

Partes hasta ahora:

Resumen

  1. La pregunta era estrecha a propósito: ¿puede un juego en Godot 4.7 registrar e iniciar sesión a un jugador con el plugin de ejemplo de AWS para Amplify, que se hizo para Godot 4.3? Puede, sin cambios en el plugin.
  2. El análisis de requisitos convirtió los hallazgos del revisor de la captura de intención en preguntas. Mis respuestas hicieron la prueba de concepto más grande de lo que planeé: el build web lo construye y aloja Amplify, con una imagen de build propia de Godot.
  3. La generación de código preguntó antes de planificar, porque dos hechos contradecían los requisitos. En la parte 1 dije que aprobaría el plan antes de que se escribiera código; me equivoqué. La aprobación del plan está desactivada para un poc.
  4. Construcción y pruebas fue donde ocurrió el trabajo en AWS, paso a paso, cada uno después de mi visto bueno. El primer build de Amplify pasó.
  5. El mejor momento fue un fallo: al retomar al día siguiente, AI-DLC vio que los resultados guardados no cubrían dos de las comprobaciones requeridas. Las hice, y esa comprobación se convirtió en una regla del proyecto.

La pregunta

El backend del juego será AWS Amplify Gen 2, y el cliente es Godot 4.7. El único cliente de Godot para Amplify que conozco es el plugin de ejemplo de AWS, publicado por última vez para Godot 4.3. Si no funciona en 4.7, cambia mucho de lo que se planifique después. Así que el primer trabajo fue un alcance poc con una sola pregunta:

/aidlc poc Prove a Godot 4.7 game can sign a player in with the AWS Amplify plugin

AI-DLC planificó cuatro etapas, cada una terminada en una puerta de aprobación: captura de intención (parte 1), análisis de requisitos, generación de código, y construcción y pruebas.

Requisitos: la revisión se convierte en preguntas

La revisión de la captura de intención de la parte 1 dejó cuatro hallazgos, que acepté como riesgos en la puerta. El análisis de requisitos no los olvidó. Sus preguntas fueron directo a ellos: qué cuenta exactamente como sesión iniciada, qué fallos comprobar, cómo se confirma el registro y dónde se hacen las comprobaciones. Mis respuestas, del archivo de preguntas:

  • Señal de éxito: el juego muestra "Signed in as <email>", con el correo leído de vuelta desde Cognito, no copiado del formulario.
  • Caso de fallo: solo una contraseña incorrecta.
  • Confirmación: Cognito envía un código por correo y el jugador lo escribe en el juego.
  • Dónde: un build de escritorio para Linux y un build web en Amplify Hosting, en Chrome.

Mi respuesta sobre el build web trajo una pregunta de seguimiento, y luego otra, que AI-DLC marcó como un conflicto con la intención. Construir el export web en Amplify Hosting necesita Godot dentro del build de Amplify, es decir, una imagen de build propia. La declaración de intención decía que esta era la forma más barata de comprobar la configuración, y una imagen propia no es barata. Me pidió elegir. Elegí mantener la imagen en la prueba de concepto: el juego real se desplegará igual, así que prefiero encontrar los problemas ahora.

El resultado fue requirements.md con FR1 a FR5 y dos requisitos no funcionales. Cada uno tiene criterios de aceptación Given/When/Then y una etiqueta de fuente que apunta a la respuesta de la que salió. El revisor de producto devolvió READY con cinco hallazgos menores, y aprobé.

Generación de código: preguntó antes de planificar

Esperaba un plan para aprobar. En cambio, lo primero que hizo la generación de código fue hacer tres preguntas más, porque había encontrado dos hechos al planificar:

  • Amplify Hosting acepta imágenes de build propias solo desde Amazon ECR Public.
  • Mi máquina no tenía Docker para construir la imagen.

Elegí instalar Docker y subir a ECR Public; apuntar el build de escritorio al backend de la rama main; y dejar que el agente creara la app de Amplify con las herramientas de AWS, pero solo después de mi visto bueno.

Luego escribió un plan de 16 pasos y empezó a construir enseguida. En la parte 1 dije que la generación de código se detendría para aprobar el plan antes de escribir código. Fue un error mío: para un poc, la aprobación del plan está desactivada, y el motor lo dice:

Plan approval ... is off for this piece of work (from scope poc). Starting code generation now.

Un subagente desarrollador lo construyó en unos 15 minutos:

  • game/: el proyecto de Godot, con el plugin (v0.3.1) copiado sin cambios y su origen registrado, una pantalla de registro / confirmación / inicio de sesión, y 7 pruebas que corren sin interfaz en Godot.
  • amplify/: un backend de Amplify Gen 2 solo con autenticación: un grupo de usuarios de Cognito con inicio de sesión por correo.
  • build-image/Dockerfile: Amazon Linux 2023 con Node 24, Godot 4.7.2 y sus plantillas de export web, cada descarga verificada contra un checksum fijado.
  • amplify.yml, una comprobación de secretos en el repositorio y un runbook con los pasos de extremo a extremo.

El plugin no necesitó cambios para Godot 4.7. El valor por defecto de Amplify necesitó uno. El plugin inicia sesión con el flujo USER_PASSWORD_AUTH de Cognito, y el cliente del grupo de usuarios que crea Amplify por defecto no lo permite, así que el backend lo añade:

// The AWS sample Godot plugin (v0.3.1) signs in with Cognito's
// USER_PASSWORD_AUTH flow (InitiateAuth). Amplify's default user pool client
// allows only SRP and custom auth, so this flow is added to the existing list.
const { cfnUserPoolClient } = backend.auth.resources.cfnResources
const existingAuthFlows = cfnUserPoolClient.explicitAuthFlows ?? []
cfnUserPoolClient.explicitAuthFlows = [
  ...existingAuthFlows,
  'ALLOW_USER_PASSWORD_AUTH',
]

Ese flujo envía la contraseña a Cognito dentro de la petición TLS en lugar de usar SRP. El revisor de arquitectura lo señaló, y ahora es una regla del proyecto: aceptable para una prueba de concepto, a revisar antes de que el juego tenga jugadores reales.

El revisor devolvió READY con cinco hallazgos menores. El más útil fue directo: nada probaba todavía que el export web funcionara. En la pregunta de aprendizajes conservé cuatro notas. Una cambió cómo funcionan las etapas siguientes: la generación de código escribe archivos y ejecuta comprobaciones locales; toda acción en AWS ocurre en construcción y pruebas, después de mi visto bueno.

Lo que se construyó

Arquitectura de la prueba de concepto: el desarrollador sube el repositorio a GitHub y construye una imagen propia con Docker, subida a Amazon ECR Public; Amplify Hosting construye main dentro de esa imagen, despliega el backend con CloudFormation, que crea el grupo de usuarios de Amazon Cognito, y exporta el build web de Godot a la CDN de Amplify; el build web en el navegador y el build de escritorio para Linux registran e inician sesión contra el mismo grupo de usuarios de Cognito

Los pasos de la derecha siguen el orden en que pasan las cosas. Dos ideas cargan casi todo: Amplify ejecuta todo su build dentro de mi imagen, y el juego lee los identificadores de su backend de un amplify_outputs.json generado que nunca se sube al repositorio. La fase frontend de amplify.yml muestra ambas:

frontend:
  phases:
    build:
      commands:
        # Outputs file for this branch's backend; generated, never committed
        - npx ampx generate outputs --branch $AWS_BRANCH --app-id $AWS_APP_ID --out-dir game
        # A fresh clone has no Godot import cache; import before exporting
        - godot --headless --path game --import
        - mkdir -p build/web
        - godot --headless --path game --export-release "Web" ../build/web/index.html

Construcción y pruebas: la parte de AWS

Primero, el punto abierto del revisor. El agente exportó el build web en local con un archivo de outputs de relleno, lo sirvió y lo abrió en Chromium. Sin errores en la consola, y apareció la pantalla de registro:

El build web de Godot en Chromium: un panel de World Rift Conflict titulado Create an account, con campos de correo y contraseña, un botón Sign up y un enlace I already have an account

Luego los pasos en AWS, cada uno esperando mi visto bueno. La mayor parte de la fricción me tocaba arreglarla a mí, no al agente:

  • Docker en Ubuntu 26.04. Después de añadirme al grupo docker, nada cambió hasta reiniciar del todo. newgrp no viene instalado ahí.
  • El build de la imagen falló una vez por un error de red al descargar las plantillas de export, y luego se construyó: 1.11 GB, amd64, Godot 4.7.2.
  • ECR Public se negó: mi conjunto de permisos de Amplify no tenía derechos de ecr-public. El agente escribió una política en línea limitada a ese único repositorio. La primera creación aún falló, porque el agente añadió una etiqueta y la política no permitía ecr-public:TagResource. El segundo intento, sin etiquetas, funcionó.
  • El rol de servicio. El caso de uso de Amplify en el asistente de IAM impone AdministratorAccess-Amplify, sin forma de elegir otra política. Creé el rol y después cambié la política por AmplifyBackendDeployFullAccess en la pestaña de permisos del rol.

Subí a GitHub (en este proyecto ese paso siempre es mío), conecté el repositorio en la consola de Amplify con la imagen propia y el rol, y el primer build pasó: build, despliegue y verificación correctos. El log del build muestra Node v24.22.1 y Godot 4.7.2.stable corriendo dentro de la imagen.

Las comprobaciones de extremo a extremo son manuales, del runbook, y las hice yo:

ComprobaciónBuild de LinuxBuild web en Amplify
Registro y código por correopasapasa (Chrome; también iPad WebKit)
"Signed in as <email>"pasapasa (Chrome 156, iPad)
Contraseña incorrectapasa: "Sign-in failed: Incorrect username or password."pasa, mismo mensaje
Carga y se ejecutasíChrome 156, Firefox 157, iPad WebKit

Lo que atraparon las pruebas

Hice la mayoría de esas comprobaciones en una sesión y paré antes de que cerrara la etapa. Al día siguiente retomé (primero aidlc engine state unpark, porque el trabajo estaba aparcado), y construcción y pruebas comparó los resultados guardados con los requisitos antes de escribir su resumen. Encontró un hueco: el registro solo se había probado en el iPad, pero FR4 y FR5 lo exigen en el build de Linux y en Chrome.

Mi primera reacción fue que ya lo había hecho y se lo había dicho a la sesión anterior. El agente me mostró la tabla guardada, y tuve que admitir que el registro solo se había hecho en el iPad. Hice los dos con correos nuevos, y ambos pasaron. En la pregunta de aprendizajes conservé la lección como regla del proyecto: registrar cada resultado de extremo a extremo por requisito y por plataforma, y compararlo con el requisito antes de dar por terminada la etapa de construcción y pruebas.

Queda un cabo suelto, anotado en el registro como no resuelto. Recuerdo haber usado dos correos nuevos distintos para los registros en Chrome y en Linux, pero el grupo de usuarios mostraba solo una cuenta creada ese día. Los resultados están registrados como los informé, con la discrepancia anotada al lado.

El resumen marcó los 12 objetivos (FR1 a FR5 con sus subrequisitos, NFR1 y NFR2) como cumplidos, y aprobé: "That is everything on the plan. Your work is finished and written up."

La limpieza tuvo una protección más. Cuando le pedí al agente borrar los usuarios de prueba, el modo automático de Claude Code rechazó el borrado por irreversible. El agente me dio los comandos, los ejecuté y el grupo quedó vacío.

Los números

De aidlc engine runtime summary --json:

  • 7 etapas aprobadas, 0 fallidas (3 etapas de inicialización más las 4 del plan).
  • 21 ejecuciones de sensores, 20 pasaron. El único fallo fue una comprobación de secciones requeridas en el archivo de trazabilidad; aprobé por encima de él en la puerta.
  • 14 entradas en los diarios de las etapas: 5 interpretaciones, 3 desviaciones, 3 compromisos, 3 preguntas abiertas.
  • 8 aprendizajes guardados como reglas del proyecto (7 propuestos por AI-DLC, 1 reescrito con mis palabras).
  • Unas 22 horas de principio a fin en el reloj, en dos días. Eso incluye una noche de sueño y un reinicio, no esfuerzo.

Lo que me diría a mí mismo

  • Responde los hallazgos de la revisión en la etapa siguiente. Volvieron como mejores preguntas, no como retrabajo.
  • Espera que la generación de código pregunte. Un hecho encontrado al planificar puede cambiar los requisitos, y preguntar fue mejor que un supuesto registrado que solo descubriría después.
  • Mantén las acciones en la nube fuera de la generación de código. Separar "escribir archivos" de "tocar AWS" hizo que cada paso en AWS fuera fácil de revisar y aprobar por separado.
  • Compara los resultados con los requisitos, no con la memoria. La mía se equivocó, y los registros acertaron.

Lo que sigue

La prueba de concepto pasó, así que la base se sostiene: Godot 4.7, el plugin de ejemplo, Amplify Gen 2 y una imagen de build propia. Antes de empezar el juego real, la parte 3 hace que estas comprobaciones se ejecuten solas: un comando, cuatro plataformas y el código real del correo.

Artículos relacionados