Vibe coding in the enterprise: the freedom to create, the duty to prove
With vibe coding, everyone knows how to build an application. No one knows which one to believe anymore.
In brief
Vibe coding consists of describing a need in natural language so that an AI writes the code. No one reviews this code. It is an excellent way to prototype, not to produce. In an enterprise, a prototype becomes a reliable product under three conditions: indicators are defined collectively, the data is reference data, and a responsible party responds when the tool breaks down.
-
We prototype much faster, even without technical knowledge. But a prototype is not a product, and many think otherwise.
-
The real risk: not knowing what separates the prototype from the final product, nor how to repair the tool when it fails.
-
Not all prototypes deserve to go into production. Choices must be made.
-
And tomorrow, when AI decides more and more for us, one question will become central: how to prove what is true?
Monday, 9 AM. The Sales Director places his phone on the committee table. On it, a sales tracking application by store, with its filters, its charts, its little logo.
He made it on Sunday. In two hours. By talking to an AI.
Then he turns to the CDO: “How many months was your reporting project again?”
No one answers. The real answer is too long for a committee.
Here is that answer.
Why a vibe-coded prototype is not a product
What the Sales Director did has a name: vibe coding. You describe what you want, in plain language. The AI writes the code. You correct it by talking, without ever touching a line.
And it works. That is precisely the problem.
In one afternoon, someone who has never coded gets a tool that runs. What hasn’t been addressed is everything that comes after: connecting real data, deciding who sees what, holding up when two hundred people open it the same morning, surviving the departure of its creator. Sunday shows the facade. The construction site, however, is behind it.
Vibe coding begins the moment no one reviews the code anymore. It becomes a corporate risk the moment no one would know how to review it.
A developer who does not review makes a bet: if it breaks, they will know how to open the hood and understand what is underneath (the data used, access rights, dependencies on other tools, edge cases). A management controller who generates an application makes no bet. She sees the hood, but does not know what is underneath.
The red line is not between AI and human. It is between not reviewing and not knowing how to review.
It remains to be seen who is on each side of this line today. Hint: you are probably having lunch with some of them.
Who is doing vibe coding in the enterprise?
It is mainly business profiles already comfortable with technology and data, rather than developers. Four profiles stand out based on whether they review the code, and whether they would know how to review it.
| Level | Who | Reviews the code? | Would know how to review? |
| Assisted | A developer, with AI autocompletion | Yes, everything | Yes |
| Delegated | A developer who entrusts tasks to an AI agent | Modifications | Yes |
| Vibe expert | A technical profile in a hurry | No | Yes |
| Vibe business | A non-technical profile | No | No |
The four levels of AI usage for coding, based on code review.
We read everywhere that “everyone” is getting into it. The most cited figure comes from the platforms themselves: about 60% non-developer users at Lovable, 63% at Taskade (13labs summary, 2026). It’s a bit like asking a gym if people are exercising.
On the developer side, 72% state that vibe coding is not part of their professional work, even though almost all use AI in one way or another (Stack Overflow Developer Survey 2025). On the business side, no one really knows.
But we already know those who are truly getting into it. The forty-tab Excel file with macros that no one dares to open, the “temporary” Access database in service since 2009: it was already them. They were already tinkering. Now they tinker much faster. Add the agencies, the consultants who prototype to convince (yes, us too), and our Sunday Sales Director.
If these faces seem familiar, it’s normal: they have already played this part. And we know the ending.
From Excel macros to Vibe coding: the same cycle
Vibe coding replays the cycle of every self-service tool: autonomy, proliferation, then a governance crisis.
| Excel Macros
1990s-2000s The programmed spreadsheet |
Access Database
2000s The temporary database |
Self-service BI
2010s To each their own report |
Vibe coding
2025 We talk, it codes |
Vibe coding and self-service tools: four tools, the same cycle (autonomy, proliferation, governance crisis, then the next tool arrives).
Self-service BI is the most recent episode. We promised autonomy to business units. We got thousands of reports, many of which are no longer opened by anyone, and meetings where we debate the figure instead of debating the decision. Vibe coding is the same movie with a turbo: there isn’t even a tool to learn anymore. We talk, the AI does.
Take the sell-through rate of the spring collection. Three departments, three applications, three figures. No one lied. Each asked the AI to “calculate the sell-through rate,” and the AI chose a definition: based on initial or received stock, with or without returns, in units or in value. The calculation was correct. The meaning was missing: no one had given it, or each had given their own.
However, this story has had happy endings. Excel and self-service BI worked very well where there was a shared definition of indicators, reference data, and someone to call in case of failure. Governance is not a brake on autonomy. It is what allows it to last.
So, should we throw away the Sunday application? No. The Sales Director did something very useful that day.
Just not what he thinks.
Why a vibe-coded prototype remains useful: the toile
A vibe-coded prototype is an excellent fitting tool. It reveals the need, but it must not be put into production as is.
In high fashion, before cutting into the final fabric, the workshop assembles the garment in unbleached cotton toile. It is tried on the client, pinned, a shoulder is adjusted. Then it is set aside. No one has ever sold a toile.
The Sunday application is a toile, in other words, a prototype. And it is an excellent toile. A business user doesn’t know how to write specifications—no one really does. But everyone knows how to say “no, not like that” in front of something that runs.
Vibe coding is the best fitting tool ever invented. And the worst production tool.
The real Sunday deliverable is therefore the need that the application brought to light: the three indicators the director actually looks at, the filter added first, the one he never touched. We keep the need. We throw away the code. Making toiles is healthy. The error begins when you put them in the shop.
Code becomes disposable. What remains is the precise description of the need, and whoever owns that, owns the product. When creating becomes free, choosing becomes the job: deciding which toiles deserve to become final pieces.
Yet one must have the time to sort. Because meanwhile, the workshop continues to produce, en masse. And some toiles are already in the shop.
How to frame vibe coding: lifespan and data criticality
To frame vibe coding without banning it, we authenticate tools rather than banning them, and we modulate control based on the tool’s lifespan and the criticality of the data.
The reflex would be to close the workshop: ban vibe coding for those on the wrong side of the red line. It won’t work. We never managed to ban Excel.
Luxury knows this problem well. It’s called counterfeiting: an object that looks like the original without having the quality. And houses respond to it less by banning than by authentication: the certificate, the serial number, the chip sewn into the lining.
Transposed to data: everyone builds what they want, but only what relies on certified data carries the house label. Control moves from the workshop to the signature. Authenticating, fundamentally, is proving.
It remains to be seen what to leave free and what to frame. Two questions are enough: how long will the tool live, and what data does it touch?
Matrix: tool lifespan × data criticality.
A disposable tool on low-stakes data is a playground: total freedom. A disposable tool on sensitive data is a toile: we try under supervision, with a 90-day expiration date. A durable tool on low-stakes data becomes a piece, with a lightweight production path. A durable tool on sensitive data is not vibe-coded alone: it goes through the data team.
A lightweight production path means a named owner, a code review by someone who knows how to read it, a connection to certified data, and usage tracking. Not a six-month project: a checklist.
These rules apply for the next two or three years, as long as we are still building applications and dashboards. Because very soon, the application itself could disappear.
From dashboard to agent: who will say what is true?
Eventually, the interface disappears: you ask a question, the AI answers, then it eventually decides.
Why did the Sales Director spend his Sunday coding? To decide. That is the only reason for data to exist. The dashboard, the application, the reporting are only means, and their interface continues to shrink: yesterday, we built the dashboard; today, we ask the AI to do it; tomorrow, we will simply ask the question.
A dashboard is a road map: all the roads are on it, it’s up to you to find the right one. Talking to your data is like using a GPS. It cross-references traffic, accidents, a municipal decree you would never have read, and recommends a route. But you still have to give it the address.
Tomorrow, we will tell it: “I want the sea, and to be there in two hours.” It will choose the beach, the route, and the departure time. Transpose: “I want to sell through the collection before the end of March, without markdowns that damage the brand.” The agent will propose the destination and the path. For now, it proposes and we choose. But by dint of entrusting it with our desires rather than our addresses, it will end up choosing for us.
The day the GPS chooses the destination, it is no longer a tool. It is a decision-maker.
On that day, knowing how to code won’t be of much use. Another question will become central: who has the right to say what is true? And above all, how to prove it?
Vibe coding in the enterprise: key takeaways
A vibe-coded tool is first and foremost a prototype. It becomes a reliable product under three conditions: collectively defined indicators, reference data, and a responsible party who responds when the tool fails.
Key points
-
Vibe coding creates a prototype in a few hours, but not the production deployment or operation.
-
The red line separates not reviewing the code from not knowing how to review it.
-
The business profiles getting into it were already tinkering with Excel or Access. The same cycle repeats.
-
Without a shared definition, the AI chooses its own: three applications give three sell-through rates.
-
The cost of a tool is in its life, not its writing: maintenance, security, support.
Vibe coding significantly reduces the cost of the prototype. It does not reduce the cost of governance, which transforms a prototype into a product.
Establish your Data & AI roadmap in 15 minutes
Take our diagnostic and leave with a clear vision for your Data projects
FAQ: vibe coding in the enterprise
Creating a tool by describing a need to an AI, which writes the code. It becomes a risk for the enterprise when no one would know how to review that code anymore.
To prototype very quickly, and above all to reveal a need: in front of a tool that runs, a business user knows how to say what they want. We keep the need, we throw away the prototype.
Almost nothing to create, as much as any other tool to maintain: maintenance, security, support. But this cost comes later, without being attached to any project.
Contradictory figures from one tool to another, poorly defined access rights, maintenance without a responsible party, and dependency on the person who created the tool.
Yes, after a lightweight path: an owner, a code review, certified data, usage tracking. If it touches sensitive data and must last, it goes through the data team.
No, that doesn’t work. It’s better to authenticate: let them create, but clearly signal which tools rely on certified data.
They optimized their performance with MeltOne
