Turn “Help Me Code” Into a Prompt You Can Test

“Write me a function” is not enough. If I do not know what behavior I want, the model can write something neat that solves a different problem. A better coding prompt starts with a small contract: inputs, outputs, special cases, and checks. Let’s use a game example. I want to award a bonus to a player who finishes a level quickly. I do not want the bonus to go negative. Once the function exists, Use AI to Draft Tests, Then Challenge the Tests helps you catch missing cases instead of trusting the generated tests.

Make a speed bonus function for my game. This invites the model to invent the scoring rule. It might decide that faster times always earn more points, but I have not stated the threshold or formula. If I dislike its result, I cannot tell whether the model failed or my brief was incomplete.

Before asking for code, I decide on a simple rule: Input: completion time in whole seconds. Rule: give 100 points at 0 seconds; subtract 2 points per second. Floor: never return less than 0. Invalid input: reject negative times with ValueError. Output: an integer. Now my prompt can be precise without being huge: Write a Python function speed_bonus(seconds: int) -> int. Return max(0, 100 - 2 * seconds) for nonnegative whole-second inputs. Raise ValueError if seconds is negative. Include a short docstring and tests for 0, 10, 50, 80, and -1. Do not use external packages. Explain any assumption you make about non-integer inputs, but do not silently change the stated rule. This lets the model choose implementation details while I control the behavior. It also tells me what to review.

Boundary cases catch more than a typical case. I expect speed_bonus(0) to be 100, speed_bonus(10) to be 80, speed_bonus(50) to be 0, and speed_bonus(80) to stay at 0. A negative value should raise an error. If the model’s test suite only checks 10, it has not checked the floor or the invalid-input rule. I would also decide whether a float such as 10.5 should be rejected or handled. The prompt deliberately asks the model to state that assumption instead of burying it. I can then make the rule explicit in the next revision. This is especially important when you are building a feature from a rough idea: unanswered questions often become hidden behavior.

Suppose the model writes the formula correctly but accepts a float. I can respond: Keep the scoring rule unchanged. Require a nonnegative integer input and reject floats with TypeError. Add one test for 10.5 and show only the changed function and tests. Notice what this does: it preserves the original contract, adds the missing rule, and gives a check. It does not restart the project with “make the code production ready.”

After the function passes tests, I may ask a second model or a second pass to review it: Review this function against the contract below. Report only behavior mismatches, missing boundary tests, or assumptions I should decide. Cite the exact line or test involved. Do not rewrite the function unless I ask. That is often more useful than asking for a complete rewrite. It focuses the review on evidence. If the model flags a concern, I still run the code and judge the concern myself.

Take one small function you want to build. Write a contract in five lines: input, output, rule, edge case, invalid input. Then prompt for the function and tests. Run the tests. Record which requirement the model missed, if any. Your next prompt should fix that requirement alone. Keep learning: Debugging With AI: Reproduce the Bug Before Requesting a Fix, Use AI to Draft Tests, Then Challenge the Tests, and A Tiny Evaluation Set for Your Favorite Coding Prompt.