Learning AI-DLC building a game, part 2: a proof of concept

This is part 2 of a series on learning AI-DLC by building a game, World Rift Conflict, in Godot with an AWS backend. Part 1 covered the setup and the first stage of the first piece of work. This part finishes that piece of work: a proof of concept.

Parts so far:

• Part 1: setup
• Part 2: a proof of concept (this post)
• Part 3: automated E2E tests
• Part 4: what the reviews caught
• Part 5: inside a stage

TL;DR

1. The question was narrow on purpose: can a Godot 4.7 game sign a player up and in with the AWS sample Amplify plugin, which was built for Godot 4.3? It can, with no changes to the plugin.
2. Requirements Analysis turned the reviewer's findings from Intent Capture into questions. My answers made the proof of concept bigger than I first planned: the web build is built and hosted by Amplify, using a custom Godot build image.
3. Code Generation asked before it planned, because two facts contradicted the requirements. Part 1 said I would approve the plan before any code; that was wrong. Plan approval is off for a poc.
4. Build and Test is where the AWS work happened, one step at a time, each after my go. The first Amplify build passed.
5. The best moment was a miss: when I resumed the next day, AI-DLC found that the saved results did not cover two of the required checks. I ran them, and that check became a project rule.

The question

The game's backend will be AWS Amplify Gen 2, and the client is Godot 4.7. The only Godot client for Amplify I know of is the AWS sample plugin, last released for Godot 4.3. If that does not work on 4.7, a lot of later planning changes. So the first piece of work was a poc scope with one question:

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

AI-DLC planned four stages, each ending at an approval gate: Intent Capture (part 1), Requirements Analysis, Code Generation, and Build and Test.

Requirements: the review becomes the questions

The Intent Capture review in part 1 left four findings, which I accepted as risks at the gate. Requirements Analysis did not forget them. Its questions went straight at them: what exactly counts as signed in, which failures to check, how sign-up is confirmed, and where the checks run. My answers, from the questions file:

• Pass signal: the game shows "Signed in as <email>", with the email read back from Cognito, not copied from the form.
• Failure case: a wrong password only.
• Confirmation: Cognito emails a code, and the player types it into the game.
• Where: a Linux desktop build, and a web build on Amplify Hosting, in Chrome.

My answer about the web build raised a follow-up question, and then a second one, which AI-DLC flagged as a conflict with the intent. Building the web export on Amplify Hosting needs Godot inside Amplify's build, which means a custom build image. The intent statement said this was the cheapest way to check the setup, and a custom image is not cheap. It asked me to choose. I chose to keep the image in the proof of concept: the real game will deploy the same way, so I would rather find the problems now.

The result was requirements.md with FR1 to FR5 and two non-functional requirements. Each has Given/When/Then acceptance criteria and a source tag that points to the answer it came from. The product-lead reviewer returned READY with five minor findings, and I approved.

Code generation: it asked before it planned

I expected a plan to approve. Instead, the first thing Code Generation did was ask three more questions, because it had found two facts while planning:

• Amplify Hosting accepts custom build images only from Amazon ECR Public.
• My machine had no Docker to build the image.

I chose to install Docker and push to ECR Public; to point the desktop build at the main branch backend; and to let the agent create the Amplify app with the AWS tools, but only after my go.

Then it wrote a 16-step plan and started building straight away. Part 1 said Code Generation would stop for plan approval before any code was written. That was my mistake: for a poc, plan approval is off, and the engine says so:

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

A developer subagent built it in about 15 minutes:

• game/: the Godot project, with the plugin (v0.3.1) copied in unchanged and its source recorded, a sign-up / confirm / sign-in screen, and 7 tests run headless in Godot.
• amplify/: an Amplify Gen 2 backend with authentication only: a Cognito user pool with email sign-in.
• build-image/Dockerfile: Amazon Linux 2023 with Node 24, Godot 4.7.2 and its web export templates, every download checked against a pinned checksum.
• amplify.yml, a committed-secrets check, and a runbook with the end-to-end steps.

The plugin needed no changes for Godot 4.7. Amplify's default needed one. The plugin signs in with Cognito's USER_PASSWORD_AUTH flow, and Amplify's default user pool client does not allow it, so the backend adds it:

// 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',
]

That flow sends the password to Cognito inside the TLS request instead of using SRP. The architecture reviewer flagged it, and it is now a project rule: fine for a proof of concept, to be revisited before the game has real players.

