VISPAICO Journal — Issue 002

In the 1920s, a factory did not buy electricity the way it had once bought steam. It bought a connection. The generator, the distribution, the actual production of power — all of that was outsourced to a utility that specialised in nothing else. What the factory owner received was current, delivered through a wire, metered by the month.

This seems obvious now. It was not obvious then. For nearly two decades after Edison's first commercial grid, most large manufacturers still ran their own private generators on-site, because that was how power had always worked: you owned the machine that made the thing you needed. The idea that a company could simply subscribe to a capability, rather than build and operate it, took an entire generation to become common sense.

Software is having its own quiet version of that transition, and almost nobody has named it correctly. The assumption still governing most executive thinking is that software is something a company acquires — licensed, subscribed to, occasionally custom-built by a vendor who understands code in a way the client never will. This assumption made sense for fifty years. It is becoming wrong in front of us.

The Category Error

Ask a manufacturing COO what software her company uses, and she will list an ERP system, a CRM, perhaps a scheduling tool from a specialist vendor. Ask her what her business actually knows — the sequence in which machines must be recalibrated after a changeover, the informal rule that certain suppliers need a two-week buffer during monsoon season, the exact conditions under which a batch gets flagged for secondary inspection — and she will describe something that lives nowhere in that list. It lives in a shift supervisor's head, in a laminated sheet taped to a wall, in the memory of whoever has been doing this job the longest.

That second list is also software. It is simply software that has never been written down in a form a machine could run. It is a set of rules, conditions, and decision logic, executed faithfully, day after day, by a human being acting as the interpreter.

This is the category error at the heart of how most executives think about technology: they believe software is what you buy from a vendor, and everything else is "just how we do things around here." But "how we do things around here" is, in every meaningful sense, an unwritten program. It has inputs. It has conditional logic. It has a defined output. The only thing missing is a runtime that isn't a person.

What is changing now is that AI can serve as that runtime — not by replacing the judgment embedded in the process, but by finally giving it a place to live outside a single employee's memory.

The Law Firm That Had No Developers

Consider a mid-sized law firm — eighty lawyers, no engineering department, nothing resembling a technology function beyond an IT administrator who manages email and printers. For decades, this firm's most valuable asset was never its case law research. It was the accumulated judgment of its senior partners: which clauses in a contract are genuinely dangerous versus merely unusual, which opposing counsel tend to negotiate in good faith, which types of disputes settle quickly and which drag on for years regardless of merit.

This judgment was never written down as a program, because nobody in the building knew how to write programs. It existed the way most professional expertise exists: as tacit knowledge, transferred slowly through years of apprenticeship, associate to partner, over long lunches and late-night document reviews.

Today, that same firm can describe its own judgment in plain language — the actual conditions a senior partner would apply when reviewing a clause — and have that judgment become something an AI system can apply consistently, at any hour, to any document, without the founding partner needing to review it personally. Nobody wrote a line of code. Nobody hired an engineer. The firm did not buy a legal-tech product in the traditional sense; it converted institutional judgment into something operational — something that behaves, for the first time, like software rather than like a habit confined to a handful of people's memory.

This is not automation of legal work. It is the externalisation of legal reasoning that used to exist only inside specific, mortal, occasionally unavailable people.

Logistics Without a Line of Code

Freight logistics has always been an industry run on exception-handling. The plan is never the interesting part; any dispatcher can route a truck under normal conditions. What separates a good logistics operation from a mediocre one is how it handles the moment the plan breaks — a delayed shipment, a customs hold, a driver who calls in sick two hours before a pickup.

For most mid-sized logistics companies, this exception-handling has always lived in the heads of a small number of senior dispatchers, the people everyone calls when something goes wrong, because they carry years of accumulated pattern-recognition that has never been formalised into a manual. Ask them why they made a particular call and they will often say something close to "it just felt right based on what usually happens" — which is a perfectly reasonable description of judgment, and a completely unusable one for training a replacement.

What is now possible is something that would have sounded like science fiction a decade ago and sounds almost mundane today: capturing the reasoning behind hundreds of those exception decisions, and turning that accumulated pattern into a system that can propose the same judgment the next time a similar exception occurs — checked, adjusted, and ultimately still approved by a human, but no longer entirely dependent on that human being awake, available, and in the building.

The company has not purchased a logistics platform. It has converted its own operational memory into something resembling software — bespoke, unglamorous, built from nothing but the accumulated judgment already sitting inside the business.

