Main idea

A lookup screen hacked together to help a team out, an export put up in two hours, a dashboard built on the side: these objects are built under an explicit regime of low requirements — no tests, no review, no governance — and that regime is justified by their supposedly short life.

The drift doesn't happen through negligence. It happens because the tool is useful. You show it, people ask for improvements, they ask when they can use it, it enters a team's weekly routine, then it becomes a mandatory step in a process. At no point did anyone decide it was becoming critical: criticality arrived through use, while the requirement regime stayed the one set for a throwaway.

Companies already know this mechanism in other forms — the department's spreadsheet, the macro only its author understands, the on-call script. A code assistant doesn't invent it; it simply lowers the entry price, and therefore raises the number of objects that take that path.

Why it matters

This moves the control point. Banning the building doesn't address the problem, since the problem isn't the building but the absence of any moment at which criticality is recognized. What has to be instituted is a threshold: a tool shared by several people, or embedded in a recurring process, changes category and takes on the requirements of its new category.

It also gives the right reading of an incident on such a tool: it wasn't the initial quality that was at fault, it was that nobody reattached the object to its actual use.

Nuances and limits

Not every throwaway tool drifts, and most really do die. Treating every script as a future critical system reproduces exactly the formalism you were trying to avoid, and removes the benefit.

The difficulty is that the tipping signal is social — someone has started depending on it — and shows up in no technical indicator.

Open questions

• What observable signal, other than a breakdown, lets you establish that an internal tool has crossed the threshold at which its requirement regime has to change?