Always start from the facts — write the rules, then keep fixing them
Article four. Everything so far comes down to one sentence: AIs act on guesses, so I have to demand facts. Here are the rules I actually run on, and how each one came about.
The rules came out of accidents
None of this was designed up front. Every rule was added after something broke, which means every one of them has a reason.
The non-negotiables
1. Check the source and GitHub first
Why: the AI kept proceeding on "it should be like this", clashing with the actual code and forcing rework.
Rule: before saying anything about a spec, an implementation status or a PR, verify against the real code or the GitHub API. Anything unverified must be labelled as such.
2. Separate investigation Issues from implementation Issues
Why: asking for "look into it and fix it" in one go meant the AI drifted into implementation mid-investigation, changing code before the approach was settled.
Rule: finish the investigation as an investigation, let me review the result, then file a separate Issue for the implementation.
3. Fix root causes, not symptoms
Why: a display bug got "fixed" by overwriting the display, and the same underlying cause resurfaced elsewhere later.
Rule: don't hide a bug with another bug. Identify the cause before fixing. "It works for now" gets rejected.
4. Report problems all at once
Why: every fix was followed by "ah, there's one more", and we went round in circles.
Rule: everything found in the first review comes out together. No drip-feeding.
5. No code until the go-ahead
Why: what I intended as a loose discussion had already turned into implementation.
Rule: share the problem → define it → propose a solution → wait for the go-ahead. Don't skip steps.
6. Merges happen after my instruction, performed by the AI
Why: same as above. The production decision stays with me.
Rule: the AI presents the preview URL and stops. Once I've checked it and said "merge it", the AI performs the merge and the production deploy. The judgement is mine, the operation is the AI's.
The workflow document
All of this lives in a document at the repository root, which the AI reads before starting work. It covers who does what for each kind of task, Issue templates, and troubleshooting.
The important part is not treating that document as finished. When something goes wrong, add a line immediately. When rules pile up, consolidate. The moment the document diverges from reality, the AI will believe the document.
Examples of it being revised
- "The AI can't write workflow files" → later it could → rule updated
- "Re-run FTP manually" → happens too often → "the AI notices the failure and re-runs it" written into the procedure (the workflow itself doesn't auto-retry)
- "One Issue, one purpose" → tightened further with "three changes maximum"
- "Memory is a reference" → after an accident, upgraded to "never grounds for a decision"
This is also a story about me
Honestly, half these rules exist to stop me taking the easy road. The urge to hand everything to the AI is always there. But every time I skipped a check, something broke. The biggest variable in AI-assisted development turned out to be my own diligence, not the AI.
What I wish I'd known
- Write the rules document first, and grow it with each accident
- Make the AI say "unverified". Keep guesses separate from facts
- Don't mix investigation with implementation, or discussion with instruction
- Your own diligence becomes the quality of the product
Series: "I wish I'd known this from the start"
- Start with GitHub, whatever else you do
- Where I got stuck connecting GitHub
- Don't trust the AI's memory. Keep everything in GitHub
- Working with Xserver — FTP, .htaccess, and deploys that fail
- Always start from the facts — write the rules, then keep fixing them (this article)
- The parts that were genuinely hard, and what I did about them
- AdSense keeps rejecting my site
- Just write @claude in an Issue, and Claude Code gets to work
- Can you really hand game dev off to AI?
- Goodbye, ChatGPT — Banned Twice, Moved to Claude
- How I Get Claude to Make Pictures