An explanation of wrong code is a correct explanation. It describes the wrong formula faithfully, in the right order, and nothing in it sounds worried.
The same login function, described line by line. One of them mentions that the password hashing has been unsafe since 2012.
“The function takes the submitted password, hashes it with MD5, compares the result to the stored value, and returns a session token on a match.”
“Same flow — and MD5 has been unsuitable for password storage since 2012. This needs a slow hash. Also, a failed attempt returns a different message than an unknown user, which lets someone enumerate accounts.”
One describes. One judges — and judging needs a standard that is not in the file.
An explanation of wrong code is a correct explanation. It will describe the wrong formula faithfully, in the right order, in confident technical language — and nothing about its tone will change, because tone follows the writing, not the danger.
The real difference is what each one needs to exist. Description needs only the file. Judgement needs a standard from outside it — the requirement, the security norm, the format finance expects — and that is precisely the thing an explanation never had to consult.
Tap a note, then tap whether it could ever tell you something is wrong. Then see exactly what each one does.
Pick a situation. In every one, somebody asked for a review and received a description.
Every line was described. The description was completely accurate. The passwords were being stored in a way that has been unsafe for a decade.
Five questions. Nothing is scored.
Five terms, not two. Tap one.
Look for comments about errors, risks, or whether the code matches requirements. If the answer only describes what happens, it is an explanation. A review points out problems, checks rules, and may suggest changes.
You may miss hidden bugs, security risks, or requirements that the code does not meet. An explanation alone cannot protect you from problems that a proper review would catch.
AI can explain code clearly and may spot some common mistakes, but it rarely understands your exact requirements or business rules. A human reviewer is needed for context, judgement, and deeper checks.
A bug is a technical mistake that causes the code to fail or behave wrongly. A requirement mismatch means the code works, but does not do what the business or project needs.
You risk shipping code that works in theory but fails in practice—missing bugs, security risks, or business needs. Problems often appear after launch, costing time, money, and reputation.
| Sign | Explanation | Review |
|---|---|---|
| Mentions only what code does | Yes | Sometimes |
| Points out mistakes or risks | No | Yes |
| Checks requirements | No | Yes |
| Suggests changes | Rarely | Often |
Description needs only the code. Judgement needs something to compare it against — and that thing is never in the file.
Copyright © Pawan Nayar · LLOS.ai · 2026 — Code review vs Code explanation: saying what it does, versus saying what is wrong with it.Original pedagogy, voice, and design — all rights reserved.