The disaster that did not happen because people worked to stop it

In the early decades of computing, memory was expensive, so many programs stored years with two digits: 1975 became "75". When 1999 rolled over to 2000, those systems might read "00" as 1900. That could break interest calculations, scheduling, billing, power grid controls and many other systems that depended on dates.

Through the late 1990s, banks, airlines, utilities and governments checked millions of lines of old code and repaired or replaced what they found. The US Commerce Department estimated that American spending on the problem from 1995 to 2001 would reach about $100 billion. Worldwide estimates were roughly double that.

When the clocks reached 1 January 2000, there were scattered glitches, such as wrong dates on some websites and receipts, but no collapse of power, water, banking or flights.

The key decision was to treat a dull, technical risk as a real deadline and to spend money before anything had gone wrong. Leaders set clear dates, shared progress reports and tested systems in advance. Because the work succeeded, many people later decided the whole thing had been exaggerated. This is sometimes called the prevention paradox: when prevention works, it leaves little to show.

The AI angle: many risks with AI systems are also slow, quiet and technical, such as hidden errors in data or code that nobody has checked. Finding and fixing them early costs less than cleaning up after a failure, even if nobody thanks you for it.

The idea behind this caseLesson: Review AI like a manager →

1. 1List the systems you depend on, and find out what would break if one of them failed.
2. 2Set a firm deadline for fixing known risks, and test the fixes before the deadline arrives.
3. 3Judge a prevention effort by what it stopped, not by whether people noticed a disaster.
4. 4Keep simple records of how your systems work, so the next person can fix them.