Who Owns What Gets Built? The Governance Gap at the Heart of Vibe Coding

Vibe coding has made it possible for anyone with domain knowledge to build software tools. Not trivial ones. Tools that process data, automate decisions, and sit inside operational workflows that teams depend on every day.

The conversation this has generated has focused largely on code quality, development speed, and whether it threatens engineering roles. These are not the most important questions for most organisations right now.

The question that matters is simpler and harder to answer. Not whether something works. Whether the person who built it truly understands what they have built.

Take security. A tool does not have to fail or leak data for a security problem to exist. The person who built it asked the AI to make it secure. But security is a set of trade-offs, not a binary outcome. Getting that balance right requires judgement and experience. It cannot be delegated to a probabilistic system and accepted at face value.

In most organisations, nobody knows what security decisions were made on their behalf, or whether those decisions were correct.

Vibe coding is not primarily a development productivity story. It is an ownership and governance story.

What the Adoption Pattern Actually Looks Like

In practice, this is how most vibe coding adoption begins.

A product manager builds a pricing tool. A finance lead builds an invoice reconciliation script. An operations manager builds a workflow automation. Each one solves a real problem. Each one saves time. Each one gets shared. And each one becomes something the team quietly relies on.

None of these went through IT. None have documentation. None were assessed for security vulnerabilities, data handling obligations, or compliance requirements. None have a named owner beyond the person who built them. And none were considered against a wider technology strategy.

The speed at which informal tools become load-bearing infrastructure is consistently underestimated. Something built on a Tuesday afternoon to solve a specific problem can become an embedded part of how a team operates within weeks. By the time anyone outside that team knows it exists, it is already relied upon.

When individual teams build their own tools in isolation, the organisation ends up with a fragmented set of capabilities that may duplicate effort, conflict with each other, or pull against what the business is actually trying to do. Nobody planned for this. It is the natural consequence of making software creation accessible without simultaneously making governance accessible.

The Governance Gap Has Three Layers

The problem vibe coding creates is not a single issue. It accumulates across three distinct dimensions, each one building on the last.

The first is ownership. Who is responsible if this tool produces a wrong output? Without a named owner, accountability diffuses. Nobody reviews it. Nobody updates it when requirements change. Nobody decommissions it when it starts to fail. The tool exists in a state of permanent informality, relied upon but unmanaged.

The second is data. What information does this tool touch, and under what obligations? GDPR, data residency requirements, and client confidentiality obligations apply regardless of how a tool was built or who built it. A vibe-coded script that processes customer records carries exactly the same regulatory weight as a formally developed system. The fact that it was assembled through natural language prompts does not change the compliance position.

The third is dependency. What breaks if this tool stops working or produces incorrect outputs? Tools that start as individual productivity aids often become critical to how a team functions without anyone making a conscious decision that this should happen. The dependency exists before the risk has been assessed.

In conventional software development, accountability is established before deployment. Somebody signs off. Somebody owns the system. Vibe coding inverts this sequence entirely. The tool exists before the accountability conversation happens.

The Accountability Inversion

Most governance frameworks assume the conversation about risk happens before deployment. Vibe coding reverses that order. The tool exists first. The questions come later, if they come at all.

But there is a further dimension that tends to get overlooked. Once the risk has been identified, who actually has the capability to assess it?

This is where who is in the driving seat becomes critical. Not everyone who vibe codes brings the same capability to what they have built. A senior developer can interrogate the output, reason about its security posture, and make a credible judgement about what is and is not safe. A product manager or finance lead who assembled something through trial and error with a language model cannot. Not through any fault of their own. They simply do not have the framework or expertise to evaluate what they have built.

Security makes this concrete. Asking an AI tool to make something secure is not the same as it being secure. Security is not a binary state. It involves trade-offs. The more controls you add, the more friction you introduce. Getting that balance right requires judgement built on experience. It cannot be fully delegated to a probabilistic system and accepted at face value. The person who built the tool by prompting an AI does not know what security decisions were made on their behalf, which ones were correct, and which ones were not.

By the time the organisation realises it needs governance, the tool is already embedded. Retrofitting ownership and compliance controls onto a system that was never designed with them in mind is substantially harder than building them in from the start.

The question is not what happens when one vibe-coded tool fails. It is what happens when a dozen of them are embedded across different functions, none documented, owned by individuals who may have already left the organisation, and relied upon by teams who do not fully understand how they work. For many organisations, this is quietly becoming reality.

What Organisations Need to Do

The organisations approaching this well are not waiting for a failure to force the governance conversation.

The first step is visibility. Running an audit of AI-assisted and vibe-coded tools already in use across teams, not as a disciplinary exercise, but as a map of current exposure. Most organisations that do this find more than they expected. Tools built months ago that have quietly become critical. Workflows that depend on something nobody formally approved. Data being processed in ways that would concern a compliance team if they knew about it.

The second is definition. Establishing clear categories of what can be built informally, by whom, under what conditions, and what requires a formal development and governance process. That line does not need to be complex. It needs to exist and be communicated.

The third is ownership as a precondition. If a tool is going to be relied upon by more than the person who built it, it needs a named owner before deployment. Not after the first failure surfaces the need for one.

None of this requires a large programme of work. It requires a clear-eyed assessment of what already exists and a set of proportionate decisions about how to manage it going forward.

The Question Organisations Need to Ask Now

The adoption of vibe coding is not going to slow down. The question is whether the organisations using it are building the accountability frameworks to match the pace of that adoption.

Most are not yet. The ones that start now will find it considerably less expensive than the organisations that wait for a failure to make the case for them.

If you want to understand where vibe-coded and AI-assisted tools already sit across your organisation, our AI Discovery service maps that exposure and identifies where governance gaps exist.

For organisations that already have vibe-coded tools in use and want them properly audited, assessed, or rebuilt on more robust foundations, our software consultancy team works directly with that output.

The capability to move fast exists. The question is whether the governance exists to move fast responsibly.