Topics / Engineering practice
Plausible code can implement the wrong promise.
Generated code often looks reasonable because it matches a familiar pattern. The useful question is whether that pattern fits your product’s actual obligations.
Find the assumption hiding inside the implementation.
Illustrative example
“Try again” creates a second payment.
A timeout handler retries a request with a fresh identifier. The code is readable and each request succeeds in isolation. But the timeout may mean the first request succeeded without returning a response. Retrying under a new identifier can create another charge.
The defect is not the presence of a retry. It is the mismatch between retry behavior and the intended at-most-once effect. A style review will not establish that contract.
Turn the assumption into a checkable obligation.
- Recover the accepted behavior from contracts, incidents and domain owners.
- State the failure conditions, including uncertain outcomes.
- Construct a test that would fail if the assumption is wrong.
- Inspect the persisted effect, not only the HTTP status.
- Retain the case as regression evidence after the fix.
In this example, simulate a successful charge followed by a lost response, then retry. The expected ledger effect must come from the product contract, not from whatever the current code happens to do.
Give future agents the same constraint.
Proof retains that obligation with its implementation links, hazard and verification evidence. A later optimization can then retrieve the payment promise and the prior failure case. This is more useful than saving only the chat where someone noticed the bug.
The example illustrates a failure pattern, not a measured defect rate for any coding model. Evaluate your own changes against their actual requirements.
Try it on your software
Bring a change that looks right but still worries you.
We will identify the assumptions and the evidence that could challenge them.