Prompts That Return Code and Nothing Else

A generated function that runs can still be wrong for your codebase: written against a library major version you do not have, importing something that does not exist in your runtime, or silently assuming an input shape you never described. None of that is visible in the snippet, and all of it is decided by what the prompt failed to pin.

What has to be pinned before you ask for code?

Is "code only, no explanation" a good instruction?

Half of one. It gets you a pasteable answer, which is the point — but the explanation is also where the model states what it assumed, and suppressing the explanation does not remove the assumptions. It just stops you finding out about them.

The version that keeps both: ask for the code, plus a short comment block at the top listing anything the code assumes that the prompt did not state. It stays inside the file, so it is still pasteable, and you get the one part of the prose that was load-bearing.

Return only the file contents — no prose before or after.
Begin with a comment block listing any assumption the prompt did not state
(input shape, library version, error behaviour). If there are none, write
"// No assumptions beyond the prompt."

Where does the file start and end?

Say it, or you get a fragment. "Write a function that validates the payload" yields a function with no imports, and whether that is right depends entirely on whether you are pasting into an existing file or creating a new one — a distinction the model cannot see.

• Pasting into an existing file: "just the function body, no imports, no exports — it goes into an existing module."
• Creating a new file: "a complete file including imports and exports, runnable as written."
• Adding to something you will show it: paste the existing file and ask for the modified version, so the boundary is visible rather than described.

Should I ask for a whole file or a diff?

A diff when the file is large and the change is small. Regenerating 300 lines to change 4 means re-reading 300 lines to find them, and it invites collateral edits — reformatted lines, a renamed variable, a comment "improved" — that are invisible in a wall of new code and obvious in a patch.

A whole file when the change is structural, or when the file is short enough to read at a glance. The failure mode of diffs is context lines that do not match your actual file, which produces a patch that will not apply — so ask for a diff only when you gave the model the real file to diff against.

What about stubs, TODOs and partial implementations?

Decide which you want and say so. A model that hits something it cannot resolve will otherwise leave a TODO or an ellipsis, and a stub that looks like an implementation is worse than an obvious gap — it passes a skim and fails at runtime.

Two workable instructions, opposite in spirit: "implement everything; if a detail is unspecified, choose a reasonable default and note it in the assumption block", or "leave anything you cannot determine as an explicit throw new Error('not implemented') rather than a plausible guess". The second is the right default for anything that touches money or auth.

What can code output not tell you about itself?

Whether it is correct. Generated code carries no evidence about its own behaviour, and reading it is not the same as running it — the failure that matters is usually the branch you did not think to read. Test it, or ask for the test alongside it and read the test first: a test that asserts the wrong thing is much easier to spot than an implementation that does the wrong thing.

In VantagePrompt, the code shape is resolved by "write code", a function name, or a language name in your input, and the optimized prompt then carries a fenced code block with a function or class signature skeleton. That skeleton is built from what you named — so a prompt that names the language, the version and the signature gets a contract, and one that says "some code for parsing this" gets the model's guess at all three.