Copilot agent mode doesn’t autocomplete. It builds whole systems from design docs. Point it at a gameplay-type-map, say “build Mission 7 as a Grip-meter Hold On pattern,” and it reads existing code, follows patterns, and produces a playable level.
I’ve done this 297 times across 16 checkpoints. Twelve missions built. 188 files touched. Here’s what the collaboration actually looks like in practice.
The Live-Test Loop
This is the core rhythm:
- Copilot commits code
- I watch the running game via RDP
- I screenshot the symptom
- I send a one-sentence observation: “the character walks through the wall here”
- Copilot reads its own code and fixes
The human isn’t reading code. The human is playing the game and reporting what feels wrong. The agent reads the code. This loop runs in real-time, dozens of iterations per session.
[DIAGRAM: Circular flow diagram showing the live-test loop: Copilot commits → Game runs → Alex plays → Screenshot → One-sentence note → Copilot fixes → repeat]
The Covenant Seal Incident
Turn 140-something. I’m reviewing Mission 5 and find a “Covenant Seal” — a collectible MacGuffin that drives the mission’s puzzle mechanic. It has no biblical basis. Copilot hallucinated it.
The agent needed a game object to solve a design problem, so it invented one that sounded plausible. “Covenant Seal” has the right texture — ancient, religious, important-sounding. But it’s theology fabricated for gameplay convenience.
This became the origin of a permanent rule: no game element can exist without scriptural grounding. The agent doesn’t get to invent theology because it needs a puzzle piece.
The broader pattern: domain knowledge becomes the crucial constraint layer. The AI generates fluently. Too fluently. It’ll produce something that sounds right to anyone who doesn’t know the domain. You need someone who knows when “Covenant Seal” is bullshit.
Five Agents, One Codebase
Multiple Copilot instances run simultaneously on separate git worktrees. Each works on a different mission or system. I context-switch between them — reviewing output, approving plans, catching hallucinations.
The attention bottleneck is real. Five agents producing code faster than I can evaluate it. The question changes from “can I build this?” to “can I review this fast enough?”
The Judgment Calls
Every session surfaces the same decisions:
- Fix vs. delegate: Do I fix this myself in two minutes, or describe it and wait?
- Accept vs. redesign: Is this output good enough, or does the whole approach need rethinking?
- Consistency vs. exception: Does this mission follow the pattern, or does it deserve a unique mechanic?
For bigger features, I require Copilot to produce a [[PLAN]] document first — a structured proposal before implementation. This prevents the agent from diving into changes that don’t align with the vision.
Rules That Emerged From Failures
These became persistent constraints — established mid-project because something broke:
- Biblical fidelity: No invented theology (the Covenant Seal)
- Never trust agent self-verification: The agent saying “it works” means nothing — only the live playtest matters
- No procedural SFX: Sound effects need to be hand-picked audio files, not runtime synthesis
- Full audio replacement: Don’t mix placeholder and final audio — replace everything or nothing per scene
The Thesis
Even when code generation is genuinely good, human roles don’t disappear. They concentrate. Judgment, taste, domain knowledge, creative direction — these become more important as production speed increases, not less.
The agent is a multiplier. The human is the signal.
I write about building with AI agents, the stuff that actually works and the stuff that breaks. Follow me on LinkedIn for more.