Review code you can't read
You don’t need to read it. You need to ask it four questions.
A developer, or an AI, hands you code. You can’t read it, that’s the whole reason you paid someone or asked an assistant to write it. But “I can’t read it” and “I can’t review it” aren’t the same thing. You can judge code you can’t read, the same way you can judge a contractor’s work without knowing how to lay bricks: not by inspecting the technique, but by asking the right questions and checking the answers hold up.
Four questions, asked every time, in order.
What you’ll need
- Code someone or something handed you, ready for review
- The AI assistant that wrote it, or any AI assistant if a human wrote it
- About fifteen minutes
“Explain what this does, in plain English, no jargon”
Paste the code, or point the assistant at it, and ask exactly that. Not “explain this code”, which invites a technical answer. Ask it to explain what it does, for a reader who doesn’t code.
Read the explanation against what you actually asked for. If you asked for “a form that emails me when someone submits it” and the explanation mentions a database, or a payment step, or anything you didn’t ask for, that’s not automatically wrong, but it’s a question, not a shrug. Ask why it’s there.
This step alone catches the most common problem: scope creep, where something does more than you asked, sometimes helpfully, sometimes not.
“What’s the worst thing that could go wrong if this runs?”
This is the question that surfaces risk without requiring you to spot it yourself. A good answer names something concrete: “if the API key is wrong, it fails silently and nothing sends.” A bad answer is vague reassurance: “it should work fine.”
If the answer mentions something touching money, user data, or anything irreversible, like deleting records, sending real emails, or charging a card, that’s the part worth a second, more specific question: “walk me through exactly what happens if that goes wrong, step by step.”
You’re not trying to become the engineer who prevents the failure. You’re trying to know, in your own words, what the failure looks like if it happens, so it isn’t a surprise.
“What did you add that I didn’t ask for, and why?”
Code rarely arrives as only the thing you requested. Libraries get added, extra files get created, small “while I was in there” changes happen. Most are reasonable. Some aren’t.
Ask directly. A trustworthy answer lists specifics: “I added a validation library because the form had no input checking.” An answer that’s vague, or that argues the question doesn’t matter, is itself information.
This is the step that catches hidden scope: not a thing done badly, but a thing done that nobody mentioned. Nobody has to be malicious for this to matter. Most of the time it’s just enthusiasm running ahead of the brief.
“How would I know if this breaks, without you telling me?”
The real question underneath this one: is there a test, a log, an error message, anything that surfaces a failure on its own? Or does it fail silently, and you only find out when a customer complains?
A good answer points at something concrete you can check yourself: “there’s a test that runs automatically” or “it’ll show an error message if the email fails to send.” Ask to see that yourself, actually see the test run, or actually trigger the error and watch it appear. Don’t take the description as the proof.
If the honest answer is “you wouldn’t know,” that’s not disqualifying by itself, but it means you’re accepting silent failure as a trade-off, and that should be a decision you made on purpose, not one nobody mentioned.
Putting it together
Four questions, four answers, and you now know: what it does beyond what you asked, what happens when it breaks, what got added without your say-so, and how you’d find out if something went wrong. That’s a real review. It doesn’t require you to read a single line of code, and it catches the things that actually cause damage, which are almost never “the code was badly written” and almost always “nobody told the owner what it does.”
The short version
- “Explain what this does, in plain English.” Check it against what you asked for.
- “What’s the worst thing that could go wrong?” Push for specifics, not reassurance.
- “What did you add that I didn’t ask for, and why?” Vague answers are themselves an answer.
- “How would I know if this breaks?” See the proof, don’t just hear the description.
Sources
This one draws on judgment and pattern, not external facts to cite. The method is the guide.
Written August 2026.
Prints to PDF from your browser — colours and all.