Healthcare's Oldest Problem, Solved Differently

Healthcare has spent a century trying to solve a version of this same problem: how do you take the judgment of an excellent clinician and make it available to every clinician, not just the gifted few? Medicine's traditional answer was standardisation — clinical guidelines, protocols, continuing education, all designed to convert individual expertise into shared practice.

This worked, but slowly, and with an inherent lag. A senior physician's refined intuition about which patients presenting with ambiguous symptoms warrant urgent escalation might take fifteen years to fully transmit to a resident through observation and mentorship — if it transmits at all before that physician retires.

What changes now is not that AI diagnoses patients — a claim that deserves exactly the scepticism most executives already bring to it. What changes is that the pattern-recognition embedded in decades of a clinical team's actual decisions — not textbook cases, but this hospital's own history of what worked and what didn't — can be captured and made available as a second opinion, instantly, to every clinician on staff, including the newest resident on their first overnight shift.

The hospital has not bought a diagnostic tool from a vendor. It has taken its own accumulated clinical judgment — previously locked inside specific senior clinicians — and turned it into an operational resource the entire institution can draw on. That is software, in every sense that matters, built entirely from what the organisation already knew.

Consulting's Uncomfortable Mirror

Nowhere is this shift more uncomfortable to confront than in consulting, an industry whose entire business model has historically depended on the scarcity of judgment. A consulting firm sells the accumulated pattern-recognition of its senior partners — the ability to look at a client's situation and say, correctly, "I have seen this exact problem four times before, and here is what actually works" — packaged, billed by the hour, and delivered through a small number of people whose time is deliberately kept scarce.

But that pattern-recognition, like the law firm's contract judgment and the logistics company's exception-handling, is not magic. It is a structured way of reasoning about a bounded set of situations, refined over years. And structured reasoning, once it can be articulated, can be captured — not perfectly, not without oversight, but well enough to change who has access to a firm's best thinking and how quickly.

The uncomfortable implication is not that consultants become obsolete. It is that the firms who move first to convert their own accumulated judgment into something operational — something junior staff and even clients can draw on directly — will offer something structurally different from firms still selling access to a handful of scarce, expensive people. The firm's true asset was never the partners themselves. It was what the partners knew. And what people know can now, for the first time, be separated from their calendars.

The New Definition

Put these examples side by side — a law firm, a logistics company, a hospital, a consultancy — and a pattern emerges that has nothing to do with any single industry. In every case, the business already possessed real intelligence. It simply stored that intelligence in the least durable, least scalable format available: individual human memory, transferred slowly, unevenly, and at risk of walking out the door at any time.

What changes now is the definition of software itself. For fifty years, software meant a product built by engineers, sold by vendors, and adopted by companies who had no part in its creation beyond configuring a few settings. That definition is quietly becoming obsolete. Software, increasingly, is simply an organisation's own accumulated judgment, made operational — describable in plain language, refined through use, owned by the business that built it rather than licensed from a company that built it for someone else.

This is a genuinely strategic shift, not a technical one, and it is why executives should resist the temptation to delegate this question to an IT department. The distinction between "companies that use software" and "companies that are becoming software" is not a distinction about technical sophistication. It is a distinction about which companies have taken the trouble to make their own judgment explicit, and which companies still keep it locked inside a small number of people who could, at any point, leave.

What This Means for the Next Decade

The factories that clung longest to their private generators were not stupid. They had made a rational bet, decades earlier, that owning the machine was safer than depending on someone else's wire. It took the obvious, compounding economics of the shared grid to prove that bet wrong, and it took a generation for the change to feel inevitable rather than radical.

Companies today are making an equally rational, equally outdated bet: that their judgment is safest kept where it has always been kept — in the minds of their most experienced people, transferred slowly, informally, imperfectly. This was, for a very long time, the only option available. It no longer is.

The businesses that recognise this first will not necessarily be the ones with the largest technology budgets. They will be the ones willing to treat their own accumulated judgment — however uncodified, however invisible, however deeply embedded in a handful of veteran employees — as an asset worth making explicit. Not to replace those employees. To ensure that what they know does not remain, indefinitely, a private and perishable thing.

Every company already runs on something that functions like software. The only question left is whether it stays locked inside people, or finally becomes something the business itself can own.

Every Company Is Now a Software Company (Even Without Engineers)