Couldn't this be a spreadsheet?
Building used to be expensive, so the existence of software was evidence somebody needed it. That evidence is gone.
There's a question I ask in roughly half my engagements now, usually while someone is showing me a custom internal tool with auth, a database, a deploy pipeline, and an AI feature. The question is in the title. The answer, more than half the time, is yes, and everyone in the room privately knows it.
What vibe-coding actually changed
It didn't just make building faster. It deleted the filter. When software cost months, the cost itself did the prioritization: only problems that hurt enough to justify months got built. Plenty of good ideas died at that filter, but so did nearly all the bad ones. Now an enthusiastic person with an AI assistant can stand up a working app in an afternoon, which means the act of building no longer proves the thing deserved to exist. The filter has to move somewhere else, and in most teams it hasn't moved anywhere. It's just gone.
The result is a new genre of organizational debt: the vibe-built tool. It works, mostly. Its author understands it, mostly. It has no tests, no owner of record, and no answer to "what happens when the person who prompted it into existence leaves." Teams used to accumulate one haunted spreadsheet per department. They're now accumulating haunted applications, which are worse, because at least everyone can open a spreadsheet.
The null hypothesis
So the question isn't rhetorical contempt. It's a test with content. A spreadsheet is the minimum viable system: data, formulas, and a person, with nothing else to maintain. Treating it as the null hypothesis forces the real question, which is what specifically about this problem the minimum system can't do.
Every system you don't build is maintenance you don't owe.
There are honest answers. Multiple people writing at once. Permissions, because not everyone should see everything. Volume past what a file survives. Integrations that have to fire without a human pressing anything. An audit trail a regulator would accept. When one of those is true, build the system, and build it to close a real leak. When none of them is true, the app is a costume. The spreadsheet version isn't a compromise, it's the correct engineering: legible to its operator, editable without a deploy, debuggable by the person who actually understands the process.
The order of operations
Even when the answer is "no, this genuinely needs software," the spreadsheet usually comes first anyway. Run the process in a sheet for a month and you learn what the real fields are, where the exceptions live, which steps a human refuses to give up. The spreadsheet is the spec, and a spec you ran is worth ten you wrote. The expensive failure mode is inverting this: vibe-coding the application first, discovering the process inside it was wrong, and now owning both a wrong process and a codebase that encodes it.
For the people who like building
None of this is an argument against the joy of making things, and AI-assisted building for the pleasure of it needs no defense. It's an argument about production: anything other people's work will depend on. There, the discipline that used to be enforced by cost has to be enforced on purpose, by someone willing to ask the annoying question before the fun starts. Cheap building didn't make judgment obsolete. It made judgment the only scarce input left.