Prompts that treat the model as a fast, well-read colleague: give it the real error, the real constraints and the real code, and ask for reasoning rather than a magic fix.
5 copy-ready prompts
Debug and review
Language agnostic
The prompts
Prompt 1
Debug with evidence, not guesses
A bug you can reproduce but cannot explain.
I have a bug in [language/framework].
Expected behaviour: [what should happen]
Actual behaviour: [what happens]
Reproduction steps: [exact steps]
Error output:
"""
[paste the full error and stack trace]
"""
Relevant code:
"""
[paste only the code in the path of the bug]
"""
Before suggesting a fix:
1. List the possible causes, ordered by likelihood.
2. For each, tell me exactly what I could check or log to confirm or rule it out.
Then give me the fix for the most likely cause and explain why the bug happened.
Why it works: Asking for causes before fixes stops the model from confidently changing the wrong line - and teaches you the debugging path.
Prompt 2
Review this code like a senior engineer
Before opening a pull request.
Review the code below as a senior [language] engineer would.
Context: [what this code does and where it runs]
Constraints: [performance, browser support, team conventions, deadlines]
Report findings in this order, with severity for each:
1. Correctness bugs, with the input that triggers them.
2. Security issues.
3. Edge cases that are not handled.
4. Readability and naming.
5. Anything that is fine as it is - say so explicitly.
Do not rewrite the whole file. Quote the specific lines.
Code:
"""
[paste your code]
"""
Why it works: Point 5 stops the model inventing problems to look thorough. Without it, everything gets flagged.
Prompt 3
Explain an unfamiliar codebase
Your first week on a new project.
Explain what the code below does, for someone who knows [language] but has never seen this project.
Give me:
- A one-paragraph summary of its purpose.
- The data flow: what comes in, what happens, what goes out.
- Any non-obvious decisions and what problem they were probably solving.
- The parts I would need to understand before changing anything.
- Questions I should ask the original author.
Code:
"""
[paste the file or module]
"""
Why it works: The "questions to ask" section is the most useful output - it points at the context that is not in the code.
Prompt 4
Refactor with a stated goal
Code that works but is hard to change.
Refactor the code below. The specific goal is: [testability / readability / removing duplication / performance].
Rules:
- Behaviour must not change. Note anything that would.
- Work in small steps and show each step separately.
- Do not introduce new dependencies.
- Follow these conventions: [your team's conventions].
After the refactor, list what is now easier and what is now harder.
Code:
"""
[paste your code]
"""
Why it works: Name one goal. "Make it better" produces a rewrite that is different rather than improved.
Prompt 5
Generate tests that could actually fail
Adding coverage to existing code.
Write tests for the function below using [test framework].
Cover:
- The normal case.
- Boundary values (empty, zero, one, maximum, negative where applicable).
- Invalid input and the errors it should raise.
- Any async or ordering behaviour.
For each test, add a comment saying what bug it would catch. Skip tests that only assert the implementation back to itself.
Code:
"""
[paste your function]
"""
Why it works: The "what bug would this catch" comment filters out tests that pass no matter what the code does.
Getting real engineering help out of a language model
Models are genuinely useful for code, and they are also confidently wrong in ways that are expensive to discover later. The difference comes down to how much context you supply and how much reasoning you demand before accepting an answer.
Context is the whole game
A model cannot see your repository, your runtime, your data or your deadline. "Why is my code not working?" with twelve lines pasted in gets you a generic answer about null checks. The same question with the expected behaviour, the actual behaviour, the exact reproduction steps, the full stack trace and the relevant code gets you something closer to what a colleague would say. Every prompt on this page is structured to collect that context before the question is asked.
Paste only the code in the path of the problem. Dumping an entire file buries the signal and increases the chance the model latches onto something irrelevant.
Ask for reasoning before the answer
The single highest-value pattern here is requesting a ranked list of possible causes with a way to test each one, before any fix is proposed. It produces a debugging plan you can follow yourself, it exposes assumptions you can correct immediately, and it prevents the common failure mode where a plausible-looking patch hides the real bug for another two weeks.
Where models are strong
Explaining unfamiliar code in a language or framework you do not use daily.
Boilerplate - configuration, scaffolding, repetitive transformations and glue code.
Test generation from a clear specification, particularly boundary cases you might skip.
Translating between languages when you understand the logic but not the syntax.
Error message archaeology - decoding a message you have never seen before.
Where they are unreliable
Recent library versions. Training data lags, so APIs that changed recently are often described as they used to be.
Invented methods. A function that sounds exactly right frequently does not exist. Check the documentation.
Security-critical code. Authentication, cryptography and access control need a human who knows the threat model.
Architecture decisions. The model cannot weigh your team size, your operational constraints or your migration history.
Anything depending on your data. Performance advice without knowledge of your actual query volumes is guesswork.
Reviewing what you receive
Read generated code the way you would read a pull request from a capable stranger who has not run the tests. Does it handle the empty case? Does it swallow errors? Does it call an API that exists in the version you are on? Does it match the conventions of the file it will live in? Never paste code you do not understand into a codebase you are responsible for - if it breaks at 2 a.m., "the model wrote it" is not a debugging strategy.
This is especially true for junior developers, where the fastest way to stall your growth is to accept working code you could not have written. Use the explanation prompts to close that gap deliberately.
Know your team's rules before you paste
Most organisations now have a written policy on AI-assisted code, and most developers have not read it. The common requirements are straightforward: use the approved tool rather than a personal account, never paste customer data or credentials, and disclose generated code in a pull request where the team asks for it. Some regulated sectors add licence-provenance requirements on top. Checking once costs five minutes; discovering the policy after an incident costs considerably more, and the answer "I did not know we had one" has never helped anybody.
Treat it as a draft from a capable stranger who has not run your tests. Review it for edge cases, check that every API it calls actually exists in your version, and never ship code you do not understand.
Why does the model suggest functions that do not exist?
It predicts plausible code rather than looking anything up. A method that fits the naming pattern of a library will be produced whether or not it was ever implemented, so always check the documentation.
