Prompts for Developers: From Bug to Code Review

You paste in a stack trace, type "fix," and the assistant hands back a rewritten function that silences the error. The test passes, sometimes because the try/except it added swallows the exception. The symptom is gone, not the bug.

A developer doesn't need anyone to explain what a prompt is. What they need most are reflexes to keep the AI from rushing toward the first plausible solution. The templates below force that slowdown, and they work in a chat as well as in a coding assistant.

Debugging: separate the diagnosis from the fix

The most profitable instruction fits in one line: no code before the diagnosis. It keeps you from signing off on a fix built on an assumed cause.

Bug in [LANGUAGE/FRAMEWORK, VERSION IF IT MATTERS].

Expected behavior: [WHAT SHOULD HAPPEN]
Observed behavior: [WHAT HAPPENS]
Reproduction: [STEPS OR TEST]
Full error:
[STACK TRACE]

Relevant code:
[EXCERPTS]

What I've already tried or ruled out: [LIST]

Don't suggest a fix yet.
1. List 3 hypotheses ranked by likelihood.
2. For each one, give the observation from the code or trace that supports it.
3. Give the quickest check to confirm or rule it out (specific log, query, minimal test).

I'll run those checks and give you the results. If you're missing a file to reason about this, ask for it instead of assuming its contents.

Take a Rails developer facing an invoice created twice: here, the hypotheses would likely include a form submitted twice, a replayed webhook, or a restarted job, and each can be checked in a few minutes in the logs. This two-step split applies the principle of step-by-step reasoning, plus a human supplying the facts in between.

Review a diff, not a whole file

A review requested without direction mostly returns style remarks. Give the diff, say what the change is supposed to do, and specify what you care about.

git diff main...HEAD > diff.txt

You're reviewing this pull request.

Goal of the change: [TICKET OR DESCRIPTION]
Context: [STACK, CONVENTIONS, PERFORMANCE CONSTRAINTS]
Diff:
[PASTE THE DIFF]

Look in this order:
1. Bugs: edge cases, unhandled errors, concurrency, null values.
2. Security: injection, access control, sensitive data in logs.
3. Gaps against the goal: what's missing and what goes beyond the scope.

For each problem, give the file and the line in the diff, the concrete scenario that triggers it, and the severity (blocking, should fix, minor). Ignore formatting and naming, a linter handles that. If the diff looks correct on one axis, just say so rather than inventing a problem.

The last sentence matters. Without it, a model asked for problems tends to find them at all costs, even in healthy code.

Secure legacy code before touching it

You have to modify a 300-line function with no tests, written by someone who has left. Asking to "refactor" amounts to losing the undocumented behaviors. The right sequence starts with characterization tests, which pin down what the code does today, bugs included.

Here's a function with no tests, in production:
[CODE]

Test framework: [PYTEST, JEST, PHPUNIT...]

Before any refactoring:
1. Describe the actual behavior of this code, case by case, including behaviors that look like bugs to you.
2. Write characterization tests that document this current behavior, without fixing it. Mark the cases that look like bugs with a comment.
3. List the dependencies to mock (database, clock, API) and the areas you can't cover without changing the code.

Don't modify the function. The refactoring will come in a second phase, in small steps, with green tests between each.

Run these tests against the current code before going further. If they fail on the current code, the model got the behavior wrong, and those gaps are precisely what you wanted to uncover. Then break the refactoring up into a prompt chain: one extraction per message, one commit per step.

Write tests that attack the code

When asked for tests after being shown an implementation, the AI often writes tests that describe that implementation. They pass and don't prove much. Steer it toward the specification and toward breaking points.

Function specification: [BUSINESS RULES]
Signature: [SIGNATURE]
Real example of input and output: [EXAMPLE]

Write the tests from the specification, without trying to mirror an implementation.
Cover boundaries, invalid inputs, duplicates, time zones, and rounding where applicable.
For each test, say in one line which realistic bug it would catch.
Drop tests that could only fail if the language itself were broken.

For a restaurant booking app, this prompt has a good chance of surfacing the time slot that straddles the daylight saving time change, the kind of case that's often forgotten.

SQL migration: have it look for what could go wrong

A migration works locally and locks the table in production. The AI is a good pessimistic reviewer as long as it knows the volume and the engine.

Engine and version: [POSTGRESQL, MYSQL...]
Size of the tables involved: [ROWS]
Traffic: [READS/WRITES, MAINTENANCE WINDOW]
Migration:
[SQL]
Application code that reads these columns: [EXCERPTS]

Analyze:
1. The locks taken by each statement and their likely effect at this volume.
2. Compatibility during deployment, when old and new code run together.
3. The rollback plan, and what can't be undone.
4. A multi-step version if needed.

If a behavior depends on the engine version, say so and tell me what I should check in the documentation.

Three precautions before trusting generated code

Check that what's cited exists. A model can invent a method, an option, or a package. The risk is real on the security side: an invented package name can be registered by a malicious third party. Before installing, look at the registry, the author, and the project's activity:

npm view [package]
pip index versions [package]

Don't paste what you can't share. API keys, connection strings, client data, and code under a nondisclosure agreement have no place in a tool your company hasn't approved. Look at the terms of your plan, since they vary from one product to another, and run a secrets scanner on what you send.

Keep responsibility for the review. Generated code gets reviewed like a colleague's, with the added question of licenses if it's a commercial product. If you work with an agent that runs commands itself, its instructions deserve as much care as your code: it's all in our guide to instructions for agents.

Open your last resolved bug ticket, give it back to your assistant with the first prompt, and compare its hypotheses with the real cause. You'll quickly learn what your tool is worth on your codebase.