The quality of the answer depends almost entirely on the question. “My code does not work” gets you a guess. A good prompt gets you something you can use immediately.
The five ingredients#
- Context — language, version, and what you are building
- The actual code — the relevant part, not a description of it
- What you expected — specifically
- What happened instead — the exact error, copied as text
- What you already tried — so it does not repeat your dead ends
Miss any of these and the answer becomes a guess dressed up as an answer.
Before and after#
Too vague#
“My Python code is not working, can you fix it?”
The assistant has no code, no error, and no idea what “working” would mean.
Much better#
I am writing a Python 3.12 script that reads a CSV of orders and totals the amounts.
Here is the function:
[the ten relevant lines]
I expected it to print a single number. Instead I get:
TypeError: unsupported operand type(s) for +=: 'int' and 'str'on line 8.I have checked that the file loads and printed the first row, which looks correct. I think the amount column is being read as text but I am not sure how to confirm it.
That prompt gets an accurate answer and an explanation, because there is enough to reason about.
A template#
Language / version:
What I am building:
What I want to happen:
What happens instead (exact error):
My code:
What I have already tried:
Please explain the cause before giving me a fix.That last line matters more than it looks. Without it you often get code and no understanding.
Prompts that produce better learning#
- “Explain this like I have been coding for two weeks.”
- “Do not give me the code. Give me a hint about which line to look at.”
- “What are three different ways to solve this, with the trade-offs?”
- “Review my code and point out what a senior developer would change, and why.”
- “What edge cases does this miss?”
- “Rewrite this to be more readable, and explain each change.”
Give it the real error, not your summary#
“It says something about a type error” is much less useful than the full message and traceback. The exact wording contains the variable name, the line number and the types involved. Copy it as text, not a screenshot description.
See how to read a stack trace for what to include.
When the answer is wrong#
It happens often. Do not just say “that did not work” — say what happened:
“That produced a different error:
AttributeError: 'list' object has no attribute 'get'on line 12. It looks likerowsis a list of lists rather than a list of dictionaries. Does that change your suggestion?”
You have now given it new information, and you worked out something real yourself in the process.
Questions people ask#
Should I ask for the whole program or one piece?
One piece. Large generated programs are hard to verify and harder to debug, and you learn far less from them.
Does it help to say “you are an expert developer”?
Far less than being specific about your problem. Detail beats flattery.
How do I stop it giving me overly complex code?
Ask for it directly: “Use only basic Python — no external libraries, no comprehensions, no classes. I have been learning for three weeks.” Assistants follow constraints well when you state them.