Applying these rules when AI writes most of the code
These rules don't get less true because a model wrote the code instead of a person. They're sound engineering principles, and sound engineering principles don't have an expiry date. But AI does change where each rule actually bites — this page is about that redistribution, not a rewrite of the rules themselves.
Rules 6, 7 and 8 become the mechanism of control
When a human wrote every line, "I understand this because I wrote it" was your safety net. That net doesn't exist with AI-generated code — you didn't write it, and rereading it carefully is a poor substitute for having actually reasoned through it as you typed. What replaces that net is the test suite: write it first, make sure it tests functionality, not implementation, and aim for 100% business-rule coverage. Do that, and the tests become the actual interface you're programming against — the AI becomes an implementation detail underneath them, free to be regenerated, refactored or replaced without you needing to re-earn trust in it from scratch each time.
This isn't a new idea forced onto an old rule set. It's TDD and BDD taken to their logical conclusion, now that there's a good reason to actually follow through on them every time rather than treating them as aspirational.
Rules 1–4 shift from the code to the prompt and the review
A vague, stream-of-consciousness prompt produces exactly the failure mode Rule 4 describes — poured out with no prior consideration of intent, boundary conditions unhandled, failure modes unconsidered. Except now there's no developer's subconscious to interrogate afterwards when it goes wrong, just an opaque model that can't tell you what it "meant," because it didn't mean anything. Programming with intent now has to happen mostly before you talk to the AI, in the prompt and the spec, and after, in the review — there is no "during" you're party to any more.
There are no shortcuts hits differently too. AI makes it strikingly easy to generate a large volume of shortcut-laden code, fast, that "just works" on the happy path — the exact prototype-to-production trap Rule 1 describes, just compressed from weeks to minutes.
Reviewer fatigue from fluency
AI output reads as confident and clean even when it's wrong. Rule 2 was written assuming sloppy code looks sloppy — that a reader gets a visible cue to slow down and look closer. That assumption breaks with AI: fluent, well-formatted, plausible-looking code invites a skim-and-approve instinct exactly when it needs the opposite. Confident and correct are not the same thing, and AI output is confident by default.
Two practical additions
- You own it, even if you didn't type it. "The AI wrote it" can't become a valid excuse in a postmortem, any more than "the framework did it" or "a contractor wrote it" ever was. This is really an accountability corollary to Rule 5 — it's the rule that stops "AI-assisted" quietly becoming "nobody's fault."
- Verify AI-asserted facts before you trust them — especially dependencies. LLMs hallucinate plausible-sounding package names, API methods and config flags with total confidence. There's already a name for the attack this enables — slopsquatting — where bad actors register the hallucinated package name an AI keeps confidently suggesting, banking on someone installing it unchecked. Rule 5 already says to ensure your third-party modules are secure; in the AI era that has to start with ensuring they exist at all, and are the real thing.