# Day 2 for vibe-coded apps: What happens after someone builds it?

By Nitzan Gindi, CEO of Cloche. Published 2026-10-08. https://cloche.dev/blog/vibe-coding-governance-day-2/

In my [last article](https://cloche.dev/blog/employees-are-building-software/), I wrote about how employees are beginning to build their own software using AI, and the questions this creates for organizations. Building something useful has become remarkably accessible, but what happens after someone builds it is still far less straightforward.

Imagine George, who works in Finance. On Tuesday, he builds an expense tracker using Claude. It takes him an afternoon, and it does exactly what his team needed. By Friday, five coworkers are using it. Nobody filed a ticket, nobody purchased new software, and nobody had to wait for a development team. It’s a good outcome, and exactly the kind of employee autonomy that AI makes possible.

But the moment George shares his tracker, it becomes more than a personal tool. Where does it actually run? Who can open it? When a coworker uses it, whose data can they access, theirs or George’s? Does anyone outside Finance know it exists? And what happens to it when George moves to another team?

I’ve come to think about this distinction as Day 1 and Day 2. Day 1 is creating the tool, something AI has made dramatically easier. Day 2 begins when other people need to use it. An application that works inside a personal AI chat is one thing. Making it available to colleagues, with the right access, security, and ownership, is another. And while employees can now create applications, automations, skills, and agents using a growing number of AI tools, most organizations are still figuring out how to manage what happens next.

A shared tool needs a few things that a personal experiment doesn’t. It needs somewhere to run that the organization can control, rather than depending entirely on one employee’s account. People using it should authenticate as themselves, and access company data according to their own permissions rather than inheriting those of the person who built it. The organization should be able to see what has been deployed, who owns it, and who can use it. And when the tool is no longer needed, or its creator leaves the company, there should be a way to retire it without depending on that person.

Today, organizations tend to handle this in one of three ways. The first is to let employees publish directly through the AI platform where they built the tool. This is increasingly possible, and major providers are investing heavily in making their platforms suitable for enterprise use. But each platform has its own environment, sharing model, and administrative controls. An organization whose employees build with Claude, ChatGPT, and other tools can find itself managing a growing collection of applications across different platforms, without a single view of what exists or a consistent way to manage it. The concern isn’t necessarily that any individual platform lacks enterprise controls, but that organizational ownership becomes fragmented across vendors.

The second approach is to involve IT or engineering. For applications that require complex integrations, significant infrastructure, or additional security review, this makes sense. The difficulty is that the number of people who can now create tools is growing much faster than the capacity of technical teams to deploy and support them. An insights manager at a company of around 260 employees described how something that takes half an hour to build can require half a day of a developer’s time just to make available to others. When every department starts creating its own tools, the deployment process can quickly become a bottleneck.

The third approach is to restrict or prevent employees from publishing what they create. This may reduce the number of officially deployed applications, but it doesn’t necessarily stop employees from building or finding ways to share them. Instead, some of that activity moves outside the organization’s visibility, making it harder to understand which tools exist, who is using them, and what company data they can access. The attempt to prevent unmanaged software can end up creating more of it.

Part of the difficulty is that we’re applying processes designed for traditional software development to something that is becoming much more common and accessible. We tend to assume that an application needs a repository, code reviews, a deployment pipeline, and ongoing engineering ownership. Those practices are important for many systems, but not everything employees create has the same requirements or lifespan. A dashboard for a quarterly board meeting or a tracker for a two-week migration might only be useful for a short period. That doesn’t make it personal or irrelevant to the organization. While other employees rely on it and it interacts with company data, it still needs appropriate access, ownership, and a way to be retired.

There’s also a difference in who is expected to operate these processes. A Head of Data I spoke with described an attempt to have employees in support, marketing, and design manage their creations through Git. Branches broke, merges became difficult, and one person eventually found themselves maintaining the repository on behalf of everyone else. The process was familiar to developers, but it wasn’t designed for the people now creating these tools. We’ve made building accessible to employees who aren’t developers, yet sharing what they’ve built can still require them to understand the tools and practices of software engineering.

In some ways, organizations have dealt with a version of this problem for years. Almost every company has an important spreadsheet that only one employee truly understands. It might support a financial process, calculate pricing, or track something that no existing system handles particularly well. The spreadsheet itself isn’t necessarily the problem. The difficulty begins when other people depend on it, but nobody has established where it should live, who can access it, or what happens when its creator moves on. AI is making it possible to create far more sophisticated tools with similar ease, and the same questions of ownership and continuity are becoming relevant to a much broader range of applications.

And this isn’t limited to applications. Employees are also beginning to create and share AI skills, commands, automations, and agents. A skill that prepares a weekly update, a command that retrieves sales figures, or an agent that helps prepare customer renewals may not look like a traditional application, but it raises many of the same questions. Who can use it? Which information can it access? Who is responsible for maintaining it? And how does the organization stop using it when it’s no longer appropriate?

I don’t think the answer is to standardize where employees build. Different teams will prefer different AI tools, and those preferences will change as the technology evolves. The important distinction is between the environment where something is created and the environment where it becomes available to the organization. Employees should be able to create with whichever AI they find most useful, without making the company dependent on that same provider to operate and manage everything they build.

This is the thinking behind Cloche. We’re building a way for employees to deploy and share what they create with AI, while giving organizations one place to manage access, ownership, and the lifecycle of those tools, independently of where they were created. The goal isn’t to introduce another approval process or move creation back into the hands of technical teams, but to make it possible for employees to share useful solutions without requiring every deployment to become an engineering project.

The next challenge for organizations isn’t simply helping more employees build with AI. It’s figuring out how the things they create can become part of the organization, with the same expectations of ownership, access, and continuity as other company resources, without losing the independence and speed that made them possible in the first place.