Reactive software was a 40-year detour

A mainframe in 1959 did not wait for you. You handed it a deck of punch cards, walked away, and came back hours later for the result. The machine ran on its own clock, chewing through the queue while you slept. Then we made computers interactive, and they got faster, and friendlier, and we taught them a habit they never had before: to sit perfectly still until a human pokes them. Sixty years later, that habit has a price. The most expensive software in your company spends almost all of its life doing nothing, waiting for someone to remember it exists.

That was supposed to be progress. We think it was a wrong turn.

Software learned to wait, for a click, a query, a prompt. The next platform does not wait, because work does not.

The arc nobody names

We tell the story of computing as a march toward speed, and that part is true. But there’s a second arc underneath it, about who starts the conversation, and on that axis the line is not straight. It bends backward.

Batch came first. In the 1950s and early 1960s a computer ran jobs from a queue with no human in the loop at all, you submitted work and the machine decided when to do it (Wikipedia: Batch processing). It was clumsy and slow, but notice the shape: the machine had initiative. It worked without you standing over it.

Then came interactive computing. Time-sharing emerged in the early 1960s and became the dominant model by the 1970s, letting many people use one machine through a terminal and get an answer as they typed (Computer History Museum: Timesharing). This was a genuine leap, computers stopped making you wait hours. But it quietly rewired the relationship. The human now drove every interaction. The machine answered; it no longer initiated.

We kept optimizing that one move, the answer, for fifty years. Faster terminals, then desktops, then the web, then the phone, then the chat box. Each generation made ask → answer slicker. None of them questioned whether ask → answer was the right loop in the first place.

The detour, named

Here is the loop we ended up worshipping. You notice something needs doing. You open the app. You ask. It answers. Then it goes dark again until the next time you notice.

The whole burden of noticing sits on the human. Always.

This is the classic request-response model, and the textbook description of it is unintentionally damning: the client sends a request and then blocks, it does nothing else until the server replies (GeeksforGeeks: Request-driven vs Event-driven). We built an entire industry on software that, by design, waits. We called the waiting “responsiveness” and shipped it for forty years.

The naive view says this is just how software works: a tool is inert until a person uses it, the way a hammer is. That feels obviously true. A hammer that swung itself would be alarming.

But software is not a hammer, and treating it like one is exactly the failure. A hammer has no idea a nail exists. Your software does, it can already see the calendar, the inbox, the unpaid invoice, the contract that lapsed on Tuesday. It is sitting on top of the information that should trigger the work, and it does nothing with it, because we trained it to wait to be asked. The cost isn’t visible in any one moment. It’s the accumulated tax of every task that needed doing while the only system that could see it was idle, politely waiting for a human to type the question.

Software learned to wait, for a click, a query, a prompt. The next platform does not wait, because work does not.

What “doesn’t wait” actually means

So picture the correction. Not a smarter answer box. A different loop entirely.

The reactive loop has a hole in it, and the hole is the most important part: between “the work needs doing” and “you open the app,” there’s a gap where nothing happens and only a human can close it. Every dropped ball in your company lives in that gap.

The proactive loop deletes the gap. The system is always running, that’s the batch machine’s old initiative, returned. It watches your world in one place. When something changes, it notices, unasked. For the small things it has earned trust on, it just acts and tells you afterward; for the rest, it drafts the move and waits one beat for your nod. Then it goes back to watching. There is no “go dark” state, because the work never goes dark.

The naive objection here is obvious and worth taking seriously: isn’t software that acts on its own just a robot waiting to do the wrong thing at scale? That’s the real fear, and the answer isn’t to make it smarter. It’s to make it earn the right to act, the way a new hire does, read-only first, then draft-and-confirm, then send-and-notify, and only at the end, for the moves it has gotten right a hundred times, act-and-report. Initiative without a leash is reckless. Initiative on a leash that lengthens with proof is just a good colleague.

Same information either way. The reactive app has the calendar and the message and stays silent. The proactive system has the same calendar and the same message, notices they disagree, and speaks up before anyone drives to the wrong building. The difference was never intelligence. It was who was awake.

Why the detour lasted forty years

It’s fair to ask: if waiting was the wrong loop, why did the best engineers on earth build it for two generations?

Because for most of those forty years, it was the right loop, software genuinely couldn’t be trusted to decide what to do. It had no judgment. A program that acted on its own would act stupidly, so we wisely confined it to answering exactly the question it was handed. Reactive wasn’t laziness. It was a correct response to machines that couldn’t reason.

That constraint is the thing that just changed. The reason “wait to be asked” was safe is that software couldn’t tell a signal from noise. Now it can, well enough to read an inbox and know which three of forty messages matter, well enough to see a rescheduled meeting and a stale invite and notice they contradict each other. The moment software can judge, the original reason for the detour evaporates. Keeping the wait-loop after that isn’t caution anymore. It’s habit.

Software learned to wait, for a click, a query, a prompt. The next platform does not wait, because work does not.

The turn: stop being the trigger

Here’s what the detour really cost, and it isn’t measured in software.

For forty years, you have been the missing piece of every reactive loop. You are the one who has to notice the work, remember the tool, open it, and ask. Strip that down and it’s a strange job description: a brilliant person, spending the bulk of their day being the trigger for software that could have triggered itself. Noticing is the lowest-leverage thing a human mind can do, and we built every system in the company to depend on it.

The correction gives that job back to the machine, the one part it was always better at. Vigilance is exactly what a person is worst at and an always-on system is best at. When the noticing moves off you, what’s left is the part that was always yours: deciding what’s worth doing, what “good” means, which problems deserve the company’s attention at all. That’s not a thing any scheduler can do for you. It’s also, conveniently, the only part that ever deserved your full attention.

The batch machine in 1959 ran without you and didn’t need to be asked. We spent forty years teaching software to wait, because for forty years it had to. It doesn’t anymore.

---

We’re building that correction at Apollo Space, an operating system for your company that watches, notices, and speaks first, so the work stops waiting on you to remember it. If you’ve spent your career being the trigger, it might be time to be the founder again.