When the code you're reviewing isn't what the model wrote

When I review AI-generated code, I read the diff as text. The tool does the same. Which is exactly the gap ASCII smuggling slides through. Microsoft just flagged that ASCII smuggling, the trick once aimed at attacking AI, is now being used by spammers to get invisible text past email filters. A Unicode tag character like U+E0041 renders as a normal "A" to humans and passes thin text filters, while carrying a payload underneath. Your eye sees one thing, the renderer sees another, and the two never meet. The same seam sits right in the middle of AI code review. A coding agent writes a line. An AI reviewer pulls the patch and runs its analysis on the text of that line. If that line contains an invisible Unicode character, the reviewer reads it as a plain ASCII equivalent and moves on. Nothing flags the discrepancy, because nothing looked at the raw bytes. This is not hypothetical for eval design. It means the thing we're measuring is the reviewer's reading of the saanitized-looking diff, not the code that actually exists in the repo. Two copies of the string that differ only in invisible codepoints get scored identically, and the one carrying the payload gets a pass. The fix is boring and it works. Before you hand a diff to any AI reviewer, normalize it: strip or flag all characters outside a strict allowlist of printable ASCII (and the specific non-ASCII the language actually uses, like accented chars in string literals). Run it before the model sees it, not after. That one step collapses the whole class of attack from "the tool reads fake normal text" to "the tool sees literally what is there." A reviewer that claims to review AI code but never looks at the bytes it was handed is reviewing a story about the code, not the code. Cheap to check, cheap to fix. Do it in the intake, and half the sneaky-prompt problems go quiet.