Specify Inputs, Outputs, and Edge Cases
A task is not defined until its boundaries are defined. Senior engineers think in terms of "what goes in, what comes out, and what happens when things go wrong." Bake that into the .
Write a function to parse a date string.
Write a function parseDate(input: string): Date | null.
Inputs: ISO 8601 strings ("2026-06-14", "2026-06-14T10:30:00Z").
Output: a Date object, or null if the string is invalid.
Edge cases to handle:
- empty string or whitespace -> null
- valid format but impossible date (2026-02-30) -> null
- trailing garbage ("2026-06-14xyz") -> null
Do not throw. Return null for all invalid input.
When you name the cases, the AI handles them. When you do not, it writes the happy path and you discover the gaps in production. The same discipline applies beyond pure functions: for an , specify the success response and the error responses (what on a duplicate email? on a malformed body?). For a UI component, specify the empty state and the loading state, not just the populated one. The interesting behavior of most software lives at its edges, so that is where your prompt should spend its words.
If you are not sure what the edge cases are, ask the AI first: "What edge cases should a date parser handle?" — then feed the answer back as constraints. This turns the model from a code generator into a checklist generator, and reviewing a checklist is faster than debugging the cases you forgot.