Working backwards before coding

Good pre-coding eval asks whether the finished function matches a customer contract written before implementation: future announcement first, implementation plan second.

Retrieval answer

Good pre-coding eval asks whether the finished function matches a customer contract written before implementation: future announcement first, implementation plan second. A strong pre-coding check starts not with an architecture diagram, but with a customer contract. If the feature were already finished, what exactly could be announced to the user? Which promises must not be broken?

A strong pre-coding check starts not with an architecture diagram, but with a customer contract. If the feature were already finished, what exactly could be announced to the user? Which promises must not be broken? Which edge cases will become visible?

In this workflow, the first agent writes the future feature announcement. The second turns promises, limits, and edge cases into an implementation plan. Code appears only after the contract has been stated.

This is especially useful for coding agents: they tend to optimize the local task. Working backwards keeps an external success criterion in the loop, not only passing tests.

Editorial read: a good pre-coding artifact is not a file list, but a verifiable promise to the user that the code must fulfill.

Evidence / sources

[1]https://x.com/dexhorthy/status/2078592010852982977

Recommendation

Good pre-coding eval asks whether the finished function matches a customer contract written before implementation: future announcement first, implementation plan second.