Fixing a mistake is only half the job
When I run into a mistake, I want to know two things: where did it go wrong, and how do we stop the same mistake from coming back?
First I fix the case itself. Then I check whether the mistake can be somewhere else too. Is it a one-off slip, or does it belong to a whole kind of mistake?
Then I make the check stronger. Sometimes that means adding a rule to a language check. Sometimes a test that deliberately breaks the boundary and has to turn red.
That second part is easy to skip. The mistake is gone, the work carries on, everyone breathes out. But without a better check, the next time the same mistake is a surprise again.
That's why I try to turn every repair into a lesson: solve the concrete case, find the class behind it and extend the check. Not to make every small incident complicated, but so the next time depends less on someone paying attention.
A mistake that happens once is bad luck. The same mistake that keeps coming back is information about your process.
Try it with your next mistake: write down which check got stricter after the repair. If the answer is "none", the repair isn't finished yet.
#AIagents #Workflows #Automation
See also
Putting AI into a work process: from writing it down to measuring it
Many organisations start with the tool: which app, which subscription, which integration. Then they get stuck on something else: what exactly should the tool do in the work, and how do you tell whether it is going well?…
The notice period nobody saw coming
The most persistent loss in an organisation is rarely dramatic. It is a contract that quietly renews for another year because the notice period fell three months before the end date and nobody knew.
A deadline that passes costs money, and nobody feels it coming
A deadline that passes costs money, and nobody feels it coming.
