Never ship code you can't explain

1. The rule

One rule, no exceptions:

Never let code into your project that you couldn't explain, line by line, in a thirty-second interview.

Not "I broadly know what it does." Not "I tested it and it works." Line by line, in your own words, why each line is there and what would break if it were gone.

If you can't, two options. Learn the lines you can't explain. Or delete them and write a smaller version you can.

2. Why this rule

It's the only rule that holds the line between using AI and being used by it. Without it, the line drifts every week — first you accept one line you don't quite get, then a function, then a whole module, and one day you wake up shipping a codebase you've never read.

That's the moment your career changes shape. Before it, you are an engineer who uses AI. After it, you are someone holding a pile of code together by hope. The change is invisible; the cliff is real.

This rule is also the simplest possible fix. It costs nothing. It just requires you to slow down for thirty seconds per chunk and check yourself.

3. The practical version

You don't have to explain everything now. You have to be able to explain it if asked. That's a lower bar than line-by-line review, but it's higher than skim-and-accept.

When AI gives you code:

1. Read it once for shape. Does the overall approach make sense?
2. Read it again for unknowns. Are there any lines, calls, or syntax pieces you'd struggle to explain?
3. If yes, switch to teacher mode and ask. "Why this method instead of X?" "What does this option do?"
4. Then accept it — having actually read it.

This takes maybe ninety seconds longer than blind accept. It is the entire difference between learning and not learning.

4. The check

If you got stuck, that's normal. The point of this rule isn't that you already pass it — it's that you start measuring against it from now on.