Prompts that produce working software

Most bad AI output is a reasonable answer to a badly asked question. The fix is not a longer prompt or a magic phrase. It is treating a prompt as a small specification.

A specification says what the thing must do, what it must not touch, and how anyone can tell whether it worked. Those three facts are what turns a plausible answer into working software.

The five parts of a working prompt

1. Goal. One outcome, in the user's words. "A visitor can filter the list by topic."

2. Context. Where it lives and what already exists. "The list is on the explore page and already loads from the database."

3. Constraints. What must stay true. "Keep the filter in the URL so it can be shared. Do not change how the cards look."

4. Shape of the output. What you expect back: a plan, one file, a change to an existing screen, an API response with named fields.

5. Definition of done. An observable test. "I pick a topic, the list narrows, I copy the URL into a new tab and see the same filtered list."

Miss part 3 and something working gets rewritten. Miss part 5 and you get a confident summary instead of a result.

Show data, not adjectives

"Make it modern and clean" has no failure condition, so it cannot be satisfied or checked. Replace adjectives with facts:

• Instead of "make the card nicer": "one line title, two line description, the rating on the right, and the whole card is one link".
• Instead of "handle errors properly": "if the request fails, keep the typed values, show the error text above the button, and do not clear the form".
• Instead of "fast": "the list should render from cached data on repeat visits, and never refetch on window focus".

When you can describe the fields, describe the fields. Structured detail is the highest leverage thing you can add to a prompt.

One change per pass

A prompt with six features produces six half features and one hard debugging session. Sequence them instead, and verify between each. The order that works:

1. Data shape first. What is stored, what is required, what can be empty. 2. Then the server behavior. Reading, writing, permissions. 3. Then the screen. 4. Then the edge cases: empty, too long, wrong, unauthorized. 5. Then polish.

Building the screen first feels faster for about twenty minutes.

Say what not to touch

This single line prevents most regressions:

Do not change the submission flow, the database schema, or the header. If a change to any of those is required, tell me first and explain why.

You are not just protecting code, you are forcing a conversation before an expensive decision.

Give the whole error, every time

When something breaks, paste the entire message: the text, the file, the line, the stack, and what you clicked right before it. Then add one sentence of expectation: "I expected the review to save. Instead the page went blank."

Half an error message produces a guess. A full error message produces a fix. Also say what already failed, so the same wrong idea is not tried twice:

Adding a null check did not help. The value is present in the request but missing in the response.

Ask for a plan before anything large

For anything that touches several screens, permissions, or stored data, ask for the plan first:

Before writing code, list the files you will change, the data you will add, and the risks. Wait for my go ahead.

Reading a plan costs a minute. Unwinding the wrong architecture costs an afternoon.

Templates you can reuse

New feature:

Goal: <one outcome, in a visitor's words>
Where: <page or flow that already exists>
Rules: <what must stay true, what must not change>
Done when: <observable test I can run myself>

Bug report:

What I did: <exact steps>
What I expected: <...>
What happened: <full error text and where it appeared>
Already tried: <...>
Do not change: <the parts that work>

Refactor:

Behavior must not change. Prove it by keeping <the test or flow> passing.
Goal: <one shared place for this logic>
Replace every duplicate use, and list what you replaced.

Anti-patterns

• "Fix everything." No target, no test, unbounded blast radius.
• "You broke it, try again." Says nothing new. Say what specifically is wrong now.
• Stacking corrections on a bad base. After two failed corrections, restate the goal from scratch rather than patching the patch.
• Trusting a summary. "All tests pass" is a claim. Run it.
• Asking for a design and a feature at once. You will get an opinionated redesign and a broken feature.

Before and after

Before:

The reviews section is broken and looks bad, please fix it and make it work like a real site.

After:

On the site detail page, the reviews list shows nothing even though there are two reviews in the database. Loading the same rows from the dashboard works. Full console error: "Cannot read properties of undefined (reading 'map')". I expected two reviews with the author name and rating. Find why the list is undefined on this page only, fix that cause, and do not restyle the section. Done when both reviews appear after a refresh, and an empty state shows when there are none.

Same problem. The second one is answerable.

The habit underneath all of it

Write the finish line before the request, and check the finish line yourself. Everything else in this article is a shortcut to that.