Learning AI-DLC building a game, part 11: retrospective

This is part 11 of a series on learning AI-DLC by building a game, World Rift Conflict, in Godot with an AWS backend. Part 1 set it up, and part 10 built the first unit. The mvp workflow is now complete, so this post looks back at the whole run.

Parts so far:

• Part 1: setup
• Part 2: a proof of concept
• Part 3: automated E2E tests
• Part 4: what the reviews caught
• Part 5: inside a stage
• Part 6: a bugfix intent
• Part 7: ideation
• Part 8: inception
• Part 9: an AppSync deploy error
• Part 10: walking skeleton
• Part 11: retrospective (this post)

TL;DR

1. One AI-DLC workflow took the game from a brainstorm to seven built and tested units in nine calendar days, with me deciding at every gate.
2. The approval gates and the adversarial reviews earned their cost: the reviews stopped real design bugs before any code existed.
3. The framework struggled with a reopened unit that never routed back, a fixed 30-minute check limit, guards that match file names, and work too large for one agent.
4. The real backend and Stripe still found defects that every local test and review had passed.
5. The first production release took three builds. Two were stopped by guards I had added myself, and both stops were correct. The production smoke check then passed 4 of 4.
6. Then I played it. The match screen did not fit the browser window, and none of the checks had asked whether it would.

What I set out to build

The game is a short strategy match between countries. Each player gets a country with stats taken from public data, plays a few rounds, deals with events, and the best score wins. The first version needed matches against computer-run countries, sign-in and saved results, real-world data events, live online matches for 2 to 4 players, desktop downloads, and owner tools to keep the running cost under about $50 a month. A supporter checkout is built but switched off.

The process was the point as much as the game. I wanted to see what AI-DLC does on a project bigger than a demo: an intent, Ideation, Inception, then Construction unit by unit, with an approval gate between steps and a written record of every decision.

The run in numbers

The counts come from aidlc engine runtime summary --json, AI-DLC's own records and my build log.

Measure	Value
Calendar days	9 (2026-10-29 to 2026-11-06)
Stages run	20, plus 3 setup stages
Units of work	7
Recorded answers in question files	254, across 48 files
Review passes	62: 40 READY, 22 NOT-READY
Sensor firings	166, 47 of them failed
Lessons captured	35
Loop-backs	1
Godot test cases	454, 0 failures
GDScript coverage	87.1% of statement lines (3818 of 4385)
Requirement targets checked at the end	223: 187 Met, 1 Not Met, 34 Unverified, 1 N/A

The TypeScript side has its own suites. At the end of the last unit, test:unit passed 213 of 213, test:backend 151 of 151, test:owner 82 of 82, test:infra 88 of 88, and test:live 95 with 2 skipped. The end-to-end suite runs on four platforms: the Linux build and the web build in Chromium, Firefox and WebKit. Its final runs had 0 failures on every platform.

The load test for live matches ran 20 bots for 30 minutes on a temporary host: 134 round results, a maximum of 439 ms, p99 216 ms, and 0 errors.

What AI-DLC did well

The gates kept me in charge. Every Ideation and Inception stage stopped for my approval before the next one started. Code Generation showed me a plan and waited for "Approve Plan" before writing code. Each round of questions ended with a summary I had to confirm. When I disagreed with a recommendation, my answer won. For the supporter checkout, the agent recommended a merchant of record and I picked Stripe Checkout. After the walking skeleton I chose "Continue automatically", and the routine approvals stopped coming to me. Plan approvals, failures and every AWS action still did.

The adversarial reviews caught real bugs on paper. A separate reviewer agent read each stage's output and could answer NOT-READY. It did that 22 times. Some examples from the owner tools unit's design stages alone:

• a live match with 3 humans would have counted as 3 finished matches;
• a checkout completing after the account was deleted would have left a paying subscription that nobody cancels;
• the design scoped roles by a key prefix that IAM cannot scope by.

Earlier, a reviewer showed by reasoning alone that the first unit's score model made the balance check impossible. None of these needed a test to find. They were fixed in a design file, before any code.

Lessons became rules. At each gate AI-DLC asked "Anything to add for next time?". The answers went into project.md as rules that every later stage reads. Some came from pain: check AppSync resolvers with evaluate-code before the first deploy, read a deploy tool's error lines and not only its exit code, trim secrets on read, fresh-deploy every host before its checkpoint, and audit what ships.

The record is complete. Every question, answer, review and decision sits in files I can cite. This series is written from them.

Where it struggled

A reopen that never routed back. During Build and Test I found that one acceptance criterion, AC2.5.3 ("a former player"), was deferred from one unit to another and never built. AI-DLC let me reopen the unit, and recorded the rejection, but next kept routing to Build and Test. aidlc doctor reported "0 problems, 5 warnings", none of which explained it. I accepted it as a known gap, to be built in a follow-up before launch. The state file still shows Code Generation as in progress.

