Vibe coding means: you say what you want, the agent builds it, you check whether it feels right, and you move on. For a weekend prototype that is wonderful. In a company with customer data, without a concept, it is negligent.
What vibe coding is, and what it is not
The term is meant loosely, and it captures something real. The way you work with an agent is different from classic programming. Faster, more conversational, more trying things out, less planning ahead.
That is good. We work this way ourselves, in NeoCoder and in customer projects. But "I check whether it feels right" is not an acceptance process. Not for a system that triggers payments or processes patient data.
Where it gets dangerous in a company
A few things we have seen, at our place and at others.
An agent gets access to the whole repository and with it to everything in there. Configurations, keys someone checked in years ago, data in test directories. It does not need any of that, but it has it.
An agent adds a dependency it knows. Nobody checks where it comes from, who maintains it and what else it does. It works, so it stays in.
An agent solves a problem by bypassing a security check that was in the way. Not maliciously. The task was "make it run", and it runs.
And the classic: code goes to production because the agent said the tests were green. Nobody saw the tests.
Our concept in five rules
What we made of this is not complicated. It is the work of a security architect, in a form that applies to agents.
An agent only sees what it needs for its task. No full access to the repository. The architect agent defines the slice, the coding agents work inside it.
No new dependencies without approval. An agent may propose, not add. The list of allowed libraries is part of the rules, not part of its discretion.
Security checks are not negotiable. QA checks deterministically whether authentication, validation and access control are still there. An agent that removes them gets the task back, no matter how good the rest is.
No agent signs off on its own work. Build, tests, rules, duplicates, then a QA agent, then, for anything that touches data or money, a human.
Everything is logged. Which agent produced what with which context. Not as a chat, but as an artifact you can still read in a year.
What it costs
Speed. A little. An agent that only sees its slice has to ask more often. An approval for a library takes time. A human in acceptance is slower than no human.
We measured it: it costs maybe ten to fifteen percent compared to unrestrained vibe coding. In return we know what is in the system. For a bank that is not a price, it is a prerequisite.
Why we do it anyway
Because the alternative is not doing without agents. The alternative is that they get used anyway, just without rules, by developers who will not be stopped. Fact is: that is happening today in every company, whether IT management knows it or not.
So a security concept for vibe coding is not a brake. It is the condition for being able to allow it officially. And anything that is officially allowed can also be controlled.
Vibe coding without rules is, in a company, an incident that has not happened yet. With rules it is the fastest way to build software that we know. The difference is five rules and the willingness to enforce them.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by our own twin model, trained on my texts. Sometimes a stumble stays in. That is mine too.