Running on the Old Map

Every company will eventually run on AI. That's not much of a prediction. You've read it a hundred times and it's probably on a slide somewhere in your building.

The number underneath it is more interesting. Building custom operational software got about a thousand times cheaper in two years. Buying tools is the small implication. The large one is that most companies are now organized wrong. Who reports to whom, which work gets a person and which gets a system, how many hands a number passes through before anyone trusts it. All of that was arranged around software being expensive. It isn't anymore.

This has happened at least twice before. Electricity reached the first commercial customers in 1882 and manufacturing productivity didn't move until the early 1920s. The microprocessor arrived in 1971 and the productivity numbers turned in 1995. Forty years, then twenty-four. The reason for the wait is the most useful thing in this essay.

The old map was right

The playbook I learned went like this. Buy software by the seat instead of building it. Keep your engineers on the product customers pay for. Handle the gaps between systems with people, because writing custom integration between two systems that don't talk costs more than paying somebody to move the numbers by hand. Let spreadsheets cover the rest.

Underneath all of it sat one assumption. Systems come as oceans.

You can see the assumption in how companies shop. A mid-sized business that needs to fix three things in its operations does not go fix three things. It runs a selection process, builds a requirements matrix, sits through six vendor demos and signs something that touches forty. That is not incompetence. It is the correct response to a world where the decision is expensive and you only make it once. You had better make it big enough to be worth the trouble.

Take an ERP implementation as the example everybody has lived through. It boils the ocean by design and the scope grows until it justifies the spend. Then it runs late and over budget.

That map was correct for its world. Custom capability really did cost a hundred thousand dollars and up, plus specialists, plus maintenance forever. A company whose board I sit on spent years building software the old way with a hired team, until the development cost turned into one of the hardest problems on its balance sheet. Nobody was being stupid. The old map said that if you were going to build, you built once and you built big. That is exactly what they did.

The price moved

Two years ago the class of internal software I now run would have cost six figures and a year of somebody else's calendar. I build it myself for a couple hundred dollars a month. I took one computer science course in college. I have never written software professionally.

The market repriced the same work at the same speed. Cursor, the AI coding tool, went from $100 million in annual revenue to roughly $4 billion in about eighteen months. The company still loses money, which is worth saying plainly. Revenue moving that fast means a lot of people are building things they weren't building before.

The cheaper price is the smaller half of it. What changed more is how small a piece of software is worth building at all.

Under the old cost you bought everything at once, because the decision was expensive and you only got to make it one time. Now the smallest thing worth building is a single annoyance that pays for itself in a week. You build that one, watch it run, then decide what comes next.

Decomposition becomes the skill that matters. Everyone talks about prompting. The harder part is cutting your company into systems small enough to build and useful enough to stand on their own.

Factories already ran this experiment

The first commercial power station opened in 1881. Electric motors made up under 5% of factory mechanical drive by 1899. A quarter of it by 1909. Just over half by 1919. Seventy-eight percent by 1929.

Now put the productivity numbers next to that. Manufacturing labor productivity grew about 1.5% a year from 1899 to 1914. Through the 1920s it ran somewhere between 3.4% and 5.1% a year depending on which year you start counting. The 5.1% version starts in 1919. That was a depressed year. Take the low end as the honest one. Even at 3.4% the decade runs at more than double the pre-war rate. And thirteen of the fourteen major manufacturing groups accelerated. No single industry is carrying that average.

Forty years of steady adoption. Then one decade that changed the country.

The reason for the wait is the part worth sitting with.

A nineteenth-century factory ran on one enormous engine. That engine turned a driveshaft that ran the length of the building near the ceiling, with every machine on the floor hanging off it by a belt. Machines were positioned by how close they needed to be to the shaft, not by the order the work happened in. Buildings went vertical to keep every floor near the power.

When electricity arrived, factories bought a large motor, pulled out the steam engine that had been sitting there for thirty years and bolted the motor onto the very same driveshaft that engine had been turning. Same belts, same building, same machines standing in the same places. The trade press called it group drive. It was a real term with real defenders.

It was also the rational choice. The defenders had numbers.

Start with speed. A 26-inch lathe needed spindle speeds running from under 2 rpm up to 225, a range of about 125 to 1. A DC motor with a rheostat gave you three or four to one. The AC induction motor was cheaper, simpler and didn't spark. It also couldn't vary speed at all. An engineer named Lozier, speaking in the discussion after a paper on exactly this problem at the Franklin Institute in 1904, said that no electrical system could ever give that range.

