More than 90% of developers now use an AI coding assistant daily. Over 65% of them will also tell you, if you ask, that the code it hands back is often "almost right" — and almost right is the expensive kind of wrong. You don't catch it on read-through. You catch it three sprints later when someone's pagination silently drops the last row.

I've hit this enough times across client SaaS builds to have opinions about it, so here's the actual workflow I run instead of just eyeballing the diff.

Why "almost right" is worse than "obviously wrong"

Broken code that doesn't compile gets caught in five seconds. The dangerous stuff is different: it's syntactically clean, idiomatically styled, and passes a casual review because it looks like something a competent engineer would write. That's exactly the problem — AI models are pattern-matching against millions of examples, not executing your code against your actual database schema or your actual third-party API version.

Three patterns show up over and over.

Hallucinated APIs and parameter assumptions. The model invents a config property that sounds plausible — timeoutMs on a client that actually expects timeout in seconds — and if your types are loose, it compiles fine and fails silently at runtime. This is the one that burns the most hours, because you're debugging a value that was never wrong syntactically, just wrong semantically.

Edge case blindness. AI assistants write the happy path beautifully and then quietly skip the boundaries: off-by-one errors in pagination loops, unhandled null/undefined from a database query that didn't find a match, no retry or backoff on a third-party call that will eventually rate-limit you.

Permissive-by-default security gaps. Nobody's model is suggesting SQL injection outright anymore. But it will default to origin: "*" on your CORS config because that's the fastest way to make the demo work, skip sanitization on a dynamic ORM filter, or reach for a non-cryptographic random generator for something that's actually a token.

None of these are exotic. They're boring, unglamorous, and exactly the kind of thing a rushed human reviewer skims past.

A three-tier verification workflow

The fix isn't "review AI code more carefully" — that's not a process, that's a hope. What works is putting mechanical checkpoints between the AI's suggestion and your main branch, in this order:

AI Suggestion → Type System Validation → Automated Unit Harness → Security Linter

Tier 1: make the compiler do the first pass

This is the cheapest tier and it should be non-negotiable. Turn on noImplicitAny, strictNullChecks, and exactOptionalPropertyTypes in tsconfig.json. If you're in Python, that means actual type hints plus mypy --strict, not decorative annotations nobody enforces.

A strict compiler catches the hallucinated-method and wrong-parameter-type class of bug before a human even opens the PR. It won't catch a wrong-but-valid boundary condition — for that you need tier two.

Tier 2: flip the order and make the AI write tests first

This is the tier that actually moves the needle, and it's the one most teams skip because it feels slower. It isn't, once the AI is generating both halves.

The sequence: ask the assistant to write unit tests covering the happy path, empty input, boundary values, and error states — before it writes any implementation. Review those tests yourself. Then, and only then, have it write code to satisfy the tests you already approved.

The reason this works better than reviewing finished code is that it forces the edge cases into a form you can actually evaluate quickly — a list of test cases — instead of forcing you to mentally simulate every branch of someone else's (or something else's) logic. You're reviewing intent before you're reviewing implementation.

Tier 3: let static analysis catch what review misses

Run security scanners — Semgrep, Bandit, ESLint's security plugins — on every PR that touches AI-generated code, no exceptions. Also audit your dependency lockfile. AI assistants occasionally hallucinate a package name that doesn't exist, and if that name happens to get squatted by someone malicious, you've just added a supply-chain vulnerability to your build (this pattern has a name now: slopsquatting).

This tier is your safety net, not your first line of defense. If tiers 1 and 2 are doing their job, tier 3 should mostly come back clean.

Prompt constraints that prevent the problem upstream

Some of this is fixable before generation even happens. When you're asking for anything beyond trivial glue code, put boundaries in the prompt itself:

• No external dependencies outside an approved list you specify.
• Explicit error handling required for every null/undefined return path.
• Unit tests required, covering empty arrays, boundary limits, and timeout scenarios.
• Strict typing — no any, no loose type assertions.

None of this is exotic prompt engineering. It's just refusing to let the model default to the laziest version of "working."

The mental model that actually matters

Treat the AI assistant as a fast junior engineer, not an autonomous author. A junior who ships clean-looking code that's subtly wrong isn't a junior you stop reviewing — it's a junior whose code you review more carefully, at the exact places juniors reliably get wrong: boundaries, error paths, and defaults. Strict types, test-first prompting, and CI-level security scanning aren't extra overhead on top of AI-assisted development. They're what makes the speed actually usable instead of a debt you pay back later, with interest, in production.