← Table of Contents · Page 270 of 868
ENDING A RUN
Part 4 of 10
LEAVING A USEFUL RECORD
Every ended run should leave behind a record that a stranger could understand weeks later.
The record should state the original goal, what was done, what was produced and where it is stored, what was not done and why, and how much time and money the run consumed.
This record serves several readers.
The user reads it to decide what to do next, a teammate reads it to continue the work, and an engineer reads it to learn from the run.
Write records in plain language and keep them short, with links or file names for the details.
Records are also the raw material for evaluation, because a collection of past runs shows how the agent behaves over time.
COMMON MISTAKES AT THE END OF A RUN
Several mistakes are common at the end of a run.
One is declaring success because the model says so, without any independent check.
Another is leaving temporary files, open connections, or half-finished changes behind.
Another is hiding a failure behind cheerful wording, which leaves the user believing something that is not true.
A fourth is ending silently, so that nobody knows whether the run finished.
Guard against these by making the final step mandatory, by checking results with code wherever possible, and by writing the failure report with the same care as the success report.
Advertisement
Read Aloud:
0:00 / 0:00