Rules Standing instructions
Conventions that always apply: how work gets briefed, what gets written down, what an agent may never do. They hold without being repeated each time.
Client work · EDHLAB
How I ship with AI
This is the process behind 20+ merged fixes on a live multiplayer game platform. AI does most of the typing and none of the deciding. Every number below comes from real work on a real product with real users.
The scoreboard · since mid-August 2026
- Issues run
- 40+
- bug report to reviewed fix, since mid-August 2026
- Fixes merged & live
- 20+
- reviewed, approved, in the product now
- Correct no-ships
- 6
- the right answer was to ship nothing
The setup · the ground it runs on
A notes system is the control room
The pipeline doesn't live in the code. It lives in my personal wiki, where every issue gets a plan, work is sent out to AI agents with written instructions, and every result comes back and gets written down. The code changes elsewhere; the memory stays here.
Recipes Workflows, written once
The whole loop below is a named, step-by-step recipe. Run it on a one-line fix or a gnarly bug; the steps and the safety checks are the same either way.
Memory Write everything down
Wins, decisions, and especially dead ends. "We checked this and it wasn't the cause" is the cheapest note to write and the most expensive one to skip.
Gates Two human checkpoints
Nothing starts without me agreeing on the problem, and nothing goes out for review without me approving it. Everything in between is delegated.
The client · where it runs for real
EDHLAB: a live game platform
EDHLAB (edhlab.gg) is an online platform for playing Commander, a popular format of Magic: The Gathering. I work on it as a freelance developer: real users, real games in progress, a real cost when a fix breaks something.
That's exactly why it's the right proving ground. A method that only works on toy projects isn't a method. Everything on this page ran against a production app where a bad change is visible to players the same day.
One honest boundary: the code belongs to the client. What you'll see here is the method, the numbers, and the lessons. Never the code itself.
20+
fixes merged & live
This isn't a demo. The loop has been running for weeks. More than forty issues have gone through it; over twenty fixes were reviewed, approved by the client, and merged into the live app. The newest ones went from bug report to a review-ready fix in a single sitting.
And the loop is getting cleaner as it learns. The most recent runs landed with zero review findings: five independent reviewers looked and had nothing to change. Meanwhile six issues correctly ended with no code at all, because the honest answer was "this is already fixed," "this isn't a bug," or "this needs a design decision first."
The shape
One loop, two human checkpoints
The loop · once per issue
Eight steps, two checkpoints
Every issue, from a typo to a game-logic bug, runs the same loop. AI does the reading, the building, and the first rounds of review. I make the two decisions that matter: what we're actually fixing, and whether it goes out.
1
Agree on the problem
Checkpoint 1- Me
- Answer five questions before anything runs: why this issue, what's in scope, do we already know the cause, one fix or several, does it need a live playtest.
- The AI
- Gathers the issue, the screenshots, and the related history, and puts the questions in front of me.
- Why
- The most expensive bug in AI-assisted work is a perfect fix for the wrong problem. Five minutes here is the cheapest insurance in the whole loop.
2
Find the real cause
- Me
- Read the findings; decide whether they hold up.
- The AI
- A research agent traces the bug to its root cause in the code, with evidence, before anyone writes a fix.
- Why
- This step is allowed to end the loop. One issue turned out to be already fixed by the client. Another needed proof it wasn't a bug, not a patch. Six issues have ended this way, on purpose. Each one is a fix that didn't get made to code that didn't need it.
3
Write the brief
- Me
- Read it. The brief is the most important artifact in the system, and a bad one is paid for by everything downstream of it.
- The AI
- Turns the research into written instructions for the builder: what to change, what's out of bounds, what "done" means, and what has already been ruled out, with dates.
- Why
- Every file the brief mentions is checked to exist before the brief is used. And the "already ruled out" list is dated on purpose, because a stale claim the builder is told not to question becomes its blind spot.
4
Build it, test-first
- Me
- Steer when asked; otherwise stay out of the way.
- The AI
- Writes a test that fails because of the bug, then the fix that makes it pass. If the game's core logic changes, a mirrored check runs against the mobile app so web and mobile can't drift apart.
- Why
- A test that failed first is proof the test can fail. A test written after the fix might be agreeing with it.
5
Prove it on screen
- Me
- Look at the actual before and after with my own eyes.
- The AI
- Runs the app twice, once without the fix and once with it, through the same flow, and captures both.
- Why
- "A render test proves an element exists, not that it lands anywhere sensible." On one issue, three green tests and a clean build missed three visual problems: buttons covering the header, dead space, a wrong font size. The screenshots caught all three. That lesson cost an afternoon and is now a permanent step. Passing tests are necessary, never sufficient.
6
Review it hard
- Me
- Decide anything about scope or how the product should behave. Those never get auto-applied.
- The AI
- Five reviewers look at the change independently, each with a different specialty drawn from this project's own history, hunting for the exact failures that already happened once. Then every finding is attacked: a second pass tries to prove each one wrong before it reaches me.
- Why
- Only fixes that are mechanically unambiguous, change nothing on screen, and are trivially reversible get applied automatically. Everything else comes to a human.
Exhibit · why findings get attacked
The reviewer was right about the math and wrong about the screen.
One reviewer flagged a spacing change. By its arithmetic, the change ate the entire safety margin around an element, leaving zero clearance. The numbers checked out. The finding still died, because the attack pass asked the question the reviewer hadn't: what does the layout actually do with those numbers? A neighboring rule canceled the change out. The real clearance was fine.
A confident, numerically correct finding was wrong about the thing that matters, what users see. That's why no finding reaches me without surviving an attempt to kill it.
7
Open the pull request
Checkpoint 2- Me
- Approve the summary, open the request. The AI never merges. Ever.
- The AI
- Assembles the change, the proof, and the review results into one reviewable package, written in my voice, not a robot's.
- Why
- Releasing to real users is a human decision by design, not a limitation. An agent reporting "done" is a claim, not a fact, and never my approval. The client merges when the client is ready.
8
Write it down
↻ back to 1- Me
- Confirm the outcome.
- The AI
- Files the result, the evidence, and any new lesson back into the wiki, including what was ruled out and why.
- Why
- This is why the loop gets better instead of just faster. The visual-proof lesson, the review specialties, the known traps: all of them are step-8 notes from earlier issues.
The layer underneath · hard-won rules
Guardrails, and the misses that made them
None of these are theory. Each one exists because something got through without it.
01 Two human checkpoints
Agree on the problem before anything runs; approve the result before it goes out. Everything between is delegated. Judgment stays at the edges.
02 "No fix" is a success
Six issues ended with no code shipped, correctly. A pipeline that can only say yes is a liability.
03 Green tests aren't proof
Tests prove the logic; only looking at the screen proves the experience. Every fix carries a before-and-after from the running app.
04 Attack every finding
Review findings are guilty until proven innocent. Each one survives a deliberate attempt to disprove it, or it dies before it reaches me.
05 Write down the dead ends
"We checked, it's not that" saves the next investigation from paying for the same conclusion twice. Dated, with evidence.
06 The AI never releases
It can research, build, prove, and review. It cannot merge, and it cannot decide that users should get the change. Those are mine and the client's.
Miss → rule · shipping without the review gate
Before the review step existed, three changes went out with problems no test would catch: wrong scope, a "fix" for a non-bug, sloppy formatting in the write-up. None failed on code quality. The five-reviewer gate was built directly from those three misses.
Miss → rule · trusting green tests
Three passing tests and a clean build missed buttons covering the header, dead space, and a wrong font size. On-screen proof became a mandatory step, not a nice-to-have.
Miss → rule · the silent side effect
Rebasing one change on top of another silently broke a neighboring component; only the type checker caught it. Stacked changes now get checked at every layer, not just the top.
The close · what transfers
The method is the product
None of this depends on the project being a game, or on any particular AI tool. It depends on three habits that transfer to any codebase, with or without AI. If you take anything from this page, take these:
- Put humans at the two moments that matter. Agree on the problem before work starts; approve the result before it ships. Delegate everything in between without guilt.
- Demand proof you can see. A green checkmark says the logic holds. A before-and-after of the real screen says the product works. They are not the same claim.
- Write down what didn't work. The loop got faster and cleaner in weeks. The AI didn't improve; the notes did. Every miss became a rule the next run inherits.
And one meta-lesson: build the pipeline from your own failures, not from best-practice lists. Every guardrail above is a specific miss, dated, with a name. That's why they hold.
Honesty legend
- shipped real and done: 20+ merged fixes, the review gate, the visual-proof step, the loop itself
- in progress the newest fixes are open and awaiting the client's merge; counts move weekly
- vision running the same loop fully hands-off is designed, not built
What this page is: a faithful picture of a working method, drawn from my own project records as of 2026-08-29. Counts are as recorded in my notes; the live repositories may have moved since. What it is not: the client's code, which stays the client's, or a claim that any of this is hands-off. Two humans still sit at the gates on every single issue.
Built from the real workflow in my wiki: the engagement doc, the per-issue project docs, the two pipeline recipes, and their post-mortems.
Want this rigor on your project?
The loop works on any codebase
Start with a free 15-minute call. You'll leave knowing what your project needs, whether or not we work together.