TL;DR: In 1980, I was a young engineer writing Pascal for a water district that lost contact with half its infrastructure for weeks every winter. We built a control system that ran without humans when humans couldn’t physically reach the equipment. The system knew its limits and failed safely when conditions exceeded what it had seen. That lesson carries into how I use AI on a book.
In 1980 I sat in front of a green monochrome screen at two in the morning, writing Pascal code. It was going to control a pumping station forty miles away, in the middle of a snowstorm I’d never see.
I was young. I had no idea I was working on what people would call artificial intelligence in forty years. I thought I was writing a control system. I thought I was writing the controller for a remote pumping station in a water district with a problem nobody had solved. Every winter, for weeks at a time, half their equipment was unreachable.
Let me tell you what I was thinking that night. I’ve spent four decades watching the same problem reappear in larger forms with bigger budgets, and the lesson I learned at 2 a.m. in front of a CRT in 1980 has never stopped being the lesson.
What I was thinking
My thoughts were on a man I’d met three weeks earlier, who had worked at the water district for thirty years. For more, see why every writer should embrace AI as a digital assistant.
He’d told me, in a tone of voice I’ve never forgotten, that the existing automation at the remote stations was unsafe. Every winter at least one tank overflowed. At least one pump damaged itself. At least one valve got stuck, because the timer held it open through a temperature drop the timer wasn’t smart enough to handle. He couldn’t get to the stations to prevent any of it.
By the time the roads opened in spring there was always damage to repair. Sometimes the damage was expensive. Once it had flooded a small town. He told me that the night before they had to evacuate the town, he hadn’t slept.
He wanted the new system to not do that.
That was what I was thinking about at 2 a.m. on a Tuesday, writing Pascal.
The man who couldn’t sleep the night before they evacuated the town. The man who, by the way, was going to be the one using my system to do his job. He was going to be the operator at central command, watching the green screen at headquarters when the lines went down and the remote stations had to decide for themselves.
The program I was writing would take some of his decisions away in the hours when he couldn’t make them, and hand them back in the hours when he could.
What I was not thinking
I wasn’t thinking that I was going to replace him.
The contrast with what people are doing in 2026 is so absolute that I have trouble describing it without sounding like I’m exaggerating. It never occurred to me, or to anyone on the project, to build a system that did what he did and then fire him.
The system existed because there were hours when he couldn’t be in the room. That was the entire reason for the system. The hours when he could be in the room were his. The hours when he couldn’t be in the room were the system’s, and the system was designed to do as little as possible while still keeping the water flowing. It was conservative, made the smallest decisions it had to make, and logged everything for him to review when the lines came back up.
It deferred to him in every situation where it could. This was the design. The technology wasn’t trying to be a person. The technology was a competent stand-in for a person during the hours that person was unreachable, doing the minimum required to keep the system safe.
I run AI the same way in my own work.
I use it every day as a digital assistant: it helps me turn session transcripts into summaries I send to the client, and it gives me a first-pass outline to argue with. I still do the writing. The tool takes the routine hours and hands every judgment back to me, the same deal the Pascal controller had with the man at central command.
Executives in 2026 are deploying something else. Systems that try to do everything the human did, all the time, with the human removed. That’s a fantasy with a corporate-communications budget. I tell that story in my web development journey.
What did Richard Lowe learn from his 1980 Pascal project?
The system shipped. It ran that winter. It ran the next winter. It ran for two decades, making small decisions when it had to and deferring large ones to humans. When it met conditions outside what it had been trained on, it failed safe. That happened periodically, and the team had designed for it.
I went on to other projects. I watched the industry develop. I watched the technology get more sophisticated, more capable, more powerful. I watched the language change. Control systems became automation. Automation became smart systems. Smart systems became expert systems. Expert systems became machine learning. Machine learning became artificial intelligence. The technology got faster, the buzzwords got grander, and the budgets got larger.
The fundamental problem, the problem that man at the water district described to me with the tone of voice I’ve never forgotten, didn’t change. The problem is that any system that works without human judgment in the loop will eventually face a situation outside what it was trained on. The system has no way to know that it’s outside its training. It produces a confident response to the new situation. The response is wrong. Somebody pays.
This is true in 1980 Pascal. This is true in 2026 large language models. The mechanism is identical. The cost scales with what you let the system control. The man at the water district understood this. The executives who deployed Air Canada’s chatbot didn’t. The executives who deployed Klarna’s customer service chatbot didn’t. The medical practice that deployed the chatbot that traps the patient for five minutes every call didn’t.
I don’t have much patience for the line that nobody could have predicted these failures. A young programmer and a thirty-year operator predicted them in 1980 with a green screen and a snowstorm. A company that puts a chatbot in charge of refunds and never asks what it’ll say to a question it hasn’t seen has made a choice about cost, and the customer on the other end of the line pays for it.
They all built systems that tried to do what the humans did in the hours the humans were absent, without the constraint we had in 1980. We understood explicitly that the system was standing in for a person, and we designed every line of it around that.
What does learning Pascal in 1980 teach about AI?
I’ve been trying, in different forms, for years, to teach the lesson I learned at 2 a.m. in front of a green CRT in 1980. The lesson is this. The technology you can deploy is always smaller than the press release wants it to be.
The press release is a marketing document. The technology is what it is. They’re not the same thing. The press release will tell you the technology can do everything the humans did. The technology can’t. At most, it can do the routine portion of what the humans did, in the hours when the humans are unreachable, with suitable fail-safe defaults for the situations outside its training. That’s what it could do in 1980. That’s what it can do in 2026.
The companies that deploy the technology according to what it can do are the companies whose systems run for two decades. The companies that deploy the technology according to what the press release said it could do are the companies whose systems get reversed within a year. The pattern is identical across forty years of technology shifts. The buzzwords change. The pattern doesn’t.
If you read What a Snow-Locked Water District Taught Me About AI, you read the third-person version of this story, the parable. This piece is the same story, told as a memoir, because the lesson I learned was concrete, and it was given to me by one man, on one project, in one year, and I’ve never forgotten it.
What I want you to do with this
I want you to think about whatever AI rollout is on your desk right now.
Ask yourself whether the technology you’re about to deploy is being deployed according to what it can do, or according to what the press release said it could do. I want you to ask yourself who’s going to be doing the work the technology can’t do, after the deployment.
Then ask yourself whether you’ve built in the explicit fail-safe defaults for the situations outside the technology’s training, the way we built them into the Pascal controllers in 1980, because the technology in 2026 is more sophisticated than the technology in 1980 in many ways, but the failure mode is exactly the same.
And I want you to think about the man who couldn’t sleep the night before they had to evacuate the town. He was right about what the technology needed to do, and he was right about what it didn’t need to do. He understood the work, he understood the limits, and he was specific about both. The systems that work get designed by people like him.
The systems that fail get designed by people who never met him, or anyone like him, and who don’t understand that he exists, and who deploy the technology as if the man doesn’t need to be in the room.
He does. He always does. Every successful automated system in the next forty years will have a person like him somewhere in the design. Every failed one will be missing one. The Birth of the Augmented Human is the longer version of what that looks like across professions, but the version I know best is one engineer, one operator, and one Pascal program, in a winter I never saw, forty years ago.
The inexcusable part of 2026 is that nobody signing off on these rollouts is short of information. The reversals are public, the lawsuits are public, and executives keep approving replacement projects because a press release is easier to present to a board than a system that does less. The customers stuck in the loop and the staff who got cut pay for that decision, and the person who approved it rarely pays anything at all.
