Vibe coding is changing the economics of software development. Writing code is becoming faster, cheaper, and accessible to people who are not professional developers.
But there is a difference between generating code and shipping software.
In this article, I explore a discussion that is starting to happen in my company: what happens when a non-developer builds an application using AI and the result looks better, faster, and cheaper than what a traditional software team could deliver?
The challenge is not just the code itself. We still need to think about source control, dependencies and licensing, cybersecurity, deployment, maintenance, testing, and long-term ownership.
There is also another risk: if everyone can easily build small tools, we may end up with dozens of applications that all need to be maintained and supported.
So maybe the real question is not “Can AI build the software?”, but rather:
“How do we adapt our software engineering practices to take advantage of vibe coding without losing the safeguards that make software reliable?”
These are some of the questions we are starting to explore internally, and I’ll share what we learn along the way.
Top comments (3)
Of the items on your list, I'd solve ownership before security: every tool built by a non-developer needs a named owner and an off switch. From running a platform where non-developers build and publish apps (I'm building Mythex), the minimum that works is: code in a repo the company controls, secrets in a secrets store rather than in the code, a sign-in in front of anything with company data, and one list of what's live and who owns it. With that in place, "dozens of small apps" becomes a catalog instead of a liability. Will these tools touch production data, or work on copies?
Production data
Then I'd add one rule before any of the others: every tool gets its own database user with only the permissions it needs, never the admin connection string. Most tools only need to read a few tables and write one. If a tool goes wrong, the damage stays inside that list, and turning it off is a single revoke instead of an incident.