Prompting for Useful Code

An AI assistant only knows what is in your prompt and what it learned in training. It has not seen your project, your database, or the error on your screen unless you show it. Most "the AI gave me garbage" moments come from a prompt that left the model guessing, and a guessing model fills the gaps with whatever is most common, not with what your project needs. This lesson is about closing those gaps.

Give it the context it can't see

Before asking for code, tell the assistant the things a new teammate would need to know on their first day:

• Language and runtime: JavaScript in Node 20, or TypeScript in the browser.
• Framework and libraries: Express, React, a specific database client, and the versions if they matter.
• The code it has to fit into: paste the function signature, the data shape, or the file it will live in.
• Constraints: no new dependencies, must stay synchronous, must match the existing style.

Without this, a request for "a function to save a user" might come back using a different database library, a different framework, and a data shape you don't have. The code may be perfectly reasonable for some project. It just isn't yours.

Ask for small pieces

A prompt like "build me a to-do app with login" gets you hundreds of lines at once, and you can't check hundreds of lines properly. Ask for one function, one route, or one component at a time. Small outputs are easier to read, easier to test, and easier to throw away when they are wrong.

A good rule: if you couldn't review the answer in a few minutes, the request was too big. Break it down, and build the pieces in an order where each one can be run and checked before you ask for the next.

State inputs, outputs and edge cases

The clearest prompts read like a small specification. Say what goes in, what comes out, and what should happen in the awkward cases.

Write a JavaScript function parsePrice(input) for Node 20.
Input: a string like "$1,299.50" or "1299.5".
Output: the price in cents as an integer, e.g. 129950.
Edge cases: return null for an empty string, for text with
no digits, and for negative amounts. Do not use any libraries.
Show three example calls with their expected results.

Naming the edge cases does two jobs. The model is far more likely to handle them, and you now have a checklist to test the answer against.

Ask it to explain and list assumptions

Finish important prompts with "explain how this works and list any assumptions you made." The assumptions are often where the bugs hide: "I assumed the list is already sorted", "I assumed userId is always present". If an assumption is false for your project, you have found the problem before running anything.

An explanation also tells you whether you understand the code. If the explanation doesn't make sense to you, don't paste the code in yet. Ask follow-up questions until it does, or ask for a simpler version.

Iterate with real error messages

When the code fails, "it doesn't work" gives the model nothing to go on, so it tends to rewrite everything and introduce new problems. Give it what you would give a human helper:

Calling parsePrice("$1,299.50") returns NaN instead of 129950.
Error: none. Node 20. Here is the function as I have it now: ...
I think the comma is not being removed before parsing.

Include the exact error text and stack trace, the input that caused it, what you expected, and what actually happened. Paste the current version of the code, because you may have changed it since the model last saw it. And change one thing at a time, so you know which change fixed it.

You are still the author

A well-written prompt makes a good answer more likely. It does not make it guaranteed. The model can still misread you, invent a function, or miss a case. Treat every answer as a first draft from a fast but careless colleague: read it, run it, and check it against the specification you wrote. The next missions in this universe are about exactly that.