A fixed 30-minute limit on checkpoint checks. AI-DLC stops a checkpoint's verification command after 30 minutes. The first time I hit it, the command was killed and left its test runner orphaned, still running an hour later. The four-platform suite had grown past that limit, so I split it: Linux and Chromium inside the check, Firefox and WebKit as a separate recorded run before each checkpoint. The last unit's check finished in 27.3 minutes, close to the limit again.

Guards that match names. One AI-DLC guard protects the audit trail. It refused the agent running the pre-push script, because a new log file was named pre-push-check-audit.log and "audit" matched the rule. My own pushes are unaffected, and a rename is still open. Earlier, the plan guard refused every shell command, even cat and grep, until the plan file existed.

Work too large for one agent. The owner tools build had 45 tasks. The first developer agent stopped on an API credit limit ("Credit balance is too low"). Resumed, it stopped again at task 29 to stay within its context. A fresh agent, briefed with a written handover, finished the rest. Resuming had its own cost: one resume delivered the stage rules in three parts before any work started.

Rules are read, not enforced. The evaluate-code rule existed when the last unit's resolvers were deployed, and the deploy still ran first. Nothing broke that time, but a rule in a file only helps when someone follows it.

What only the real environment caught

Each of these passed unit tests, scene tests and at least one review.

• A secret with a newline. The supporter checkout failed on all four platforms with "Support is not available right now". The Stripe secret had been stored with a trailing newline, because the setup piped value + "\n", and the code read it untrimmed. This caused the run's one loop-back: Code Generation for that unit was reopened, the fix got regression tests, and the review came back READY.
• Stripe's hosted pages and automated browsers. Stripe showed an hCaptcha check to the test browsers, and "Subscribe" stayed on "Processing" for 3 minutes. I chose to pay through Stripe's test API instead. The scenario still checks that the real checkout and billing pages open with the right product and price.
• Three boot bugs on the live host. The first fresh deploy of the live-match server never came up. The network wait treated the probe address's 403 as "no network". The log folder was 0700 root, so the proxy exited. And the server's "am I the main program" check failed when it was started through a symlink. Each fix got a regression test that failed first.
• An audit that checked nothing. npm audit --omit=dev at the root passed, but every root package is a devDependency, so it audited nothing. The new check:audit audits the 42 packages the runtime code imports: 0 advisories.

The pattern from part 10 held to the end. Reviews catch what can be reasoned about. Deploys catch what the platform does.

The release

Pushing main deploys production, and that is my step, not the agent's. The push carried about 80 commits: the whole game. It took three builds.

1. Build 1 stopped at the new spending-alert check: the Amplify build role could not list the alert topic. Nothing was deployed, and production kept its old version. That is the check doing its job. I added a small read-only policy to the role.
2. Before the next build, the production Stripe placeholders had to exist. The command that writes them failed with exit 252, because this AWS CLI version cannot read --cli-input-json file:///dev/stdin. The unit tests used a fake CLI, so they never saw it. The fix writes the input to a private temporary file, with a regression test.
3. Build 2 passed the read rights, then stopped on the budget: AWS held five alerts, and the check expected exactly four. Someone, almost certainly me, had added an "actual over $50" alert in the console. I chose to accept extra alerts, since an extra alert can only warn more.
4. Build 3 succeeded. The production smoke check passed 3 of 4 at first, because my own role could not read the production table: branch deploys name their tables after the app ID, not the app name. One more resource pattern, and it passed 4 of 4: the game loads and starts, the download page loads, the live host is healthy with its alarm on, and the supporter checkout is off.

Every one of these stops was a check I had asked for, failing closed on a real gap. That is the outcome you want from a gate. It still cost an evening.

What the first real play found

The smoke check proves the game loads and starts. Then I played the production web build for the first time, and the match screen did not fit the browser window. The sliders and the proposal rows were cut off at the left, the player list at the right, and the top bar's buttons at the top. Long explanations sat on the main screen, the proposal area repeated the same three buttons for every country, and there was no banner, map or flag.

All the suites were green, because none of them asked whether a control fit inside the window. That question now has its own piece of work, separate from the finished mvp workflow: a layout that fits, short labels with help on demand, and visuals. It is in progress and not yet released.

Reviews catch what can be reasoned about, and deploys catch what the platform does. A person playing the game catches what nobody thought to check.

What is next

The UI work comes first. After it: AC2.5.3, then the targets that need a month of data (follow-ups dated 2026-12-05), and the one Not Met target (NFR3.5, because Amplify adds AWS_IAM). After that: SES production access for sign-up emails, the Windows and macOS builds, and a few open game items, such as military-strength countries trailing in balance. The supporter checkout stays off until the running costs are known.