The AI wrote it confidently and it was completely wrong

The confidence is the problem

LLMs don't hedge. They don't write // not sure about this endpoint in a comment. They produce fluent, plausible-looking code with the same tone whether they're certain or completely fabricating. That's what makes them dangerous on client work.

When you're billing someone for a deliverable, a hallucinated dependency isn't a funny anecdote. It's a broken handoff. It's you on a call explaining why the thing doesn't work. It's trust, spent.

What actually goes wrong

From what I've seen working on client projects, the failure modes cluster around a few things.

Fabricated APIs. The model knows a library exists. It doesn't know the exact method signature, so it invents one that sounds right. You don't catch it until runtime, sometimes not until the client does.

Invented dependencies. A package name that almost exists. Close enough to pass a quick read, not close enough to install.

Context drift. You paste in a file, the model starts well, then forty lines down it's writing for a different schema, a different framework version, a different assumption about how your data is shaped. It forgot the constraints. It didn't tell you.

Silent rewrites. You ask it to fix one thing. It fixes that thing and changes three others. Nothing breaks immediately. Something breaks later, in production, in a way that's hard to trace.

The discipline that actually helps

I don't think the answer is less AI. I think the answer is treating AI output the way you'd treat code from a junior developer who's very fast, very confident, and occasionally makes things up.

You wouldn't merge that without reading it. You wouldn't skip the test run because the diff looked clean.

A few things that have changed how I work:

Run it before you read it. Don't review AI-generated code before you run it. Run it first. If it doesn't execute, the review is moot. If it does, your review is more honest because you're not convincing yourself it works while reading it.

Check imports and package names explicitly. Don't skim the import block. Open the actual package registry. A hallucinated package name is almost always in the import block.

Scope the context deliberately. Don't dump your entire codebase into the prompt and hope the model tracks all of it. Give it exactly what it needs for the task. Smaller context, more reliable output.

Name what you're not changing. If you want the model to touch one function, tell it explicitly what it should not touch. Constraints reduce drift.

Why this matters more for small studios

If you're working at scale, a hallucination is a ticket in the backlog. Someone catches it in review. The system absorbs it.

If you're one person or a small team delivering to a client, the system is you. There's no second layer. The hallucination ships if you don't catch it.

That asymmetry means verification isn't optional overhead. It's the actual job. The AI handles the volume. You handle the judgment. The moment you abdicate that, you're not using a tool anymore. You're hoping.

What I'm building toward

I want a working habit, not a checklist. Something that runs automatically at the end of every AI-assisted session: imports verified, tests run, diff reviewed with fresh eyes after a short break.

It's not about distrusting the model. It's about knowing what the model is good at and what it isn't. It's fast. It's fluent. It has no idea whether that API exists. Only one of us can check that. It's not the model.