Bad AI Coding Prompts and How to Fix Them

The working pattern for bad AI coding prompts is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Yes. The frame below is a starting point, not a script. Fill in your own files, constraints and done state, and keep the plan step so the agent commits to an approach before it writes code.

Task: [one outcome]
Context: [files, errors, docs and examples]
Boundary: [what not to touch]
Done when: [test, typecheck, screenshot or review proof]

Before editing, write a short plan with files, risk and checks.

The Boundary line is the one people leave out, and probably the one doing the most work. Without it every file the agent can reach is fair game, so you end up reviewing incidental edits to config and imports and some helper you'd forgotten existed, all mixed in with the change you actually wanted. Naming what not to touch takes a few seconds. Reverting it afterwards does not.

"Done when" has to name something you can run. A test name, a typecheck, a command whose output you can read, a screenshot of one specific state. "Done when the bug is fixed" doesn't count, and I'd say that's the single most common version of this mistake, because it quietly hands the judgment back to the agent, and the agent is going to tell you it's finished either way.

Running bad AI coding prompts as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

Check the mode before you rewrite anything. Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition. is read-only and will not touch a file; agent mode reads "why is this happening" as a request to fix the underlying issue, so it edits. Rewording does not change that, and if agent mode has already changed code you only wanted explained, undo-all and re-ask the same question in ask mode.

There are four modes and the same sentence means something different in each. Ask explains. Plan researches and writes a spec before any code. Agent executes. Debug is the odd one. It forms hypotheses, adds instrumentation that streams logs to a local debug server, asks you to reproduce the issue, reads the runtime evidence, then strips the instrumentation once the fix is verified.

A mode change, then. It costs a second through the mode picker or ⇧+⇥, and it is a smaller bet than another rewrite.

Before you lean on debug mode, though, check where you'll be running it. Cursor's JetBrains integration offers ask, plan and agent, and debug hasn't landed there yet. If the mode you rely on is missing inside the IDE, drop to the terminal for that run.

Anything you have typed more than twice. Rules are reusable context Cursor loads for you, .mdc files under .cursor/rules/, and that is where a convention like "use our logger, not console.log" belongs rather than at the top of every prompt. If yours still live in a single .cursorrules file at the repo root, that location is deprecated.

So the advice is to move conventions out of prompts and into rules. Which is right, and it skips the part that actually bites. A rule has four apply modes, and Always is the expensive one, because it loads on every prompt and competes with your task for the model's attention. Cursor's own open-source rules run about eight lines each. A page-long rule set to Always has not removed the noise from your prompt, it has made the noise permanent.

Pick the narrowest mode that still fires, which is probably narrower than feels comfortable. File-glob scopes a rule to matching paths, apply-intelligently lets the agent pull it in when the description matches, and manual waits for an @-mention.

And when a rule turns out to do nothing at all, the wording is rarely the reason. The causes are mechanical: wrong or missing globs, a rule long enough to dilute itself, malformed frontmatter, or that deprecated file location again.

Because the thread is fuller than it was. Cursor summarizes everything discussed so far on every turn and packages that with your new message, and as a thread grows each turn carries more history than the one before it. The third prompt is being read against a more crowded context than the first one was.

The cheapest fix at that point is honestly a new thread carrying the better prompt.

Cursor's CLI guidance is to compact at roughly 50 to 60% of the context window, before performance starts to degrade rather than after. Switching models mid-session breaks the cache as well, so an unplanned swap partway through a rescue attempt costs you the cached context on top of the time.