Bad AI Coding Prompts and How to Fix Them

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

Yes. Treat the frame below as a starting point. 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.

Fill the Context line with things the agent can open: file paths, the exact error text and the doc or example to follow. Paste errors instead of paraphrasing them, because a paraphrase drops the detail the agent needs to trace the cause.

The Boundary line is easy to leave out, and in our view it does the most work. Without it, every file the agent can reach is fair game. You end up reviewing incidental edits to config, imports and helpers you had forgotten about, mixed in with the change you wanted. Naming what not to touch takes a few seconds, and reverting stray edits afterwards takes far longer.

"Done when" has to name something you can run or look at: a test name, a typecheck, a command whose output you can read, or a screenshot of one specific state. "Done when the bug is fixed" doesn't count. It hands the judgment back to the agent, and the agent will report that the work is finished either way.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

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.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows 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.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

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 modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. can read "why is this happening" as a request to fix the underlying issue, and then it edits. Rewording does not change that. If Agent mode has already changed code you only wanted explained, restore the checkpoint from before your question and ask it again in Ask mode.

Cursor has four modes, and each reads the same sentence differently. Ask explains, Plan researches and writes a spec before any code, and Agent executes. Debug forms hypotheses, adds instrumentation that streams logs to a local debug server, and asks you to reproduce the issue. Then it reads the runtime evidence and strips the instrumentation once the fix is verified.

Switching modes takes a second with the mode picker or ⇧+⇥, so try that before another rewrite. Each mode keeps its own context, so the switch also starts a fresh context window.

Check where you will run Debug modeA mode that diagnoses a failure: it reproduces the issue, adds instrumentation and watches the logs, rather than reviewing a pull request. Press Enter for the full definition. before you rely on it. In JetBrains IDEs, Cursor's agent runs through ACPAgent Client Protocol. An open standard that lets any IDE host any coding agent; Cursor uses it to run inside JetBrains/IntelliJ and Android Studio. Press Enter for the full definition., and the ACP docs list Agent, Plan and Ask modes but not Debug. If you need Debug mode there, run that task in the Cursor CLICursor's command line: the full agent, all modes and models, in the terminal and pipeable into scripts and CI. Press Enter for the full definition., which has a /debug command.

Anything you have typed more than twice. Rules are reusable context that Cursor loads for you, stored as .mdc files under .cursor/rules/. A convention like "use our logger, not console.log" belongs there, not at the top of every prompt. If your rules still live in a single .cursorrules file at the repo root, Cursor calls that file legacy and says it will be deprecated.

Moving conventions into rules is the right advice, but it skips the part that causes trouble. A rule has four apply modes, and Always is the expensive one. It is included in every conversation, where it 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 moves the noise out of your prompt and into every conversation.

Pick the narrowest mode that still fires. A file-glob rule applies to matching paths, an apply-intelligently rule is pulled in when its description matches, and a manual rule waits for an @-mention.

When a rule seems to do nothing, check the mechanics before you reword it. Cursor's docs point to the rule type first: an Apply Intelligently rule needs a description, and a file-scoped rule needs a glob that matches the files in context. A plain .md file in .cursor/rules is ignored, because it has no frontmatter. A rule long enough to dilute itself can look ignored too.

The thread is fuller than it was. Each new message goes to the model with the conversation so far, and when the window gets close to full, Cursor compresses older turns into a summary. As the thread grows, each turn carries more history than the last, so your third prompt is read against a more crowded context than your first.

At that point, the cheapest fix is a new thread that starts with the better prompt.

If you stay in the thread, compact it early. Cursor field engineers suggest running /summarize at roughly 50 to 60% of the context window, before performance starts to degrade. Switching models mid-session also breaks the cache, so an unplanned model swap during a rescue attempt costs you the cached context on top of the time.