"Review This Code" Is the Worst ChatGPT Prompt. Here Are 5 Better Ones for the Same Buggy Function.

There is a bug in these six lines. Find it before you scroll.

`def get_discount(price, user): 
     if user.is_premium: 
         discount = 0.2 
     if price > 100: 
         discount = discount + 0.1 
     return price - price * discount `

Most of us would paste this into ChatGPT with three words:

Review this code.

It's the kind of prompt that's incredibly easy to type. You will get an answer. You will also have left the model to guess everything that matters.

What "review this code" leaves out

When a prompt leaves those blank, the model fills them with the most average answer available: a tidy list about naming, docstrings, type hints and "consider adding error handling". The real bug may be in there, as one bullet among eight, with the same weight as a missing docstring.

ChatGPT prompt engineering is mostly the work of filling in those blanks on purpose. Here are five ways to do it, all on the same function. The answer to the bug is further down, so you can test each prompt before you read it.

Prompt 1: Give it a role, a goal and a context

`You are a senior Python engineer reviewing a pull request. 
 This function runs in the checkout path of an online store. 
 A wrong result means a customer is charged the wrong amount. 

Goal: find anything that could produce a wrong price or a crash. 
 Ignore style unless it hides a bug. 

[paste the function] `

What changes: the model stops reviewing "some code" and starts reviewing a checkout function where a wrong number costs money. Style notes drop away because you said they don't matter.

Use it when: always. This is the baseline, and it takes twenty seconds.

Prompt 2: Show it the answer you want (few-shot)

`Review the function below. Report each issue in exactly this format. 

Example: 
 SEVERITY: High 
 INPUT THAT TRIGGERS IT: quantity = 0 
 WHAT HAPPENS: ZeroDivisionError on line 4 
 FIX: return 0 early when quantity is 0 

Now review this function: 
 [paste the function] `

What changes: one example does more than a paragraph of instructions. The reply comes back in the same four fields, and "INPUT THAT TRIGGERS IT" forces a concrete failing case where a vague prompt gets "this might fail in some situations".

Use it when: the output goes into a ticket or a PR comment, or you run the same review across many functions.

Prompt 3: Make it trace the cases step by step

`Before giving any verdict, trace this function by hand for four cases: 

1. premium user, price 150 
 2. premium user, price 50 
 3. non-premium user, price 150 
 4. non-premium user, price 50 

For each case, state the value of every variable after each line. 
 Only then tell me what is wrong. 

[paste the function] `

What changes: you have replaced "have an opinion" with "do the work". The model works through concrete inputs before it judges, so a bug that lives in one branch has nowhere to hide once every branch is walked with real numbers.

Use it when: the logic has branches and the stakes are real: money, dates, permissions.

Prompt 4: Let it interview you first (flipped interaction)

`I want you to review a function. Before you do, ask me up to three 
 questions about anything you need to know to review it properly. 
 Wait for my answers before reviewing. 

[paste the function] `

What changes: expect questions like "what discount should a non-premium user get?" or "are the two discounts meant to stack?". Those questions are the missing spec, and a lot of bugs are spec gaps. This prompt shows you what you forgot to say.

Use it when: you suspect the problem is in the requirements, not the syntax.

Prompt 5: Turn it into a template you reuse

`ROLE: Senior {language} engineer reviewing a pull request. 
 CONTEXT: {where this code runs and what a failure costs} 
 GOAL: Find bugs that cause wrong results or crashes. Ignore style. 
 METHOD: Trace every branch with concrete inputs before judging. 
 FORMAT: For each issue give severity, triggering input, what happens, fix. 
 IF UNSURE: Ask me before assuming. 

{code} `

What changes: this is prompts 1 to 4 folded into one block. Save it as a snippet and you never type "review this code" again.

Use it when: you review code with AI more than once a week.

The bug

If the user is not premium, discount is never assigned.

Non-premium, price 150: line 5 reads discount before it exists.

Non-premium, price 50: the return line does the same.

Both raise UnboundLocalError. Every non-premium customer crashes the function, and premium customers never notice. The fix is one line at the top: discount = 0.0.

Cases 3 and 4 in Prompt 3 walk straight into it.

The honest trade-offs

A good model may catch this bug with the lazy prompt too. The better prompts are about what comes back first, in what order, with a failing input attached, and how consistently.

Output varies between runs. The same prompt can produce two different reviews. For anything important, run it twice.

Longer prompts cost time. For a throwaway question, three words are fine.

You still read the code. A well-formatted review can be confidently wrong.

Where these patterns come from

None of these five are my invention. Role prompts, few-shot examples, chain of thought, flipped interaction and reusable templates are standard prompt patterns, and there are a dozen more that work the same way on emails, summaries, documentation and test cases.

If you want them taught in a structured sequence, the course I'd point you to is LearnKartS' Prompt Engineering for ChatGPT: Beginner to Advanced.

This ChatGPT prompt engineering course covers the techniques behind the five prompts above and the ones I had no room for: prompt structure, few-shot and chain of thought prompting, ask-before-answer, flipped interaction, reusable prompt frameworks and responsible AI use. As an AI prompt engineering course it is beginner level and self-paced, and the free version of ChatGPT is enough to follow along.

Your turn

Two things I'd like to see in the comments:

Run the lazy prompt. Paste the function into the model you use with only "Review this code." Did it lead with the crash, or bury it under style notes? Post the first line you got back, and name the model.

Share your default. What is the one prompt you reuse most, for code or anything else?

And if you think "worst prompt" is unfair, tell me why. I'll defend the title.