Prompts That Actually Work When You Are Writing Code

Updated: 2026-08-15 | Reading time: 5 min

Beginners blame the AI when they get bad code. Nine times out of ten the request was the problem — vague in, vague out.

The four ingredients

A prompt that reliably produces useful code contains four things:

• The goal — what should be true when this works.
• The context — what already exists, which file, which language.
• The constraints — what it must not do.
• The check — how you will both know it worked.

Before and after

❌ "Make a student management system."

This produces something huge, generic, and impossible to review. The student cannot evaluate it, so they accept it, and learn nothing.

✅ "In students.py I have a list of dictionaries with name and marks. Add a function that returns the top three students by marks. Standard library only. If two students tie, keep the one that appears first. Show me how you'd test it with five students."

Specific, reviewable, and small enough that the student can tell whether the answer is right.

Ask for the approach before the code

One of the highest-value habits we teach: "Before writing anything, tell me how you would approach this and what could go wrong."

Two benefits. You catch a bad plan before it becomes forty lines you have to read. And you get an explanation, which turns the assistant into something closer to a tutor than a dispenser.

Build in small pieces

Asking for a whole application at once is the most common beginner error. Experienced users work incrementally: one function, check it, next function. It feels slower and finishes sooner, because you are never debugging six unknown things simultaneously.

Prompts for when you are stuck

• "Explain this error like I have been coding for two months."
• "What are two ways to do this, and when would each be better?" — forces a comparison instead of a verdict.
• "What did you assume that I did not tell you?" — surprisingly effective at surfacing a wrong assumption early.
• "Do not write code yet. Ask me what is unclear."

The prompt to avoid

"Just fix it." When something breaks and a student pastes the error with those words, they get a change they do not understand, applied to code they did not read, solving a problem they never diagnosed. Sometimes it works. Repeat it for three months and you have a student who cannot function without the tool.

Ask instead: "What is causing this, and what are my options?" The extra ten seconds is the entire difference between using the tool and being used by it.