How to Write a Prompt That Produces Working Code

August 27, 2026

A prompt that produces working code names the goal, the inputs, the outputs, the edge cases and the format you want back. When you leave those out, the assistant fills the gaps with guesses, and you spend your time correcting guesses. A few extra sentences at the start usually save several rounds of repair.

Here is a method you can reuse for nearly any small tool.

Start with the result, not the method

Describe what the finished thing does from a user’s point of view. Compare these two:

• “Write JavaScript with a function that takes numbers and returns a result.”
• “Build a page where I type a bill amount and choose a tip percentage, and it shows the tip and the total.”

The second gives the assistant a purpose it can reason about. You do not need technical words. Plain description of behavior is what the assistant is best at turning into code.

Spell out inputs and outputs

List what goes in and what comes out, including formats. Be concrete about:

• Inputs: fields, buttons, files, and what each accepts.
• Outputs: what appears on screen, in what format, and with how many decimals.
• Units and limits: currency, minimum and maximum values, date format.

For example: “Input is a bill amount in dollars with up to two decimals. Output is the tip, the total and the per-person amount, each with a dollar sign and two decimals.” A sentence like this removes a dozen small decisions.

Name the edge cases

Edge cases are the unusual inputs where tools break. Most first drafts handle the normal case and fail on the rest. Tell the assistant what should happen when:

1. A field is empty.
2. A number is negative or zero.
3. The input is far larger than expected.
4. The user types letters where numbers belong.
5. The list is empty, or has only one item.

You do not need to cover all of these every time. Think about the two or three most likely for your tool and state the behavior you want, such as “show nothing” or “show a gentle message.”

Say what format you want back

The shape of the answer matters as much as the content. Specify:

• One file or several. For beginners, “one HTML file with the CSS and JavaScript inside” is easiest to run.
• No extras. “Do not use any build tools or install steps.”
• Explanations. “After the code, explain in three sentences how to save and open it.”
• Comments. “Add short comments describing each section.”

Without this, the assistant may produce a project requiring commands you do not know, or it may skip instructions for running it.

Give style constraints briefly

Describe the look in a sentence or two: “Simple, one centered card, large text, works on a phone.” If you have no preference, say “keep the design minimal.” This prevents decorative additions that make the file longer and harder to check.

If you want to avoid dependencies, say so: “Use only plain HTML, CSS and JavaScript.” If a library is acceptable, say that too, and ask which one it chose and why.

Include a way to test

Give a few input and output pairs, and the assistant can check its own logic against them. For example: “A bill of 100 with a 20 percent tip should show 20 and 120.” You will also use these same pairs when you test the page yourself.

You can go further and ask: “List five test cases I should try, with the expected result for each.” Then run them. The list often includes edge cases you had not considered.

Put it together

Here is a short template you can adapt:

Goal: [what the tool does, in one sentence]
Inputs: [fields, formats, limits]
Outputs: [what is shown, formats]
Edge cases: [what should happen when input is empty, negative, huge, or invalid]
Format: one HTML file with CSS and JavaScript inside; no installs
Style: [one or two sentences]
Tests: [two or three input/output examples]
After the code: explain how to save and run it in three sentences.

Fill it in with a few lines each. The whole prompt may run to eight or ten lines, which is fine. Long and specific beats short and vague.

Ask the assistant to ask you

If you are unsure what to include, flip the process. Write your goal in two sentences and add: “Before writing any code, ask me up to five questions that would help you get this right.” The questions usually cover things you had not thought about, such as whether the page needs to work offline or what should happen with invalid input.

Answer briefly and then say “Now build it.” This costs one extra message and often removes the need for several repair rounds. It also teaches you which details matter, so your next prompt starts out stronger. Save the questions that were useful; they can become part of your own template.

What not to do

Do not ask for everything at once. A prompt that requests ten features produces a large file that is hard to check. Build the core first, test it, and add features separately.

Do not assume the assistant remembers your intent from earlier in a long conversation. If you start getting odd results, restate the key requirements briefly.

Do not paste secrets such as passwords or private keys into a prompt.

Improve by adjusting one thing

If the first result is poor, change one part of the prompt and try again, rather than rewriting everything. If the layout was wrong, refine the style line. If an edge case failed, add it to the list. Treat the prompt like a recipe you refine, and keep the versions that worked well.

Your next step

Take a tool idea you have now and write the template above for it. Spend ten minutes on the edge cases and the test pairs, then send it to an assistant. Compare the result with what you wrote down, fix gaps by editing the template, and save the final version in a notes file. That file becomes your own library of prompts that work.