Specify behaviour before generating code

Learning outcome: Turn a feature request into observable cases.

A coding request needs behaviour, boundaries and an environment. State the inputs, expected outputs and failure cases before asking for an implementation. Identify the existing conventions and files that the change should fit. Avoid asking for an entire application when the problem is one defined function.

Acceptance cases should be independent of the proposed code. If the same mistaken assumption appears in both implementation and test, a green result can be misleading. Include at least one empty input, one invalid input and one boundary value. Keep user-facing behaviour distinct from an implementation preference so a reviewer can challenge unnecessary complexity.

Worked example

A fictional function calculates a percentage reduction. The specification says old=30 and new=24 gives 20%; old=0 is undefined and must return an explicit error; an increase must not be labelled a saving. Asking only for “a percentage helper” leaves all three decisions open to guessing.

Try it yourself

Write acceptance cases for old=30/new=24, old=0/new=5 and old=10/new=12. Decide whether increases return a negative reduction or a separate label.

You can do this exercise on paper. If using an assistant, keep to the fictional material and an approved tool.

Check your understanding

What should define the test result?

1. The agreed behaviour and independently checked examples
2. Whatever the generated function currently returns
3. The answer that makes every test green

Workbook

Download the course workbook to record your answer and compare it after the knowledge check.

Further reading

• Anthropic: effective agent design
• Anthropic: evaluating agents