Asking for Code: Small Steps, Examples and Constraints

The problem

You ask the assistant to "build a CSV import feature with validation, error reporting and a progress bar." It produces 600 lines across eight files. Some of it is good, some isn't, and you can't tell which without reading everything. You end up rejecting it all.

Real-world analogy

You would not ask a builder to "build the house" and only look when it is finished. You agree on the foundations, check them, then the walls, then the roof. Each step is small enough to inspect.

The idea

• Plan first: ask for a short plan (steps and files) before any code, and correct the plan.
• One step at a time: a function, a test file, one endpoint; review and run each before continuing.
• Give examples of input and expected output; they remove ambiguity faster than paragraphs.
• State constraints: libraries allowed, performance limits, what must not change.
• Ask for tests with the code, or write them first (next module).

The code

An example-driven request turns into code that can be checked against the same examples:

# Request: "Write parse_amount(text) -> int cents. Examples:
#   '12' -> 1200, '12.5' -> 1250, '1,234.56' -> 123456, '  7.05 ' -> 705, 'abc' -> ValueError"
from decimal import Decimal, InvalidOperation

def parse_amount(text):
    cleaned = text.strip().replace(",", "")
    try:
        value = Decimal(cleaned)
    except InvalidOperation:
        raise ValueError(f"not an amount: {text!r}")
    return int((value * 100).quantize(Decimal("1")))

examples = {"12": 1200, "12.5": 1250, "1,234.56": 123456, "  7.05 ": 705}
for text, expected in examples.items():
    got = parse_amount(text)
    print(repr(text), "->", got, "ok" if got == expected else f"expected {expected}")
try:
    parse_amount("abc")
except ValueError as e:
    print("'abc' ->", e)

'12' -> 1200 ok
'12.5' -> 1250 ok
'1,234.56' -> 123456 ok
'  7.05 ' -> 705 ok
'abc' -> not an amount: 'abc'

Common mistakes

• Asking for a whole feature in one prompt.
• Describing behaviour in prose when two examples would be clearer.
• Not saying what must stay unchanged (public APIs, database schema).
• Continuing to the next step before running the current one.

Key points

• Ask for a plan, then build in small, reviewable steps.
• Use input and output examples; they double as tests.
• State constraints and what must not change.

Further reading: Claude Code best practices: explore, plan, code, commit · Prompt engineering overview