Same Mechanic, Different Shop: Why AI Code Quality Is a Tooling Problem

Scroll through any feed with an engineering slant and you'll find the same post in a dozen variations. The model invented a method that doesn't exist. It cited a library nobody has ever published. It wrote three hundred lines that looked plausible and didn't compile. The conclusion is always some version of the same thing: AI writes bad code, and hallucination is why you can't trust it.

I don't doubt any of those stories. I've watched every one of them happen on my own screen. What I've come to doubt is the diagnosis. After a year of running models on my own hardware and using AI to write code in an enterprise language that barely exists on the public internet, I've stopped believing the model is the thing that's broken. Most of the time, it's the shop.

The mechanic on the side of the road

Picture an excellent mechanic — twenty years in, the kind of person that can diagnose a problem from across the lot. Now put them on the side of a highway with a broken car, a pair of pliers, and a screwdriver.

Nothing about the mechanic changed between the shop and the shoulder. The knowledge is all still there. What changed is what they can act on and what they can check. They can't put the car on a lift. They can't read the codes. They can't pull the part they suspect and look at it. They can form a diagnosis, and it'll probably be a good one, but they can't test it — and an expert diagnosis that can't be tested is still a guess. If they get it wrong, nobody sensible says "that mechanic has a hallucination problem." They say "they needed their tools."

That's the situation a model is in when you hand it a task with no way to read the real documentation, no way to compile anything, no way to run a test, and no way to be stopped when it tries to do the best it can with the tools available. You've asked it to guess, and then you've graded it as if you asked it to know.

What a hallucination actually is

Here's the reframe that changed how I work: a hallucination is an answer produced where a lookup should have happened.

From the inside, the model can't tell the difference between "I remember this API" and "I'm pattern-matching to how APIs like this usually look." Both feel the same. Both come out with the same confidence. For a mainstream framework with a million examples in the training data, the pattern-match is usually right, so nobody notices. For anything less common — an internal library, an unusual version, a language with a small public footprint — the pattern-match drifts, and out comes a method that ought to exist but doesn't.

Take the same model and give it something to check against. Let it open the actual source. Let it run the compiler. Now the same internal state that used to become confident fiction becomes "that method isn't there — here's the one that is." Nothing about the weights changed. What changed is that a guess had somewhere to go to become a fact.

The toolbelt

Once you look at it this way, "make the AI reliable" stops being a prompt-engineering question and becomes an inventory question. What can it see, what can it run, what can stop it, and what is it aiming at? Four things cover most of it.

Ground truth it can read. Real docs, real source, real schemas — retrieved at the moment they're needed, not recalled from training. This is the single biggest lever. A model that can look something up doesn't have to remember it, and remembering is where the invention creeps in.

A way to run things. A compiler, a test suite, a linter, a shell. This is the difference between "this should work" and "this works." An agent that can compile its own output and read the error is doing something no amount of careful prompting can substitute for: it's finding out.

A way to be told no. I wrote last time about how an instruction file only ever asks. The other half of that is that the thing which actually keeps a bad action from happening is a mechanism — a check that blocks the commit, a guard that refuses the destructive command, a test that fails loudly. Guardrails aren't there because the model is malicious. They're there because a mechanic without a torque wrench will eventually overtighten something, no matter how good they are.

Something checkable to aim at. A spec, a table, a number that is either right or wrong. Vague requirements produce code nobody can verify, and code nobody can verify gets labeled hallucination when it's really just unanchored. If the target is concrete, the output can be checked against it, and the checking is what makes the whole loop trustworthy.

Where the effort actually goes

None of that is a prompt. That's the uncomfortable part, and I think it's why the "bad AI code" narrative persists: the fix isn't something you can type into a chat box. It's plumbing. Wiring the documentation so it can be searched. Exposing the compiler and the test runner so the agent can call them. Teaching the stack to hand errors back in a form the model can read and act on. Deciding which actions need a hard stop and building the stop.

And then the other half, which is easy to skip: configuring the model to actually reach for those tools. An agent with a compiler available that isn't set up to use it before answering is a mechanic with a full toolbox in the trunk who never opens it. The tools have to exist, and the stack has to be arranged so that using them is the default path, not an optional extra.

It's unglamorous work, and it's most of the work. But it's also where the reliability comes from. The people getting consistently good results from AI coding tools aren't using a secret better model. They built a better shop, and then they put the same mechanic everyone else has inside it.

The question to ask

So the next time the output is bad — and it will be, sometimes — resist the reflex to blame the model. Ask two questions instead. What could it see? What could it run?

More often than not, the honest answer is: pliers and a screwdriver.

❯ tools(model) > model ✓