Then capacity. A motor bolted to a single machine has to be sized for that machine's peak load, while one motor driving a group of thirty gets sized to the average of all of them, which is why unit drive needed five to seven times the installed horsepower to do the same work.

Then engineering labor. Charles Day, who had equipped more than a hundred machines by 1904, put the cost of designing the drive at $150 per machine before you bought a motor. That is 1904 dollars. It's the actual price of the redraw.

None of that is inertia. None of it is a technology gap either. Unit drive was available the whole time. By late 1886 there were 250 Sprague motors between half a horsepower and fifteen running in American cities. By 1900 the largest electrical works in Germany ran a motor on every machine and tool. By 1904 several of the biggest American lathe builders had already redesigned thirty percent of their product line for direct motor connection, which is not something a manufacturer does for a technology nobody is asking about. The thing existed and you could buy it. In most shops it just didn't pay yet.

The speed problem got solved from an unexpected direction. Machine tools specialized. A machine built to do one job inside a narrow band never needs 125 to 1. The gearing that used to hang from the ceiling moved inside the housing. Nobody ever built the variable-speed motor those 1904 engineers said they needed. The machines changed to fit the motors instead.

What broke it open was unit drive. One motor per machine.

Once each machine carried its own power the shaft could come out. Once the shaft came out the building could change. Machines got arranged in the order the work actually flowed. Ceilings cleared, which let overhead cranes move material through the plant. Factories dropped to a single story. A breakdown stopped one machine instead of the entire floor.

The motor was a real invention. It just didn't pay until the floor plan caught up with it.1

That's the part that transfers. A general-purpose technology pays out when the organization around it gets redrawn. The redraw takes far longer than the installation and it costs more than the equipment.

Which brings us to the numbers everybody quotes now. Around 88% of organizations report using AI. About 6% get results that show up in their financials. Roughly one in ten agent pilots reaches production.

That's group drive. We bought the motor and bolted it to the shaft.

What redrawing actually looked like

For me it started with a whiteboard.

There's one in our production facility with everybody's name on it, what they're supposed to produce that day and what they actually produced. At the end of a shift somebody photographs it. The photo goes to Slack. A parser reads the photo and writes the numbers into a database.

That's the whole first tool. Nobody would call it a transformation.

Next I pulled our compliance and tracking data into the same database, which gave me every material package we hold. Those two together turned out to be worth more than either one alone, because once you can follow both material and labor through the creation of every unit you make, you get a real margin per product instead of a blended average that hides which things are actually worth building.

Sell-through data came third, through a partner API, matched against what we shipped. That shows where product is moving and how fast. It feeds demand planning and hands the sales team a list of accounts worth a call.

After that, a monthly reconciliation that relieves consumable inventory off the balance sheet as we build and sell, rather than at a quarterly guess.

Most recently, days-on-hand tracking for our non-cannabis inputs. We know how many days of cones or packaging or labels are left before a line goes down.

Every one of those started as a small annoyance. None of them was a project. Add them up and you have the operational core of an ERP, assembled in the order the business actually needed the pieces. I never implemented one. One is assembling anyway.

There is nothing special about me in that story, which is the point. All over your company right now there are people looking at a problem they have stared at for years and can finally solve themselves without a budget line or a vendor or anybody's permission. They are solving it. Little project by little project. Roughly 41% of American workers use generative AI for work while about 18% of firms officially deploy it. That gap is the whole thing. In a survey of 32,000 employees across 47 countries, nearly half the people who use AI admit using it in ways that break their own company's rules. Another 42% say they have hidden that they used it at all.

The finding that should end the argument about locking it down sits in the same survey. At companies that banned generative AI outright, 67% of employees put sensitive company information into public AI tools anyway. At companies with no policy at all, 33% did. The ban doubled the behavior it was written to prevent.

The redraw is already happening in your building. Nobody put it on the roadmap.

Why waiting gets expensive

The advantage compounds, which is what makes waiting costly rather than merely late.

Each system makes the next one cheaper. Getting the data foundation right was the expensive part, the integration and the schema and the reconciliation logic that nobody ever sees on a screen. It's finished now. Everything I build after it starts from clean inputs instead of starting over from the raw feeds.

