The short answer
The best AI prompts for coding give an agent the goal and reason, where to look, the constraints and a check such as a test command, and ask for a plan before code on bigger tasks. This page has 13 prompts for understanding code, building features, debugging, testing and review. GitHub Copilot Free includes 2,000 completions a month and agent mode; Cursor has Plan Mode; Claude Code comes with Claude Pro and above.
| Prompts on this page | 13, in four groups |
|---|---|
| Free way to start | GitHub Copilot Free: 2,000 inline completions a month, agent mode and MCP |
| Plan before coding | Cursor Plan Mode: Shift+Tab in the chat input |
| Terminal agent | Claude Code, on Claude Pro and above |
| Rules files | Cursor reads .cursor/rules (.mdc) and AGENTS.md |
How good coding prompts differ from chat prompts
Coding assistants in late 2026 are agents: GitHub Copilot's agent mode, Cursor's Agent and Claude Code can read your repository, edit several files and run terminal commands. That changes what a good prompt looks like. The model can now find context itself, so the most valuable things you add are the things it cannot find: the goal, the constraints, how you will judge the result and what it must not touch.
Every prompt below uses five ingredients:
- Goal and reason. "Add rate limiting to the login endpoint because we are seeing credential-stuffing attacks" leads to better choices than "add rate limiting".
- Where to look. Name the files, folders or functions involved, even if the agent could search for them. It saves time and avoids edits in the wrong place.
- Constraints. Language version, libraries you allow, style rules, and what must not change (public APIs, database schema).
- A check. Tests to run, a command that must pass, or behaviour to demonstrate. Agents that can run tests should be told to run them.
- Plan before code. For anything larger than a small fix, ask for a plan first and approve it. In Cursor, Plan Mode (Shift+Tab in the chat input) does this: the agent researches the code, asks clarifying questions and writes an editable plan before coding.
Prompts for understanding a codebase
The fastest win from AI is reading code you did not write. The Map an unfamiliar repository prompt produces a short tour of the architecture with file paths, so you can check every claim. The Trace a request end to end prompt follows one real user action through the system, which is how most bugs are actually found. The Explain this code to a new teammate prompt is useful for onboarding and for your own future self.
Prompts for planning and building features
Agents write code quickly, so the expensive mistakes are now in the plan. The Plan a feature before writing code prompt asks for a numbered plan with files to change, risks and tests, and tells the agent to wait. The Implement one step of the plan prompt keeps changes small enough to review. The Write project rules for the agent prompt turns your team's conventions into a file the agent reads every time: Cursor reads Project Rules as .mdc files in .cursor/rules and also supports AGENTS.md.
Prompts for debugging and testing
Good debugging prompts include the evidence: the exact error, the stack trace, what you expected and what you already tried. The Debug from an error and a stack trace prompt asks for hypotheses ranked by likelihood with a way to confirm each, which stops the agent from "fixing" the wrong thing. The Write tests that would have caught this bug prompt locks in the fix, and the Add tests to untested code prompt asks for behaviour-level tests rather than tests that mirror the implementation.
Prompts for review, refactoring and documentation
Ask the model to review as a specific reviewer with specific concerns and it finds real problems; ask it "is this good?" and it says yes. The Review a diff like a senior engineer prompt ranks issues by severity. The Refactor without changing behaviour prompt requires tests to pass before and after. The Look for security problems prompt names the classes of bug to check. Treat every finding as a lead to verify, and never merge AI-written code you do not understand.
How to adapt these prompts
- Put the stable parts in a rules file. Language versions, test commands, folder conventions and forbidden patterns belong in project rules or AGENTS.md, so each prompt can stay short.
- Size the task to what you can review. If the diff will be longer than you would read carefully, split the task.
- Give the real error, not a summary. Paste the full message and stack trace, plus the command you ran.
- Start fresh when it goes in circles. If the agent has tried the same fix twice, open a new chat with a summary of what failed. Long, confused threads make answers worse.
- Keep secrets out. Never paste API keys, passwords or customer data into a prompt. Use environment variables and sample data.
Which AI coding tool works best
GitHub Copilot is the easiest start: Copilot Free includes 2,000 inline completions a month plus agent mode and MCP in the editor, using Auto model selection, and paid plans add model choice including Claude Opus 5.5, GPT-6 Sol and Gemini 4 Argon depending on plan and admin policy. Cursor suits developers who want an agent-first editor with Plan Mode and rules; its paid plans start with Plus, which runs only Grok models, while Cloud Agents and third-party models such as Claude and GPT need Premium or above. Claude includes Claude Code from the Pro plan upwards for work in the terminal. For a fuller comparison see Cursor vs GitHub Copilot, Claude vs Cursor, best AI for coding and AI for software engineers.
Check your privacy settings before you point an agent at company code. On GitHub Copilot Free, Pro, Pro+ and Max, interaction data can be used for training unless you turn off "Allow GitHub to use my data for AI model training" under your profile picture, then Copilot settings; Business and Enterprise data is not used for training. In Cursor, turn on Privacy Mode in settings; it is on by default for Enterprise.
Prompts to copy
Map an unfamiliar repository
Give me a tour of this repository for a developer joining the team. Cover: what the application does, the main folders and what lives in each, how a request flows from entry point to database, how configuration and secrets are loaded, and how to run the tests. Cite the file path for every claim, keep it under 400 words, and list anything you could not work out.
You get: A checkable architecture tour with file paths
Trace a request end to end
Trace what happens when a user [action, such as submits the checkout form]. Start from [route, component or endpoint] and list each function, file and external call in order, including validation, database queries and error handling. Point out any place where an error could be swallowed silently.
You get: The real path of one user action through the code
Explain this code to a new teammate
Explain [file or function] to a developer who knows [language] but not this codebase. Describe what it does, why it is probably written this way, the inputs and outputs, side effects, and the two things most likely to break if someone changes it. Do not rewrite it.
You get: A plain explanation with the fragile parts flagged
Plan a feature before writing code
I want to add [feature] so that [user goal]. Constraints: [framework and version, libraries allowed, must not change public API or schema]. Before writing any code, give me a numbered plan: files to create or change, the approach for each, data or migration changes, risks, and the tests you will add. Ask me up to three questions if anything is unclear, then wait for my approval.
You get: An approved plan before any code is written
Implement one step of the plan
Implement step [number] of the plan we agreed, and nothing else. Follow the existing patterns in [similar file]. When you are done, run [test command], show me the result, and summarise the diff in five bullets including anything you were unsure about.
You get: A small, reviewable change with tests run
Write project rules for the agent
Draft a rules file for AI coding agents working in this repository. Look at the code and include: language and framework versions, how to run tests, lint and build, folder conventions, naming and error-handling patterns, libraries we use and ones to avoid, and things the agent must never do (such as edit migrations or commit secrets). Keep it under 60 lines, as Markdown bullet points.
You get: A rules file so every prompt starts with your conventions
Debug from an error and a stack trace
This command [command] fails with the error below. Expected behaviour: [expected]. What I already tried: [attempts]. Error and stack trace: [paste in full]. Give me the three most likely causes ranked by likelihood, how to confirm each one with a quick check, and only then propose a fix for the confirmed cause.
You get: Ranked hypotheses and a confirmed fix
Write tests that would have caught this bug
We just fixed this bug: [describe bug and fix, or paste the diff]. Write tests in [test framework] that fail on the old code and pass on the new code. Cover the exact case and two nearby edge cases. Follow the style of [existing test file] and run the tests.
You get: Regression tests that lock in the fix
Add tests to untested code
Write tests for [module or function] using [test framework]. Test behaviour through the public interface, not private details. Include the normal path, empty and invalid input, boundary values and one failure from a dependency, mocked. List any behaviour that looks like a bug rather than writing a test that accepts it.
You get: Behaviour-level tests and suspected bugs
Review a diff like a senior engineer
Review this change as a senior [language] engineer: [paste diff or name the branch]. Look for correctness bugs, missing error handling, performance problems, unclear names and missing tests. Rank findings as must fix, should fix or nit, quote the exact line for each, and suggest the change. Do not comment on formatting that a linter would catch.
You get: A prioritised code review with line references
Refactor without changing behaviour
Refactor [file or function] to [goal, such as remove duplication or split into smaller functions]. Behaviour must not change. First run [test command] and confirm the tests pass; if coverage of this code is thin, add tests before refactoring. Make the change in small steps, run the tests after each, and summarise what changed.
You get: A safer refactor protected by tests
Look for security problems
Review [files or feature] for security problems: injection (SQL, command, template), broken access control, unsafe deserialisation, secrets in code or logs, missing input validation and insecure defaults. For each issue give the file and line, how it could be exploited in one sentence, severity, and a fix. Say clearly if you found nothing in a category.
You get: Security leads to verify, by category
Write documentation people use
Write a README section for [module or service] covering: what it does in two sentences, how to set it up locally, configuration options in a table, one realistic usage example, and common errors with fixes. Base it only on the code and existing docs, and mark anything you inferred.
You get: Practical docs grounded in the code