I’ve been using AI to write parts of my code, but I’m realizing I can’t always explain what it does or catch possible bugs. It worked at first, then I needed to debug and modify it, and I got stuck fast. I need help figuring out how developers review, test, and truly understand AI-generated code before using it in real projects.
If you can’t explain the code, you don’t own it. The AI does.
Treat AI output like code from a rushed junior dev. Sometimes useful. Often fragile.
What to do:
- Make it explain every function in plain English.
- Add tests before you trust it.
- Ask for a line by line walkthrough.
- Remove magic. Rename vars. Split big functions.
- Change one thing at a time and rerun tests.
- If you still don’t get it, don’t ship it.
A simple rule helped me. If you can’t answer these 3 things, rewrite it:
- What goes in.
- What comes out.
- What breaks it.
AI saves typing, not understanding. That part is still yours. It sucks, but yep, taht’s the job.
Honestly, no, you probably do not understand it yet, and that’s not some moral failure. It just means you borrowed speed and now you owe interest.
I mostly agree with @espritlibre, but I’d push back on the “if you can’t explain it, don’t ship it” rule as an absolute. In real life, teams ship code they only partly understand all the time. The real question is whether the unknowns are boxed in. Small helper script? Lower risk. Auth logic, payments, concurrency, data deletion? Yeah, different story. Do not yolo that stuff.
What helped me was treating AI code like a black box first, then turning it into a glass box. Not just “what does this function do,” but:
- what assumptions is it making?
- what hidden dependencies does it rely on?
- where is state changing?
- what part is actual logic vs boilerplate fluff?
Also, force yourself to delete parts of it. Seriously. If removing a block makes you panic because you have no clue why it exists, that’s the part you need to study. Same with changing constants, input shapes, or error conditions. Poke it until it squeals a little.
Big tell: if you can use the code but can’t predict how it will fail, you don’t really own it yet. That’s where AI code gets people. It looks clean, works on the happy path, then boom, one weird edge case and you’re spelunking through someone else’s fake confidence.
My rule is simpler: if I can’t redraw the logic from memory in rough pseudocode, I’m not done. Not perfect memory, just enough to rebuild the core idea. If I cant do that, I’m still just babysitting it.
I disagree a little with @espritlibre on one point: total understanding is not binary. There are levels.
Level 1: you know what goes in and what comes out.
Level 2: you know why it works.
Level 3: you know where it breaks.
Level 4: you can safely change it.
AI-written code is dangerous mostly when people stop at Level 1 and mistake that for ownership.
A useful test that is different from “explain it back” is this: can you put guardrails around it? Add assertions, type checks, logging, and one ugly test with bad inputs. If the code becomes more trustworthy after that, good. If adding guardrails exposes chaos, then the code was never really under control.
Also, check for “compression fraud.” AI often gives you 40 lines that should really be 8, or hides a simple idea inside fancy abstractions. Shrinking it yourself is a great way to learn it.
Pros of using ': faster scaffolding, less boilerplate, good for exploring approaches.
Cons of using ': false confidence, inconsistent patterns, and debugging debt later.
My rule: before keeping AI code, I should be able to rename variables, delete half the comments, and simplify one branch without fear. If I cannot, it is still rented code, not mine.