The second effect is cost structure. Software you buy by the seat has been getting more expensive at roughly 16% a year and it doesn't stop, because every vendor's renewal is somebody else's growth target. A company that builds its own operational layer carries the overhead of a business half its size. That gap never shows up as a press release. It shows up in SG&A quarter after quarter. It decides who can afford to compete on price.

Now the uncomfortable version. A company started today gets built AI-native by default because there's no legacy anything to work around. An incumbent has to redraw while running. That's the group drive trap and it held real factories for decades for reasons that were sound at the time.

I run an incumbent. I think we're structurally disadvantaged and I don't think we're doomed. The difference is method. The old retrofit meant stopping. You tore out a working system that people depended on every day, spent a year in implementation while everybody kept doing the job on spreadsheets in the meantime, then hoped that what came back on the other side was better. Building one tool at a time doesn't ask for that. You can redraw a company while it keeps shipping. That's what makes this version survivable.

The firms that lose won't be the ones that refused. They'll be the ones still waiting for the big implementation.

The case against all of this

The argument against everything above is strong and I'd rather make it myself.

About 45% of AI-generated code contains security vulnerabilities. Experienced developers in a controlled study came out 19% slower with AI assistance while believing they'd been faster. An AI agent deleted a production database during a code freeze. And I shipped a dashboard with a permissions setting wrong, which left about twenty thousand rows readable by anyone who found the address. I caught it reviewing my own work. It is exactly the mistake the critics predict.

The honest comparison is the one nobody makes. My alternative was never a professional engineering team. It was a spreadsheet in a shared drive that half the company could edit. Something like 94% of business spreadsheets that get audited turn out to contain errors. Nobody called that a security posture.

Risk isn't one thing either. A consumer app serving millions with no security review sits in a different category from an internal reporting tool behind a login. Both deserve care. They don't deserve the same care.

The subtler failure has nothing to do with security. Change how one system handles its inputs and you can quietly break an assumption that a different system, built by a different person for a different reason two months earlier, was resting its whole output on. Nothing errors. The reports keep producing numbers and the numbers are wrong. A tool that breaks tells you it broke. This kind gets quieter instead.

A framework worth starting with

So the departments closest to a problem should own the tools that solve it. Somebody still has to own the seams, meaning the places where one team's output becomes another team's input. I went looking for the standard that covers this and there isn't one. The published AI governance frameworks assume a team with assigned roles and executive accountability, which is exactly what a tool built by one person on a Tuesday afternoon doesn't have.

So here's a starting point. I'm proposing this rather than reporting it. What I run today is thinner. The gaps between the two are where I've been bitten.

Keep one register, one row per tool, five columns.

• Owner. A named human. Not a team, not a department.
• Status. Live, paused or retired. A tool nobody turned off is worse than one nobody built.
• Tier. One of the three below.
• Why. One written sentence explaining the tier. If you can't write the sentence the tier is wrong.
• Seam. What this tool reads and who reads what it writes.

Three tiers. The tier sets how much ceremony a change costs you.

Tier one reads data and writes nothing anybody else depends on. Somebody's own analysis. Build it, log it, move on.

Tier two writes into a shared store, or a decision somebody else makes runs through it. Before it ships, one other person reads it and the seam column gets filled in for real.

Tier three touches money, compliance or customer data. Review by somebody who didn't build it, plus a tested way to turn it off and put the old number back.

Then one question, asked out loud before any change ships. Does this change what the data means to anyone downstream?

The register is bookkeeping. The question is the control. If you can't name who's downstream, you already have your answer.

Would that have caught the accounting change that broke my sell-through reporting? Only if I had filled in the seam column honestly. I hadn't.

Which is the uncomfortable part. The thing that works is a person remembering to ask who else is looking at this number. That's smaller and more human than I wanted the answer to be. It's also why I don't buy the version of this where AI eliminates everybody's job. Somebody still has to know what a number means to the person three desks away. Nobody has automated that.

The maintenance question answered itself in a way I didn't expect. These tools describe inventory sitting on a shelf in a building I am responsible for, which means that when the count is wrong somebody tells me about it that morning. Nobody has to schedule a review.

The whiteboard is still on the wall. It was never the thing to replace.

Nobody hands out the new map. It's being drawn right now by companies walking the ground, most of them small enough that you haven't heard of them. The ones still reading the old map aren't behind because they lack the technology. They're behind because they're still budgeting for a project that no longer needs to exist.