사람이 쓴 글
Why code ordered with 'just make it work' always gets rewritten
Writing done-conditions, edge cases, and must-not-break lists into a coding request.
이 가이드는 영어로 쓰였습니다. 한국어판 읽기
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' — it filters out baseless lines like '10× faster.'
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
읽었으면 직접 해 보는 편이 빠릅니다.
지금 만들어 보기