Review this [LANGUAGE] code for bugs, security issues and performance problems. Give a fixed version with comments: [CODE]
Explain this code to a junior developer, line by line, then give a one-paragraph summary: [CODE]
Write unit tests for this function covering happy path, edge cases and error handling: [CODE]
Refactor this code to be more readable and follow [LANGUAGE] conventions. Explain each change: [CODE]
Generate a REST API design for [RESOURCE] with endpoints, request/response JSON, status codes and error format.
Write a regex that matches [PATTERN] and explain each part of it with 3 test cases.
Turn this SQL query into an optimized version and explain the index strategy: [QUERY]
Create a debugging checklist for [ERROR] ordered from most to least likely cause.
Write a README for this project: what it does, install, usage, config, and troubleshooting: [PROJECT]
Convert this code from [LANG_A] to [LANG_B] and note any behavioral differences: [CODE]
Context is the whole game
Paste the language and framework version, the constraint that matters (latency, memory, readability) and what you have already tried. A model without that context will confidently suggest the thing you ruled out in your first attempt.
For a bug, include the full stack trace and the smallest reproduction you can build. Half of debugging with AI is the discipline of producing a minimal reproduction - which often reveals the bug before the model answers.
Never accept code you cannot explain
Ask for the reasoning before the patch, then read it. If the explanation contains a step you cannot follow, that is the part that will break in production.
Ask explicitly for the failure modes: 'what input would break this?' A model that lists its own edge cases is far more useful than one that only produces the happy path.
Frequently asked questions
Can AI review code reliably?
It is good at spotting missing null checks, unhandled promises, obvious injection risks and duplicated logic. It is unreliable about whether a change fits your architecture, because it cannot see the rest of the codebase unless you paste it.
Should I let it write tests?
Yes, with one rule: ask for the failure mode each test protects against. Tests generated without that framing tend to assert what the code currently does rather than what it should do, which locks in bugs.
How do I stop it inventing APIs?
Paste the actual signature or the relevant documentation excerpt. Hallucinated methods come from missing context, and a five-line interface definition removes most of them.