The reviewer returned READY with five minor findings. The most useful was blunt: nothing proved the web export actually worked yet. At the learnings question I kept four notes. One of them changed how later stages run: Code Generation writes files and runs local checks only; every AWS action happens in Build and Test, after my go.

What got built

The steps on the right are the order things happen in. Two ideas carry most of it: Amplify runs its whole build inside my image, and the game reads its backend's IDs from a generated amplify_outputs.json that is never committed. The frontend phase of amplify.yml shows both:

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

Build and test: the AWS part

First, the reviewer's open point. The agent exported the web build locally with a stand-in outputs file, served it, and opened it in Chromium. No console errors, and the sign-up screen showed:

Then the AWS steps, each one stopping for my go. Most of the friction was mine to fix, not the agent's:

• Docker on Ubuntu 26.04. After adding myself to the docker group, nothing changed until a full restart. newgrp is not installed there.
• The image build failed once on a network error while downloading the export templates, then built: 1.11 GB, amd64, Godot 4.7.2.
• ECR Public refused: my Amplify permission set had no ecr-public rights. The agent wrote an inline policy limited to the one repository. The first create still failed, because the agent added a tag and the policy did not allow ecr-public:TagResource. The second try, without tags, worked.
• The service role. The IAM wizard's Amplify use case forces AdministratorAccess-Amplify, with no way to pick another policy. I created the role, then swapped the policy for AmplifyBackendDeployFullAccess on the role's Permissions tab.

I pushed to GitHub (in this project that is always my step), connected the repo in the Amplify console with the custom image and the role, and the first build passed: build, deploy and verify all succeeded. The build log shows Node v24.22.1 and Godot 4.7.2.stable running inside the image.

The end-to-end checks are manual, from the runbook, and I ran them:

Check	Linux build	Web build on Amplify
Sign-up and emailed code	pass	pass (Chrome; also iPad WebKit)
"Signed in as <email>"	pass	pass (Chrome 156, iPad)
Wrong password	pass: "Sign-in failed: Incorrect username or password."	pass, same message
Loads and runs	yes	Chrome 156, Firefox 157, iPad WebKit

What the tests caught

I ran most of those checks in one session and stopped before the stage closed. The next day I resumed (aidlc engine state unpark first, because the work was parked), and Build and Test compared the saved results with the requirements before writing its summary. It found a gap: sign-up had only been tested on the iPad, but FR4 and FR5 require it in the Linux build and in Chrome.

My first reaction was that I had already done it and told the last session. The agent showed me the saved table, and I had to admit that sign-up had only run on the iPad. I ran both with fresh email addresses, and both passed. At the learnings question I kept the lesson as a project rule: record each end-to-end result per requirement and per platform, and compare it with the requirement before calling Build and Test complete.

One loose end is still in the record as unresolved. I remember using two different new addresses for the Chrome and Linux sign-ups, but the user pool showed only one account created that day. The results are recorded as I reported them, with the discrepancy noted next to them.

The summary marked all 12 targets (FR1 to FR5 with their sub-requirements, NFR1 and NFR2) as Met, and I approved: "That is everything on the plan. Your work is finished and written up."

The cleanup had one more guard. When I asked the agent to delete the test users, Claude Code's auto mode refused the deletion as irreversible. The agent gave me the commands, I ran them, and the pool was empty.

The numbers

From aidlc engine runtime summary --json:

• 7 stages approved, 0 failed (3 initialization stages plus the 4 in the plan).
• 21 sensor runs, 20 passed. The one failure was a required-sections check on the traceability file; I approved past it at the gate.
• 14 stage diary entries: 5 interpretations, 3 deviations, 3 trade-offs, 3 open questions.
• 8 learnings saved as project rules (7 offered by AI-DLC, 1 rewritten in my own words).
• About 22 hours from start to finish on the clock, across two days. That counts a night's sleep and a reboot, not effort.

What I would tell myself

• Answer the review findings in the next stage. They came back as better questions, not as rework.
• Expect Code Generation to ask. A fact found while planning can change the requirements, and asking was better than a recorded assumption I would only find later.
• Keep cloud actions out of code generation. Splitting "write files" from "touch AWS" made each AWS step easy to review and approve on its own.
• Compare results with requirements, not with memory. Mine was wrong, and the records were right.

What is next

The proof of concept passed, so the stack holds: Godot 4.7, the sample plugin, Amplify Gen 2, and a custom build image. Before the real game starts, part 3 makes these checks run by themselves: one command, four platforms, and the real emailed code.