Edited by us
Coding prompt — why 'just make it work' code always gets rewritten
Writing done-conditions, edge cases, and must-not-break lists into a coding request.
By Mephify (operator)3 min read
What makes this hard
A typical request
Write a script that reads a CSV and totals by month
Working code will come back. The problem: 'working' means different things.
Without done-conditions, AI declares done on the narrowest reading. Files without headers, values containing commas, blank lines, non-numeric cells: everything real data actually has sits outside 'it works.' And when the task touches existing code, the moment you don't name what must not break, things that were fine change along with what you asked to fix.
What to add to the request
1. Done-conditions: numbered and observable
Rewrite it like this
Done means: 1) header presence auto-detected 2) non-numeric amount cells report their line number to stderr and processing continues 3) output is month-ascending CSV on stdout. Python 3.11, standard library only.
Write each condition so you can see with your eyes whether it's met.
2. Define behavior on failure
Specify only the success path and the failure path becomes AI's discretion. Decide what the error message carries, what the exit code is, whether it continues or stops. This comes before the edge-case list. Miss a case and a stated failure principle still handles it consistently.
3. Pin language, runtime, dependencies
Unpinned versions bring syntax that won't run in your environment. State the dependency policy too. And add 'claim no performance numbers you didn't measure'. That filters out baseless lines like '10× faster.'
The four parts of the finished instruction
- Goal and stack — language, runtime, dependencies, and execution environment, as fixed values or slots
- Acceptance criteria (numbered) — observable done-conditions
- Edge cases — behavior on failure (message, exit code, recovery) and existing behavior that must not break
- Verification — the command to run and sample input
Example — a done-condition becoming a verification step
Continuing from condition 2)
Verify: with a sample.csv whose third line has 'abc' in the amount column, stderr shows 'line 3: amount is not a number', the monthly totals on stdout include only the remaining lines, and the exit code is 0.
Every condition needs a verification sentence like this before 'done' can be seen rather than claimed.
When the work touches existing code, it lists what must not break — 'results for files with headers stay identical', 'existing command-line options keep working'. Without that list, things that were fine change along with what you asked to fix. And one line forbids claiming performance numbers that weren't measured.
Checklist for writing it yourself
- 1Are the done-conditions numbered, observable sentences
- 2Did you define failure behavior (message, exit code, recovery)
- 3Did you pin language, runtime version, dependency policy
- 4Did you list existing behavior that must not break
- 5Did you require a way to verify — a command to run, sample input
Reading helps; trying is faster.