Spreadsheets occupy a strange place in the world of software. They’re not thought of as programming languages, yet an enormous amount of real business logic lives inside them. Financial forecasts, operational planning, reporting pipelines, and entire budgeting systems are frequently nothing more than layers of formulas stacked on top of each other in Excel or Google Sheets.
At the same time, spreadsheets are among the most productive tools ever created. You can take a vague idea, open a blank sheet, and within minutes have something that resembles a working model. That combination of power and accessibility is rare.
Recently I realized that spreadsheets share some of the same strengths – and weaknesses – as large language models.
Both tools are great for prototyping. And both tools become problematic when people quietly start treating the prototype as the final system.
Exploration Without Structure
What makes spreadsheets so effective is that they let you defer structure. Instead of designing a system ahead of time, you can just start experimenting.
You type in some numbers, write a formula, add a few rows, maybe another sheet. As you work, the model gradually takes shape. You discover which variables matter, what relationships exist, and the kinds of calculations that are required.
Large language models enable a similar workflow. Instead of carefully designing a system, you prompt the model and see what happens. Sometimes you get something functional, sometimes not.
In both cases the barrier to experimentation is extremely low. That immediacy makes these tools sometimes extraordinarily useful when you’re still trying to understand the problem itself.
The Gradual Mess
Spreadsheets almost always begin in a clean state. The original author understands the structure, the formulas are simple, and everything is easy to follow.
Then the spreadsheet survives longer than anyone expected.
A new column gets added for a slightly different metric. Another sheet references the first one. Someone copies a formula but forgets to update a range. Eventually a few cells start containing manual overrides because it was the fastest way to correct something.
Months or years later the spreadsheet has become a small ecosystem. Some cells contain formulas, some contain constants, and some contain formulas that depend on constants that used to be formulas. A few critical numbers may depend on chains of references that stretch across multiple sheets.
At that point the spreadsheet still works, but understanding it requires a kind of archaeological effort. The same problem plagues LLM-produced code. Even when it works, no human has been burdened with understanding it.
Organic growth is wonderful during exploration. It is much less wonderful during maintenance.
When Structure Should Appear
Spreadsheets are at their best when you’re figuring out a model. They allow you to explore the space quickly and discover what the underlying structure actually is. After a while, though, that structure usually becomes clear. You can see what the entities are, what relationships exist between them, and what transformations need to happen to the data.
In other words, the data model has emerged.
That is usually the point where the spreadsheet has already done its most valuable work. Once the model is understood, the sensible, often ignored next step is to make the structure explicit and build a system around it.
That system might be a small application, a database-backed tool, or even a simple script that processes structured input. The exact technology isn’t important. What matters is that the logic stops being hidden inside a grid of cells and instead becomes something that can be read, versioned, and maintained.
This is the same transition that many teams will likely soon need to make with LLM-driven workflows and codebases. LLMs can help in discovering what the workflow should look like. But once the workflow stabilizes, the structure should move into crafted code and well-defined data models, allowing a developer to rationalize, document and secure the system.
When the Spreadsheet Is the System
Of course, in practice many spreadsheets never get replaced. They are embedded in workflows, relied upon by teams, and “good enough” that nobody wants to invest time in rebuilding them. Perhaps the use case is too small to merit any further development.
When that happens, the best option is to at least impose some discipline on the spreadsheet itself. Here’s a two things you can do with a spreadsheet and one you can do on a LLM-generated codebase.
Access Control
When a spreadsheet becomes a legitimate, solidified part of business, it needs to be treated with the same respect as other business practices – including control over who has access to what. Most modern spreadsheets allow varying levels of access control, to the file itself, or a specific sheet, or even more granular to limit access to certain cells to specific people.
Prevent User Errors
Many spreadsheet tools allow you to lock cells that contain formulas so they cannot be edited accidentally. You can separate inputs from calculations so that users only interact with clearly defined areas. Named ranges can replace fragile positional references, making formulas easier to read and less likely to break when rows move around.
Input validation can prevent impossible values from appearing in key cells. Sheets can be protected so that only specific parts remain editable. Even simple documentation inside the spreadsheet can make a large difference when someone new tries to understand how it works.
None of this transforms a spreadsheet into a perfectly engineered system, but it reduces the probability that a single accidental edit silently corrupts the logic.
How to mitigate a vibe coded system / LLM-generated codebase
Have a professional rewrite it.
The Lesson
The similarity between spreadsheets and LLMs is that both allow you to postpone formal structure. They let you build first and understand later.
That capability is valuable. Many problems are easier to solve once you have experimented with them. But experimentation is only the first phase of engineering.
At some point the structure that was discovered during exploration needs to be made explicit. Data models need to be defined, rules need to be encoded clearly, and the system needs to be understandable by someone who wasn’t present when it was first created.
Prototypes that accidentally become production systems have a habit of turning maintenance into archaeology.
In case that feels painfully familiar, my business, Out of the Box Software, specializes in this type of archaeology and stabilization and salvage of rapid-prototyped and obsoleted systems.
Leave a Reply