Imagine a small task-list app. You press “Add task” and the screen gives you no response. You try again. Now there are two entries.
Being able to create a task is one question. Having enough evidence to let someone else depend on the feature is another.
This is a hypothetical example, not a product or client incident. Assume the product rule is that one creation operation should produce at most one task within an agreed retry window. Two separate operations may express a real intention to create two tasks; matching titles alone cannot settle that distinction.
This is the example’s product promise; the HTTP definition of idempotency provides background on repeated requests and their intended effects.
AI can help change the code, write tests and explain a failure. Someone still needs to explain the promise being made, the evidence behind it and the questions that remain open.
I would put those judgments on a four-line handoff card. It is a thinking and communication aid, not proof of acceptance or permission to release.
Line one: the promise
What must hold, for whom and under which conditions?
“Adding tasks works” leaves too much unstated. In this example, the promise is that retrying the same creation operation after a lost response should not create another task within the agreed window. The specification must still explain how retries are identified and how long that window lasts.
AWS’s discussion of retries and idempotency describes this kind of uncertainty: receiving no response does not establish that nothing happened. The example borrows that problem; it does not endorse a particular implementation.
Line two: the evidence
What did you observe, in which version, environment and scenario? What remains untested?
“Tests passed” gives the next person little to work with. Record the version. Say whether the checks actually covered a retry after a lost response. Identify what was observed: the screen, the stored records, or both. Explain how the test environment differs from the environment people will use.
If only the ordinary success path has been checked, say so. Keep the promise within the reach of the evidence.
Line three: the failure response
How will you notice a failure, limit further effects and address effects that already occurred?
If duplicate tasks already exist, rolling back the application does not automatically remove them. Stopping new writes, identifying affected records and deciding how to repair them are separate jobs.
Likewise, a notification already sent does not disappear when code is rolled back. A handoff needs to account for those consequences.
If a reliable way to notice or handle the failure is missing, this line can say: “Not yet established. We need a way to observe the problem or help from someone qualified to assess it.”
Line four: the limits of judgment
Which changed condition requires a new check? Who can help with the remaining unknowns?
A single-user tool gains collaboration. A feature tested in one environment moves to another data store. Earlier evidence may no longer answer the relevant question.
Choose one changed condition. Predict which behavior it might affect, then check that prediction against evidence. A fluent explanation can still be wrong. The gap between the prediction and the result gives you something specific to investigate.
This separates three judgments: output concerns what has been built; control concerns noticing and handling problems; capability includes knowing what you can assess and where you need help. They are not levels to pass in sequence.
There is still room for delegation
Founders do not need to understand every library’s internals. Mature tools and professional collaboration make it possible to delegate substantial work.
What matters is understanding proportionate to the consequences, along with access to people who can resolve the unknowns. A personal practice tool and a service other people depend on require different depths of evidence. A completed card cannot replace appropriate specifications, qualified review or actual verification.
My earlier essay on learning programming when AI can code discusses specification, debugging and understanding. That essay is in Traditional Chinese. This card adds a smaller action: before handing work over, make the basis of your judgment visible to the next person.
Try it with your next small feature. Fill in the four lines. Pick one unanswered question and take the evidence you have to someone who can help assess it.
Sometimes the most useful part of a handoff is an unknown made visible early.
Download the bilingual handoff decision card (PDF, 2 pages)
Related reading: turning AI failures into tests you can run again. For the learning distinction, AI-assisted performance and learning is a Traditional Chinese original.
