A Subway store's computer register went down on a Saturday.
Not a slow day. Not a quiet afternoon where you can hang a sign on the door. A regular, customers-are-here, transactions-need-to-happen Saturday. The kind of moment that used to trigger a very specific chain reaction.
Here is what that chain reaction used to look like:
First, the day gets worse. You scramble. You apologize to customers. You try restarting things. You call someone who calls someone. Eventually the day ends with lost revenue, frustrated staff, and a growing sense that this better not happen again.
Then the aftermath. Do we need new hardware? New software? A service contract? Let me call our IT person. Let me get a quote. Let me schedule a scoping call. Let me review the proposal. Let me sign the contract. Let me wait for implementation. Weeks pass. Maybe months. The register works again, but the cost — in time, in money, in trust — was never just about the register.
That is the old model. And it is what most businesses still default to when something breaks.
Here is what actually happened.
Steve Ginsberg had been using Claude for about two weeks. Not months. Not after an intensive training program. Two weeks of exploring what the tool could do, building his own understanding through use. When the register went down, he did not call IT. He did not open a ticket. He did not start a procurement process.
He opened Claude and described the problem.
Within ten minutes, he had built a working register replacement from a spreadsheet. He connected Square to process offline transactions. Every transaction was captured and saved to a local file. Customers got served. Revenue was not lost. The day continued.
Ten minutes. No contract. No scoping call. No vendor evaluation. No waiting.
This is not a story about technology replacing humans. Steve is very much the human in this story — he recognized the problem, knew what outcome he needed, and used the tool to get there. The technology did not decide what to build. Steve did. Claude helped him build it faster than anyone could have arrived on site to begin diagnosing the issue.
This is a story about what happens when people are empowered instead of dependent.
The old model creates dependency at every step. Something breaks, and you depend on the person who knows the system. That person depends on a schedule that accommodates your urgency alongside everyone else's. The fix depends on a contract that depends on approval that depends on budget. Every dependency adds time. Every dependency adds cost. And every dependency adds risk that the original problem compounds into something worse while you wait.
Empowerment looks different. It looks like someone who has spent two weeks building capability — not expertise, capability — using that capability in the moment it matters most. The gap between "I have a problem" and "I have a solution" collapsed from weeks to minutes. Not because the problem was trivial. Because the person was equipped.
We talk a lot about AI transformation as if it is a large-scale organizational initiative. And sometimes it is. But the real transformation happens in moments like this — a Saturday afternoon, a broken register, a person who two weeks ago did not know what Claude was, building exactly what they need because they have the capability to do it.
The question is not whether AI can do impressive things in controlled environments with prepared data and dedicated engineering teams. It can. The question is whether the people closest to the problems — the ones standing in the store when the register goes down — have the capability to act.
Steve did not need a transformation program. He needed two weeks of genuine exploration and a real problem worth solving. The activation was already complete before the register failed. The register just gave him a reason to prove it.
There is a version of this story that plays out across every business, every week. Not always a broken register. Sometimes it is a report that takes three days to build manually. Sometimes it is a process that requires four people to coordinate when one person with the right capability could handle it in an afternoon. Sometimes it is a decision that stalls because the data to support it lives in six different systems and no one has time to pull it all together.
The pattern is the same. A problem exists. A capability gap makes the problem expensive. The traditional response is to fill that gap with vendor relationships, service contracts, and implementation timelines.
The alternative is to fill it with capability.
Not everyone needs to build a register from scratch on a Saturday. But everyone deserves the opportunity to discover what they can do when the tools are accessible and the exploration is genuine. That discovery — that moment where a person realizes they can solve their own problem — is worth more than any service contract.
Steve's ten minutes saved the day. But what they really proved is that the day never needed saving. It just needed someone who was ready.