Last week, a16z General Partner Andrew Chen kicked off one of those debates that only the internet can deliver: a million-view argument about whether AI will kill the spreadsheet. His thesis was clean: spreadsheets are business logic trapped in a grid, AI code generation collapses the barrier that kept people there, and a billion spreadsheet users are about to become a billion micro-app builders.
Hundreds of replies piled in. Finance veterans swore on their Thinkpads that Excel would outlive us all. Engineers wondered why anyone still uses VLOOKUP when Python exists. And a few sharp observers pointed out that both sides might be arguing about the wrong thing entirely.
I think they're right. The spreadsheet debate isn't really about spreadsheets. It's about where your data lives, and who (or what) can use it.
Andrew Chen's Argument: Spreadsheets Are Business Logic in the Wrong Format
Chen's structural argument is hard to argue with. Spreadsheets have no version control, no testing framework, no modularity. They're brittle. One inserted row can break a cascade of cell references that took weeks to build. Every organization has a "mission-critical" spreadsheet that nobody fully understands, maintained by one person who might leave next quarter.
And his barrier-to-entry point is real. The reason a finance analyst builds in Excel instead of Python has always been the learning curve, not some inherent superiority of the grid. If AI code generation compresses that curve to near zero, the gravitational pull of the spreadsheet weakens.
Where I think he's directionally right: the "shadow IT" spreadsheet that runs half the company's operations is genuinely dangerous infrastructure. It's unversioned, untested, and invisible to the people who are supposed to manage risk. Something has to change.
Why Spreadsheet Defenders Have a Point
But the pushback wasn't just nostalgia. Some of it was genuinely sharp.
Spreadsheets as a Thinking Tool
The strongest counterargument came from Robert L. Peters, who made a point most technologists miss entirely: the spreadsheet isn't just where you store your conclusion. It's where you arrive at your conclusion. Building a financial model forces you to articulate every assumption. You discover what you don't know by trying to fill in cells. You develop conviction about your inputs by manipulating them directly and watching the downstream effects.
That's not a software problem. That's a cognitive process. And "describe what you want to an LLM" skips the most valuable part.
The Auditability Problem With AI-Generated Code
Peters also dropped the line of the thread: "95% right is 0% useful." In front-office finance, a single miscalculation can cost a billion dollars. In a spreadsheet, you can trace every number back to its source. In a vibe-coded Python app, you're trusting that the AI correctly interpreted your intent and implemented it without error. For a marketing tracker, that's fine. For a leveraged buyout model, that's malpractice.
Two Kinds of Spreadsheet Use
Dan Hockenmaier offered an important segmentation: there are really two kinds of spreadsheet use. The "mini software" kind (dashboards, trackers, attribution models) is ripe for replacement. But the "thinking tool" kind (financial models, scenario planning, ROI analysis) is stickier, because the process of building it is the product.
The Grid Is the Interface
Richard Pham made the interface argument: the grid isn't a limitation, it's the feature. Humans need spatial, parallel visibility into structured data. You can scan 50 rows and 12 columns simultaneously and spot an anomaly that a sequential chat interface would never surface.
These aren't minor objections. They're fundamental.
What Both Sides Miss: AI Agents Need Structured Data, Not Spreadsheets
Here's what strikes me about the entire thread: it's framed as a debate between humans using spreadsheets and humans using code. Nobody asks the more important question: what happens when the primary consumer of your data isn't a human at all?
But before we get there, it's worth stating something obvious that the entire debate dances around without ever saying directly: spreadsheets aren't databases. They have no enforced schema, no relational integrity, no real query language. A column can silently shift from numbers to text to dates and nothing breaks until everything breaks. There's no concept of a primary key, a foreign key, or a join. Every "spreadsheet as system of record" is really a database pretending to be a document, with none of the guarantees that make databases reliable.
This matters because the debate keeps comparing spreadsheets to code, as if the only choice is between a grid and a Python script. But the deeper issue is that organizations are using a presentation format as a data management layer. It's like debating whether a Word doc or a text file is a better way to run a relational database. The answer is neither, because that was never what those tools were for.
Once you see it that way, the agent question becomes unavoidable. We're entering an era where AI agents are making decisions, routing workflows, synthesizing information, and taking action across systems. Those agents need structured data they can query, reason over, and act on. And spreadsheets, which were never databases to begin with, are terrible infrastructure for that.
An .xlsx file sitting in someone's Google Drive is invisible to an agent. It has no API. It has no schema. It has no query interface. It's a locked box that only a human with the right permissions and the right mental model can open and interpret.
This is the real disruption. Not that humans will stop wanting grids, but that the data trapped in those grids needs to be liberated for a new class of consumer. The agent layer doesn't care about your pivot table formatting. It needs structured, queryable, API-accessible data.
The "shadow IT" problem Chen identifies isn't just a governance risk. It's an AI readiness problem. Every spreadsheet that runs a critical business process is a data silo that your AI stack can't touch.
The Future of Spreadsheets: From Files to Structured Data Layers
So here's where I think the future actually lands.
Spreadsheets don't die. But their role narrows. They retain the personal, exploratory, thinking-tool use cases that Peters and Hockenmaier defend: the ad-hoc analysis, the early-stage model where the process of building it is the point, the quick-and-dirty list that doesn't need infrastructure.
What spreadsheets lose is everything collaborative at scale, everything that feeds into automated workflows, everything an agent needs to consume, and every operational system masquerading as a flat file.
The transition isn't spreadsheets to code. It's spreadsheets to structured data layers with multiple interfaces on top. The grid might survive as one of those interfaces. But the .xlsx file as the system of record is what's actually dying.
Chen almost gets here when he says the grid might become "more of a display" with a database underneath and apps built on top. That's the right intuition. But he frames it as a code generation story when it's really a data architecture story.
How Alani Insights Fits Into This Shift
This is the thesis behind Alani Insights.
We didn't set out to replace anyone's spreadsheet. We set out to solve a different problem: organizations have critical knowledge and operational data locked in formats that humans can access but AI agents can't. Spreadsheets are one of those formats. PDFs are another. Institutional knowledge trapped in people's heads is a third.
Alani Insights is an MCP-native structured data layer. It's a SQL database that AI agents can query directly through the Model Context Protocol (MCP), the emerging standard for how agents interact with data sources. Your data gets a schema, an API, and a query interface that both humans and machines can use.
But here's the thing the Peters crowd would appreciate: you can also just talk to it. Ask your data a question in plain English. Explore assumptions. Test scenarios. Develop the intuition that comes from interacting with your data directly, without needing to know SQL, and without giving up the structured infrastructure underneath.
That's the resolution of the debate, as I see it. You don't have to choose between the exploratory, intuition-building interaction that makes spreadsheets powerful and the proper infrastructure that makes data useful at scale and to agents. You can have both, but only if the underlying layer is designed for it from the start.
The Bottom Line: It's Not Excel vs. Python. It's Files vs. Layers.
I don't think the spreadsheet is going away any more than the PDF went away. But Chen is right that its dominance is ending. Not because AI code generation replaces the grid, but because the world is shifting to an architecture where data needs to be agent-ready, queryable, and structured by default.
The billion-dollar question isn't whether your team uses Excel or Python. It's whether your data is locked in files or living in a layer that both your people and your AI can actually use.
That's the transition we're in. And it's bigger than spreadsheets.
Frequently Asked Questions
Will AI replace spreadsheets entirely?
No. Spreadsheets will retain their role as personal thinking tools, including exploratory modeling, ad-hoc analysis, and quick-and-dirty lists. What AI replaces is the spreadsheet as an operational system of record. Anything collaborative at scale, feeding automated workflows, or needing to be consumed by AI agents will migrate to structured data layers.
What is a structured data layer?
A structured data layer is a database with a defined schema, API access, and query interface that both humans and AI agents can interact with. Unlike a spreadsheet file, it supports version control, programmatic access, and integration with AI tools through protocols like MCP (Model Context Protocol).
What is MCP and why does it matter for data?
The Model Context Protocol (MCP) is an emerging standard for how AI agents connect to and query external data sources. An MCP-native data layer means AI agents can access your structured data directly, without custom integrations, screen scraping, or manual exports from spreadsheets.
What's the difference between "spreadsheets as thinking tools" and "spreadsheets as software"?
Spreadsheets serve two distinct purposes. As thinking tools, they help users build financial models, test assumptions, and develop intuition. The process matters as much as the output. As software, they function as dashboards, trackers, and operational systems, where the output is the point. AI is most likely to replace the second category first.
Ready to put your information to work?
Pick a product. Start free or talk to our team.