Your work vs the AI's, and how you verify
Give one concrete story of overruling the AI and one of catching its mistake. Then show that verification is yours: a review at the end of each feature, and deliberately testing the things that pass a quick test but fail later. Never say "if it works, it's correct".
What went wrong in the mock
- "The design doc shows my decisions" is true but abstract. They want a 30-second story.
- "I test everything as I go as directed by the agent": that says the AI writes the code and decides how to check it. That's exactly what they're probing.
- "If it works without performance issues, it's correct" is the classic red flag. Not seeing a failure doesn't prove there isn't one.
Your evidence (use it)
- Overruled the AI: it proposed typed sockets with GUIDs; you rejected both because THRUST's attach UX never needed them, and the design doc records why. Also: killing node retyping on a semantics argument, and correcting the AI's inverted cluster/Niagara model.
- Caught the AI: a previous assistant left the build broken with a botched merge. You caught it by diffing against the last compiling commit rather than trusting its account.
- Process: each major Part ends with a whole-branch review, and the findings get fixed in their own commits
(
31c86b6: 8 findings,6862f4f: 6,9c46084: 8). - Reasoning, not observing: commit
5e6ac53records that an invariant depends onOnRegister. - WadOfGore: you're porting the lecture code in by hand rather than merging it: "lecture work gets ported in by hand from here on, not merged".
What you specifically test
The list on the GC page: GC (raw pointers), undo/redo, save and reload, full restart vs live coding, packaged vs editor.
"Authorship: the architecture is mine, and I can show where I overruled the AI. For example, it proposed typed sockets with GUIDs; I rejected both because the game's attach UX never needed them, and the design doc records why. Verification: I don't treat 'it runs' as proof. Each feature ends with a whole-branch review, and the findings are fixed in their own commits. You can see them in the history. I specifically test what passes a quick test but fails later in Unreal: undo, save and reload, a full restart rather than hot reload. And my C++ reading speed is the weak point. Where I can't yet explain a line, I make the AI explain it until I can, and that's the gap I'm closing."
Delete "vibe-coded" from your vocabulary. State the gap once, plainly, without adjectives, and never volunteer a second one.
Quiz yourself
Why is "I test as the agent directs" a bad answer?
It says the AI both writes the code and decides how it's checked. Verification is the part that must visibly be yours.
Give your 10-second "I overruled the AI" story.
It proposed typed sockets with GUIDs; I rejected both because the actual attach UX never needed them, and the design doc records the reasoning.
Give your 10-second "I caught the AI" story.
An assistant left the build broken after a botched merge. I found it by diffing against the last compiling commit instead of trusting its summary.
Why is "it works without performance issues, so it's correct" a red flag?
Many Unreal bugs work in testing and fail later (GC, undo, reload, packaged builds). Not having seen a failure isn't evidence there's none.
What evidence in git shows a verification process?
End-of-feature whole-branch reviews whose findings are fixed in their own commits (e.g. 8, 6 and 8 findings on three Parts).