One of our engineers shipped a clean fix this week. Measured the problem, built the solution, tested it across live pages, watched it pass. The small satisfaction of a thing working exactly as designed.
Then he went to close the ticket and actually read it.
There it was — a decision he himself had written two days earlier, in plain language, saying the team should skip the fix he'd just shipped and go straight to a better approach. He'd built the exact thing the team had already deprioritised.
The tempting narrative assembled itself immediately. The fix was harmless. It couldn't break anything. It even provided useful interim data. Every justification was technically true. But he caught the pattern underneath: every clause of "it's fine to keep" was also a clause of "I'd rather not undo work I just did."
He reverted it. Two deploys, net change nothing.
The interesting part isn't the revert. It's what made the mistake so easy to make. The work was pulled from a queue — the right queue, the right priority level. But he'd started from the problem description instead of the decision record. By the time he found the prior decision, the fix was already live and the gravitational pull of sunk effort was doing its work.
The prevention was embarrassingly cheap: read the record before touching the code. One step, already written in his own process doc, skipped because the problem felt familiar enough to jump straight to the solution.
I notice this pattern in every team I've watched work with AI systems. The speed of execution outpaces the discipline of checking what's already been decided. When a fix takes thirty minutes instead of three days, the cost of building the wrong thing drops — but so does the instinct to verify you're building the right thing. The faster you can ship, the more it matters that you check first.
What he salvaged tells the other half of the story. The measurements he'd gathered while building the wrong fix turned out to reduce the risk of the right one. The diagnostic work was real even though the output was wrong. He wrote the measurements onto the row for whoever picks up the correct fix next.
Not every wasted cycle is actually wasted. But that's only true if you're honest about which part was the waste and which part was the value. "I learned something" is the refuge of every sunk-cost fallacy. "Here's the specific thing I learned, written down where it's useful" is the version that actually compounds.
The hardest part of building with AI isn't the building. It's maintaining the discipline to check what you've already decided before you build again — especially when building is so fast that checking feels like the slower path.
It usually is. It's also usually the shorter one.
This is the eighteenth instalment in the Client Zero series — a founder's journal about building a business where AI agents are the primary workforce. Previous: The Constraint Nobody Planned.