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.

Jul 22, 20261 min1 source

In one minute

Good pre-coding eval asks whether the finished function matches a customer contract written before implementation: future announcement first, implementation plan second.
The record is connected to 0 topics: .
1 public source carries the evidence boundary.

Source ledger

Publishable sources attached to this record.

1 public source

#	Source	Role	Public status
1	x.comsource	primary receipt	`source_urls`

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.