The current conversation about AI and business is loud. It’s technically literate. It’s driven by engineers. And it runs on a familiar promise: engineers will use AI to build amazing products. Businesses will buy those products and reap the benefits.
For most of my 35 years in Silicon Valley, I bought this narrative too — it was the only one available. I’m an engineer. I’m bullish on AI. I spend most of my days in the AI prompt. And from where I stand now, I see things at a slightly different angle.
Sticks, Matches, and 16 Kilobytes of Core Memory
Let me take you back to a time before software engineering existed as a profession.
In April 1964, IBM announced the System/360. It was too expensive to buy, even for the largest corporations, so they leased instead. Smaller companies bought computing time from service bureaus. The pattern should sound familiar. Today, very few companies run their own AI models. The infrastructure is too expensive, the expertise too specialized. Everyone else rents access — the same way businesses in the 1960s did. And the interface mirrors, too: back then, you sat down at a terminal, typed commands, and waited for the mainframe to respond. Today, you open a chat window, type a prompt, and wait for the model to respond. Terminal session then, chat session now.
Nobody had a computer at home. Not meaningfully until the IBM PC in 1981. For the first two decades of commercial computing, if you wanted to automate something, you did it on your employer’s machine.
And here’s the part that matters for this story: there was no such thing as a “software engineer” in that era. The discipline didn’t exist. Universities weren’t teaching it. The term “software engineering” itself was coined at a NATO conference in 1968, and it would take another decade before it meant anything resembling a standardized profession.
So who was writing the code?
Business people. Accountants who figured out they could automate payroll. Actuaries who wrote their own statistical programs. COBOL was designed in 1959 specifically to let them describe business logic to computers in something resembling English.
In 1953, American Airlines president C.R. Smith met IBM salesman R. Blair Smith on a flight from Los Angeles to New York. Their conversation eventually produced SABRE — the first computerized airline reservation system. To staff the project, IBM and American didn’t hire any programmers. There weren’t any. They administered IBM’s aptitude test to 650 applicants from American’s own reservations department — and trained the ones who passed.
The people who built SABRE weren’t software engineers. They were reservation clerks — domain experts — who’d learned to code.
Business people were writing their own code everywhere. In banks, in insurance companies, in manufacturing. By today’s standards, they were building with sticks and matches. System/360 started with as little as 16KB of RAM, and these machines ran payroll, inventory, general ledger, and the earliest forms of what we’d now call ERP, for companies employing tens of thousands of people. Each program was a miracle of thoughtful design, built by people who understood the business problem intimately because they lived it every day.
The software was intended for gradual business improvement. Not transforming operations end-to-end. Not bending the business to fit a packaged product. Someone saw the friction and fixed it — one process at a time. An accountant automated payroll to match her company’s actual pay structure, departments, and exceptions — and her monthly close went from weeks to days. A bookkeeper built a ledger system that perfectly matched the company’s chart of accounts — and eliminated two weeks of manual reconciliation a month.
Business people understood the problem, learned the tool, and improved their businesses. Engineers worked for IBM.
When a Book and a PC Were Enough
By the mid-1980s, a second wave of business automation arrived — this time reaching smaller companies. It was driven by cheap PCs and a family of xBase database tools: dBASE, FoxBASE, and Clipper. The latter was my personal favorite at the time — a fully compiled language with extensible grammar, so your code ended up reading like plain English. Curious about the details? Chat with my AI twin — we share memories.
These tools were simple and revolutionary. They let business experts build database-backed PC applications: inventory systems, customer trackers, accounting packages, point-of-sale terminals.
The result was an explosion of small business automation. Thousands of independent consultants, many of them domain experts who’d picked up xBase, built custom systems for dentists, auto repair shops, law firms, distributors, construction companies. They weren’t software engineers. They were accountants, office managers, or shop owners who’d picked up a book and realized they could fix their own workflows.
The xBase market collapsed in the early 1990s. Businesses were moving to Windows, to client-server architecture, to SQL databases running on servers. xBase was built for the single-user DOS world. The tools couldn’t keep up with the platform shift.
xBase died. And with it, died the idea that a business person could build real automation alone. From then on, they’d call a software engineer.
The Long Exile of the Domain Expert
Since that time, software has grown too big for one person. Building it took multiple specializations: frontend, backend, databases, infrastructure, mobile. And with that, everything about business automation changed as well.
The domain expert — the person who actually understood the business — could no longer be the one building the automation. You can’t be a master of insurance underwriting and a master of microservices and a master of user interface design. The business person had to step back and become something new: a requirements writer. A product manager. Someone who described what needed to be built, then handed that description to engineers who actually built the software.
Small improvements stopped. They weren’t worth the cost of mobilizing an engineering team. Instead, you got ERP implementations, SaaS transitions, six-month integration projects, multi-year digital transformations.
Those big projects often missed the mark. Engineers are experts in their own field. Give them requirements, and they’ll fill the gaps leaning on their own software common sense — formed by years of working with code, but very different from business common sense. The result: software that doesn’t quite fit, missed deadlines, blown budgets, canceled projects. I covered one such failure in an earlier post — the FBI’s $170 million Virtual Case File disaster.
Why not just hand engineers a complete, gap-free specification that leaves no room for interpretation? Because it’s a naive fantasy. Every product manager learns this sooner or later: engineers won’t necessarily understand the spec as intended. Worse, enumerating every edge case upfront is mission impossible. The gaps only surface once the software ships — against real data, real users, real exceptions.
This has been the dominant model for business improvement through technology for three decades. A broken one, locking businesses out of the expertise they’ve spent years building in-house.
Can the Exile End?
And now we have AI.
The dominant AI story right now is a familiar one: engineers use AI to build products for businesses. Chatbots, copilots, voice agents, AI-powered SaaS — engineering teams ship, businesses buy. I’m not going to argue with this approach. It’s producing real tools and real value.
But there’s a second opportunity — the one I want to focus on here. Just as in the early mainframe days and then in the xBase times, businesses can (again) safely, gradually, and efficiently automate and improve their processes — using the internal domain expertise of their own people. No one knows the intricate operational details better than the people who live them — not a consulting firm that parachutes in, not a SaaS vendor.
Perhaps it’s time to resurrect a long-forgotten name: intrapreneur. Not a startup founder. Not an outsider. Someone who sees an inefficiency in their daily routine and takes it upon themselves to fix it.
And modern AI — autonomous agentic AI, specifically — can become the tool that enables this change, just like mainframes and xBase did in their day.
As things stand, outside the engineering community, agentic AI is effectively used by only the few who’ve gone out and figured it out. For intrapreneurship to take root again, two things have to come together: AI tools as business-friendly as spreadsheets, and the training to use them.
Powerful, Yes. Ready for the Bookkeeper, No.
Today’s AI is powerful, and it gets better by the day. I’m not referring to chatbots. I mean agentic tools like Claude Cowork. They analyze files, interact with various applications, browse the web, and run multi-step tasks on their own.
Even so, these tools are — to be direct — still in their infancy as a platform for non-engineers. Agentic AI works well for a user who has already built AI fluency through hours of hands-on practice. Outside of engineering, almost nobody has had a reason to put in the time. Accountants, warehouse managers, office administrators, HR coordinators, operations leads — the people who make up the bulk of any workforce — are unlikely to feel at home when they sit down with Claude or its peers.
The adoption numbers tell the same story. Anthropic reports that the vast majority of Claude Cowork use comes from outside engineering: operations, marketing, finance, legal. Sounds like the revolution is underway. Not quite. Most of it goes to drafts, decks, research summaries — what Anthropic itself calls “the work that surrounds their most critical tasks,” not the core business tasks themselves.
Here’s where the tools still have catching up to do.
The simplicity of a spreadsheet. Excel is the gold standard. A bookkeeper doesn’t need a week of training to put a number into a cell. The tool is self-evident. Agentic AI today is nowhere near that bar. It requires you to know what to say, what to avoid, which tools to enable, how to phrase the request, when to interrupt, how to verify, and how to keep the token bill from spiraling — before you get any value out of it. The tool should bend to the user, not the user to the tool.
Multi-user operation. A business rarely runs on one person. Today’s AI tools are personal: one user, one session, one context. There’s an obvious need to handle multiple people involved in a shared workflow — with proper roles, handoffs, and an audit trail.
Interfaces beyond chat. Right now, AI offers a chat window with occasional multiple-choice selections. Non-engineers need forms, spreadsheets, scrollable tables, buttons, drop-down menus, visual dashboards, approval queues, Gantt or Kanban charts, and more. Asking them to give up familiar concepts proven over decades is like dragging them into the Zork dungeon: entertaining but counterproductive.
Build as you use. Agentic AI can do more than use built-in tools — it can construct new ones on the fly. These tools should become first-class citizens in the interface, creating structure and reusability, potentially company-wide. The traditional separation of build and use phases is a legacy of software engineering, not a law of nature. Making, running, and improving a tool require no separation.
Structured memory. Every business deals with well-understood entities: customers, invoices, SKUs, routes, shifts. Storing them in flat text files, as today’s AI does, is impractical and, in many cases, prohibitive. Databases have been addressing the need for decades — no need to ditch them now. Agentic AI should access tables, treat them as its memory, construct new and adjust existing ones — without a designer at the helm.
The list continues. Security, safety, integrations, predictability, observability, and more — each a real gap, too technical to unpack here.
These aren’t small features. Individually, they’re hard engineering problems. Together, they add up to a new kind of product.
Can You Learn to Fly from a Book?
The tools are only half the equation. The other half is training — and what’s available today doesn’t come anywhere close.
Tacit knowledge. AI prompts look simple. What they control is not. Small changes in wording produce wildly different outcomes in cost, quality, and agent behavior. That kind of system can’t be learned effectively from a book or a training video — only through repetition. It’s tacit knowledge. Mainstream AI training today doesn’t offer this. Universities teach theory. Fine for AI builders; completely off the mark for operators. Online courses push prompt libraries and “magic phrases” that work until the next model update. Businesses need less theory and more “flight simulators” that build “muscle memory” — hands-on training on real tasks, guided by someone with the right intuition.
The ChatGPT fallacy. People typed prompts into ChatGPT in 2023, got useful answers, and concluded: “I’ve used ChatGPT — I know AI.” They carry that conclusion into every AI-related decision they make today. But the times have changed. Chatting with AI and trusting it with business processes are as different as riding in a taxi and flying a helicopter. The interface is the same box. The machine behind it is not. People operating on this stale model dismiss agentic AI as “just a chatbot” — and miss the opportunity entirely.
None of this is in the air today. Someone has to build the curriculum, and someone has to teach it. For more details on which skills are missing, check out my previous post, Fluent in AI? Congrats — That Was Just the Trailer.
A Window, Not a Prediction
What I’ve described so far is not a prediction. It’s a clear opportunity — actually, several opportunities stacked on top of each other. An opportunity to build autonomous AI products for businesses. An opportunity to turn the chat window into a full operational ecosystem. An opportunity to educate the businesses and the people who desperately need it — sometimes without knowing they do. And more will surface along the way, once the first few are underway. Plenty of open seats at this table — for engineers, business operators, and educators.
History doesn’t repeat itself exactly — but it tends to reveal similar patterns over and over again. What I see now is very similar to what I saw before, twice. When I open an AI tool today, I get the same exhilarating feeling I had in my teens sitting in front of a green-screen IBM 3270 terminal. Maybe that’s why this website looks like a terminal window ;)
I think we’re onto something here — potentially as big as the AI tech that underpins it. I’d love to hear your thoughts — drop me a line.
Cheers!
References
- IBM, “The IBM System/360” — announced April 7, 1964; Model 30 core memory as little as 16KB
- Engineering and Technology History Wiki, “SABRE Airline Reservation System” — 650 applicants tested from American’s reservations staff via IBM’s aptitude test
- Wikipedia, “Altair 8800” (introduced January 1975) and “IBM Personal Computer” (introduced August 12, 1981)
- Wikipedia, “COBOL” — design committee first met at The Pentagon on May 28, 1959; intended to let “managers, programmers and systems analysts communicate with any available computer”
- NATO Software Engineering Conference, Garmisch, Germany, 1968 — origin of the term “software engineering”
- Dan Eggen and Griff Witte, “The FBI’s Upgrade That Wasn’t,” Washington Post, August 18, 2006 — $170M Virtual Case File project canceled
- Anthropic, “Making Claude Cowork ready for enterprise”, April 9, 2026 — vast majority of Claude Cowork usage comes from outside engineering (operations, marketing, finance, legal); teams use it for “the work that surrounds their most critical tasks — project updates, collaboration decks, research sprints, etc.”