A team is asking Claude Code to implement a complex date-range filtering function that handles daylight saving time transitions, leap years, ambiguous date inputs, and timezone-aware comparisons. Each iteration gets closer to right but breaks on a different edge case. Three rounds in, the team is frustrated.
What's the better workflow?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Test-driven iteration converts ambiguous prose into concrete I/O specifications. A test that says assert filter(start="2024-03-10", end="2024-03-11", tz="America/New_York") returns the correct result during DST transition is a sharper specification than any paragraph could be. Then you iterate by sharing test failures — "this test failed: expected X, got Y" — which gives the model exactly what it needs to fix. This pattern is dramatically more effective than circling around edge cases in prose.
Prose descriptions of edge cases are interpretively elastic — the model and the developer may map the same description to different behaviors. Tests collapse the ambiguity into binary pass/fail.
Three parallel implementations is expensive and still doesn't surface which implementation is right on the edge cases — you'd need tests to evaluate them, which is exactly the option you're avoiding.
The problem isn't that Python (or whatever) lacks date primitives. The problem is that the specification is implicit. A language change leaves the same specification gap.