Key Takeaways: The AI revolution and the spreadsheet revolution share the same pattern: a powerful tool lowers the barrier to creation, and the result is a generation of unmaintainable artefacts built by people who are not software engineers. Vibe coding is today’s VBA. It produces working results fast, and terrible maintenance problems later. The answer is not to reject the tool; it’s to build the engineering discipline around it that the tool itself won’t provide.
In the early 1990s, something remarkable happened in every office on the planet. A tool arrived that let non-technical people build genuinely complex logic without writing “real” software. Accountants built amortisation models. Operations managers built scheduling tools. Sales teams built commission calculators. All of it in Excel, most of it held together with formulas, named ranges, and eventually, inevitably, VBA.
It worked. It was fast. It was empowering. And it created a maintenance debt that organisations are still paying off thirty years later.
The AI moment feels different. But it rhymes.
What the Excel Revolution Actually Was
Before Excel, building a financial modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… required either a developer or a specialist in tools like Lotus 1-2-3. The calculation was in the software. The logic was in the code. Changing it required a technical person.
Excel collapsed that gap. The logic moved into the spreadsheet itself, where the person closest to the business problem could define it directly. This was genuinely transformative: faster iteration, lower cost, more relevant output.
But it came with a catch no one talked about at the time.
Spreadsheets don’t have version control. They don’t have test suites. They don’t enforce separation of concerns. The person who built the modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… is the only one who understands it, and once they leave, the modelA mathematical function trained on data that maps inputs to outputs. In ML, a model is the artifact produced after training — it encapsulates learned patterns and is used to make predictions or… becomes archaeology. The VBA macro that calculates monthly commissions across twelve sheets using three global variables and a GoTo statement? Nobody touches it. Nobody dares.
The tool democratised creation. It didn’t democratise maintenance.
Vibe Coding Is the New VBA
Vibe coding, the practice of describing what you want in natural language and having an AI generate the code, is the most exciting productivity shift in software development in a decade. A junior developer can scaffold a working API in an afternoon. A non-engineer can build a data pipelineAn automated sequence of steps that ingests, transforms, validates, and delivers data for training or inference. Data pipelines ensure consistent, repeatable data preparation and are foundational to… by describing it in plain English. The barrier to producing something that works has never been lower.
This is exactly what Excel felt like in 1993.
The VBA parallel is precise, not rhetorical. Consider what vibe coding and VBA have in common:
The output is real, working logic. VBA macros ran. They calculated things correctly. AI-generated code runs. It passes the test. The “working” bar is cleared easily.
The process is opaque. A VBA macro written by an accountant who learned from a YouTube tutorial doesn’t follow software engineering conventions. There are no abstractions, no separation of concerns, no meaningful variable names. AI-generated code has the same tendency, especially when prompted by someone who doesn’t know what good code looks like.
Ownership is unclear. Who owns the spreadsheet? Whoever built it, and often no one else understands it. Who owns the AI-generated module? The developer who prompted it, and they may not fully understand the output either.
It accumulates. One VBA macro is manageable. Fifty interlocking macros with shared state is a system no one can reason about. One AI-generated featureAn individual measurable property or characteristic of the data used as input to a model. Feature engineering — selecting, transforming, and creating features — is a critical step in the ML pipeline. is fine. A codebase where every featureAn individual measurable property or characteristic of the data used as input to a model. Feature engineering — selecting, transforming, and creating features — is a critical step in the ML pipeline. was vibe-coded by a different person over eighteen months is a different kind of problem entirely.
The Part Nobody Warned About in 1993
The productivity gains from Excel were real. The complaints about “spreadsheet chaos” came later, much later, when organisations tried to audit, migrate, or replace systems that had grown from one sheet into forty connected workbooks maintained by people who had since left the company.
The pattern runs like this: the tool is adopted bottom-up because it solves real problems fast. Engineering governance is bypassed because the tool feels like “not really software.” The people who understand the artefacts become irreplaceable. When they leave, the organisation either freezes the system or spends disproportionate effort reverse-engineering it.
Vibe coding is following the same adoption curve. Teams are shipping faster. Product managers are building prototypes without engineering resources. Startups are reaching MVP with half the headcount. All of this is real.
The audit is coming. It always does.
The Right Response Is Not to Slow Down
The lesson from the spreadsheet era is not “Excel was a mistake.” It’s that the organisations that got the most from Excel were the ones that built discipline around it: naming conventions, version control (yes, even for spreadsheets), designated owners, documentation standards.
The discipline lagged the tool by roughly a decade. That lag was expensive.
With AI-assisted development, the window to build the right habits is now, before the codebase fills up with generated code that no one owns and no one understands.
Concretely, this means:
Treat AI-generated code as a first draft, not a deliverable. The output needs review by someone who understands what it’s doing. “It works” is not the same as “it’s correct, maintainable, and consistent with the rest of the system.”
Don’t bypass the engineering process. Code review, testing, documentation: these matter more for AI-generated code, not less. The generator doesn’t know your conventions. The reviewer does.
Preserve ownership. Someone on the team needs to understand every module well enough to change it safely. If that’s not true, the module is already a liability.
Be honest about what vibe coding is good for. Prototyping, exploration, scaffolding, automating repetitive patterns: excellent. Core business logic that will need to evolve over years: that’s where the VBA macro problem lives.
The Analogy Has a Limit
The Excel revolution produced enormous value despite the maintenance debt. The organisations that were most damaged were the ones that never treated spreadsheet logic as real software. The ones that did, that versioned it, tested it, documented it, owned it, got the productivity gains without proportional debt.
AI-assisted development can go the same way. The tool is genuinely powerful. The question is whether the engineering culture around it matures faster than the debt accumulates.
In 1993, that question took thirty years to answer. We have a shorter window this time, and the stakes are higher, because the output is production software, not a spreadsheet.
Build fast. But build like someone else will have to maintain it. Because they will.