← Blog

Vibe Coding Is the Excel Problem All Over Again

Someone on your portfolio company’s finance team built a tool last week. They did not write a ticket. They did not ask IT. They described what they wanted to an AI, and in an afternoon they had a working app that pulls numbers, calculates a metric, and shows a clean view of the business.

It works. It looks good. People started using it.

You have seen this movie before. It was called Excel.

The pattern is not new

For thirty years the spreadsheet was the most powerful tool in the building. Anyone could open it. Anyone could build a model. Anyone could create the number that ran a department.

That was the gift and the curse. The gift was speed. A finance lead could answer a question in an hour instead of waiting six weeks for IT to build a report. The curse showed up later, when there were four hundred spreadsheets across the company, each with its own logic, its own definitions, and its own version of revenue.

PE has spent years untangling that mess. When a buyer asks how you calculate gross margin and the answer is “it depends which spreadsheet you open,” that is the Excel problem. It is the gap I wrote about in the dashboard nobody opens, where the formal system says one thing and the spreadsheet on someone’s laptop says another, and the company runs on the laptop.

Vibe coding is the same dynamic with a faster engine. Fast creation. Zero governance. Ninety days later, a pile of tools nobody can reconcile.

Why this version is worse

The Excel problem at least had a tell. A spreadsheet looked like a spreadsheet. You could open it, see the formulas, and trace where a number came from, even if it took a painful afternoon.

An AI-built tool hides the logic. It presents a polished interface and a confident number. The person who built it described what they wanted in plain language and trusted the output. They often cannot explain the calculation underneath it, because they never wrote it. The AI did.

So now you have three problems stacked on top of each other.

The tool produces numbers that feed decisions, but nobody can audit how those numbers are produced.

The person who built it has moved on to the next thing, and the tool keeps running.

The number it produces does not match the number in the official system, and nobody notices until the two land in the same meeting.

This is shadow IT with a better disguise. The old version was a database someone stood up under their desk. This version looks like a real product, which is exactly why people trust it more than they should.

Here is how it usually plays out. An analyst builds a tool to track net revenue retention because the official report takes two weeks and they need it now. The tool works. It gets shared. Within a month it is in a leadership deck. Nobody asks how it defines a renewal, or whether it counts a downgrade the same way finance does. The number becomes the number. Then quarter end arrives, finance publishes a different retention figure, and the two are off by four points. Now you are in a meeting arguing about which number is right instead of what the number means. Multiply that by every tool somebody quietly built, and you have rebuilt the exact problem PE has been paying to solve for a decade.

How fast this compounds

The speed is the part that catches operators off guard.

Excel sprawl took years to become a diligence problem because building a meaningful spreadsheet model took real effort. There was natural friction. Not many people could build the thing that ran the department.

That friction is gone. Anyone who can describe a problem can now generate a tool. The marketing analyst builds a campaign tracker. The ops manager builds a capacity model. The RevOps lead builds a pipeline forecaster. None of them talk to each other. Each tool has its own definition of an active customer, a closed deal, a unit of margin.

Inside one quarter you can go from zero AI-built tools to a dozen, each carrying its own version of the truth. The same fracture that took the spreadsheet era a decade now happens in ninety days.

And the data team usually finds out last. They get handed the reconciliation problem after it exists, which is the same dynamic behind why the data team gets blamed for messes they did not create and were never asked to prevent.

Almost nobody in PE is addressing this

Talk to operating partners about AI right now and the conversation is about adoption. Get the portfolio companies using these tools. Move faster. Cut cost. That is the right instinct and the wrong stopping point.

The governance question is barely on the agenda. Who is allowed to build a tool that touches financial data. Where does the number it produces get checked against the system of record. What happens to the tool when the person who built it leaves. How does any of this surface in diligence eighteen months from now.

These are not exotic questions. They are the same questions that should have been asked about spreadsheets in 2005. The industry learned the lesson the slow and expensive way. The opportunity now is to apply that lesson before the sprawl sets in, not after.

A buyer two years from now will ask the same follow-up they always ask. Show me how this number is produced. If the honest answer is “an AI tool one of our analysts built and we are not entirely sure how it works,” that is a discount. It reads as a company that does not control its own data, because it does not.

What light governance looks like

The wrong response is to ban it. Lock the tools down, route everything through IT, kill the speed. You would be trading a real advantage for a false sense of control, and people would build the tools anyway and just hide them. The shadow gets darker, not smaller.

The goal is the same one that runs through data governance that raises valuation. Keep the speed. Add just enough structure that the output is trustworthy and the company can explain itself. Light governance, not a committee.

A few moves get you most of the way there.

Draw a line around what the tools can touch. Let people build freely against operational and exploratory data. Put a boundary around the numbers that go to the board, feed investor reporting, or land in diligence. Inside that boundary, an AI-built tool does not get to be the source. It can present the number. It cannot define it.

Name the system of record and make tools check against it. Every important metric should have one authoritative source. An AI-built tool is allowed to pull from that source and display it. It is not allowed to invent its own version. When a tool’s number and the system of record disagree, the system of record wins, and someone investigates the gap.

Keep a simple registry. A single list of the tools people have built that touch real business data. What it does, who built it, what number it produces, where that number comes from. This sounds bureaucratic. It is one shared document, and it is the difference between knowing your exposure and discovering it during diligence.

Require a check before a tool feeds a decision. Not a six-week review. A second person confirms the tool’s number matches the authoritative source before it gets used to run anything. If it does not reconcile, it does not ship. That single gate stops most of the damage, because the failure mode is always the same. A confident number, never checked, quietly wrong.

Assign an owner when the builder moves on. A tool that runs the business cannot belong to someone who left in March. Every tool inside the boundary has a current owner who is accountable for the number being right, the same way every important metric needs an owner.

None of this slows down the analyst building a quick view of something exploratory. That is the point. You spend the governance where the risk is, which is the small set of numbers that decisions and valuations rest on, and you leave everything else fast and free.

The window is now

The spreadsheet sprawl that PE spends diligence cycles untangling did not have to happen. It happened because the tool arrived before the discipline, and by the time anyone cared, there were four hundred files and no way back.

Vibe coding is at the start of that same curve. Right now most portfolio companies have a handful of AI-built tools and a clean shot at putting light structure around them before the count gets to fifty. In a year that shot is gone.

The companies that get this right will keep the speed and stay explainable. The companies that ignore it will spend a future diligence cycle reverse-engineering tools nobody understands, defending numbers nobody can trace, and taking the discount that comes with it.

If you want to know where your portfolio companies sit on that curve today, the VCP Data Score is a fast way to see how exposed your data foundation is before a buyer does it for you.

The Excel problem cost the industry years. The vibe coding version does not have to.