DEV Community

Cover image for Why your AI coding agent ships confident, slightly-wrong code (and why rewording the prompt never fixes it)
Anisa
Anisa

Posted on

Why your AI coding agent ships confident, slightly-wrong code (and why rewording the prompt never fixes it)

Your AI coding agent writes something that looks right. It compiles in your head. Then you notice it called user.getProfileById() — a method that doesn't exist anywhere in your codebase.

You didn't ask it to make that up. It invented it confidently, in the middle of otherwise-fine code. And that's the worst kind of wrong: not obviously broken, just quietly incorrect in a way you have to catch.

If you've run Claude Code, Cursor, or any agent on a real repo, you know this one. Here's why it happens — and why the obvious fix doesn't work.

The fix everyone tries first (and why it fails)

You reword the prompt.

You add "Don't make up functions." It behaves… for one file. Then it does it again. So you add "Only use methods that exist in the provided code." Better for a bit. Then two more sentences — and now your prompt is fifteen rules long and it still invents a method the moment the task gets complex.

Here's the part nobody tells you: rewording treats a structural problem as a vocabulary problem.

A prompt isn't a contract the model reads once and obeys. It's something the model has to hold in working memory while it reasons about your actual task. A flat list of fifteen rules is unholdable. As the work gets harder, the model spends its attention on the code and quietly drops whichever rule wasn't front-of-mind. "Don't invent methods" is usually rule #11. Under load, it falls out.

You can't out-word that. A sixteenth rule just gives it one more thing to drop.

The actual cause: shape, not wording

The agent invents a method because nothing in the prompt's structure requires it to check. You told it what not to do. You never changed what it actually does, step by step.

So stop forbidding the bad thing. Remove the opportunity for it.

Instead of a rule it has to remember, make grounding a required step it has to perform.

Before — a pile of rules:You are an expert engineer. Write clean code.
Follow our conventions. Don't make up functions.
Only use methods that exist. Handle errors.
Don't leave TODOs. Write tests. ...

After — an ordered procedure:1. First, list every method or API you plan to call.
For each, quote the file and line where it's defined.

  1. If you can't find where something is defined, stop and tell me — do not write code that uses it.
  2. Only once that list is complete, write the code, using only the methods you grounded in step 1. Same model. No new rule about "don't hallucinate." But now the agent can't invent getProfileById() — the structure makes it find the real method before it's allowed to write the call. And if the method genuinely doesn't exist, step 2 forces it to say so instead of guessing.

Why this holds when rewording didn't

Here's the part that matters.

When you reworded, you were patching one instance — this invented method, in this file. The next one slips through in a slightly different shape.

When you change the structure, you close the whole class: every invented method, in every file, because the model now can't reach the "write the call" step without grounding it first. You didn't fix a symptom. You removed the cause.

That's the real test of a prompt fix: does the same mistake come back wearing different words? If it does, you patched wording. If it doesn't, you fixed structure.

(One aside, because it's the same principle: this is also why cramming prompts into rigid JSON schemas often lowers quality. When you make a model fill fields, it stops reasoning and starts form-filling. Reason in prose and an ordered procedure; save strict JSON for the final hand-off, after the thinking is done.)

A checklist for your next prompt

Forbid less, structure more. Every "don't do X" is a rule the model can drop. Turn it into a step it has to perform.
Make verification a step, not a hope. "Quote where this is defined" beats "use real methods."
Front-load grounding. Read before write — make the model gather the real facts before it generates.
When it can't ground something, it should stop and ask. A question is cheaper than a confident wrong answer.

Do those four and most of the "confidently wrong" problem disappears — without a single extra rule.

If you want this in a reusable form, I packaged the checklist plus a tiny self-updating skill (it keeps these rules current as you add your own) as a free download — [link]. Take it; it's genuinely useful on its own.

And if you've got a prompt that keeps doing this and you'd rather just hand it off — rebuilding flaky prompts into structures that hold is the thing I do. I'm ready to help

Top comments (0)