The two pieces before this one were about tooling that doesn’t exist and tooling that does. The thread’s last question is what happens once you can see the manual work clearly: some of it should be made easier, and some of it shouldn’t exist at all. Those are different responses, and reaching for the first one automatically is how a company ends up with an elegant internal tool for repairing a problem it could have stopped creating.

The distinction is usually visible in the shape of the task. Work that exists because a human judgment is genuinely required — approving an exception, deciding whether a refund is warranted, choosing between two plausible readings of a customer’s intent — should be made fast and pleasant, because it isn’t going away. Work that exists because the system produced a state it shouldn’t have is a different animal. Correcting records that got into an impossible configuration, re-running jobs that fail predictably on certain inputs, manually reconciling two systems that drifted — each of those is a symptom, and automating the repair makes the symptom cheaper while leaving the cause untouched.

Cheaper symptoms are not neutral, either, because they lower the pressure that would otherwise force a fix. A repair that takes an hour gets escalated; the same repair reduced to a button gets clicked a hundred times a month by someone who no longer thinks of it as a defect. The tool that made the work bearable is also the thing that made it permanent, and the frequency counter that would have justified fixing the root cause never gets read because nobody’s in pain anymore.

The practical version is to ask, whenever a manual process is about to be smoothed, which category it’s in — and if it’s a repair, to at least count it. Frequency is the argument that gets root causes fixed: “we corrected 400 records this quarter” is a case, where “support handles it” is not. That’s the same instrumentation argument as the dead-code thread’s usage data and the limits thread’s rate-limit hits — you can’t make the case for the deeper change without the number, and the number only exists if someone decided to record it.

So the thread ends where it began, with the observation that the work people do around a product is a description of the product’s gaps. Some of those gaps should be filled with better tools. Some are telling you the system is producing states it shouldn’t, and the honest response is upstream. What you don’t want is to become very efficient at cleaning up after a problem you could have stopped having — which is the most comfortable failure mode available, because from the inside it looks exactly like getting better at your job.