Vibe coding means that someone describes in everyday language what an application should do, and an AI tool such as Claude or Codex writes the code. The person mainly checks whether the result works and often does not read the code at all. In a company, this makes sense as long as it is clear which data may go into the app, who is responsible for it and where it runs.
What is vibe coding?
The AI researcher Andrej Karpathy coined the term in early 2025. The result is real code. That is the difference from no-code tools, where you work inside a ready-made construction kit.
At small and mid-sized companies, the people building are often technically minded employees, product managers or branch and workshop managers. They know the business problem well, but have no training in software development or in running applications.
Where does vibe coding fit in a company?
Tasks that are clearly defined and where a mistake has limited consequences are well suited. Typical examples are:
- Checking and importing Excel files
- Preparing extracts from the ERP system for branch and department managers
- Time tracking for small teams (contains staff data, so level 3 in the rules below)
- A chatbot for branch staff that knows your internal instructions
- Prototypes that you use to clarify requirements before you buy or commission software
Vibe coding is less suitable for core systems such as accounting and payments. There, a prototype can show the requirements, but running the system takes experienced developers.
What typically goes wrong with vibe coding?
KPMG describes vibe coding as a new form of shadow IT (article in German), in which business departments often develop solutions without clear rules for data, quality and operation. Shadow IT means software that a company uses without its IT lead knowing about it or having approved it. In practice, this shows in the following points:
- The prototype stays. An app is created for a demo and is then used every day, without backups and without a responsible person.
- Company data ends up in the prompt. Anyone who pastes a real customer list into the AI tool passes it on to the AI provider.
- The app works but is not protected. An AI builds what you describe. If nobody says who may see which data, signed-in people may be able to open other people's records.
- Credentials sit in the code. Passwords and API keys travel with every copy of the code.
- The knowledge depends on one person. If that person leaves the company, nobody understands any more how the app works and where it runs.
- Duplicates appear. Three departments build the same tool, and the figures do not match.
Why is a ban not a good solution?
A ban does not remove the need that led to the apps, and the AI tools are easy to reach. People will therefore probably keep building, and you will hear less about it.
KPMG also states that the aim is not to prevent development in business departments, and recommends a controllable framework with a secure standard route. This route has to be convenient, otherwise hardly anyone will use it.
Which rules make sense for small and mid-sized companies?
You do not need a long set of rules. A classification by risk that each person can carry out alone works best:
- Level 1, personal helpers. Only one person uses the app, and it contains no data about people. You may build freely.
- Level 2, team tools. Several people use the app, and it contains internal data. The minimum rules below apply.
- Level 3, sensitive applications. The app contains staff or customer data, can be used from outside or writes to core systems. In addition, the IT leads and data protection look at it before launch.
These minimum rules fit on one page:
- Every app is registered. A simple list is enough: name, purpose, responsible person, data, address.
- Every app has a responsible person and a deputy.
- There are clear rules for prompts. Real data about people only goes into an AI tool if this has been cleared. Sample data is enough for building.
- AI tools run on company accounts. Private accounts are not allowed for company data, because you control neither the settings nor the contract there.
- Sign-in runs through the company account. There is no open link and no shared password.
- Credentials are never in the code.
- A second person tests before launch. They check whether they can see something they should not be able to see.
- Apps no longer in use are switched off. Check once a year what is still needed.
Who does what: departments, IT and management?
- The business department builds, tests and maintains the app and stays responsible for its content.
- The IT leads define the standard route, meaning accounts, operation and sign-in, and advise on level 3. At smaller companies, a department head often does this on the side.
- Management adopts the rules, provides time for them and decides in cases of doubt.
For individual apps, there is the checklist from prototype to company tool.
What Auftrieb takes care of
Auftrieb is one possible standard route for the rules in this guide. Sign-in runs through Google Workspace or Microsoft Entra. Apps you build yourselves are internal and become public only when the responsible team expressly confirms it. A central catalogue shows the apps, and the people responsible for an app decide on access requests. Credentials are stored encrypted and apart from the code. You maintain the code of your own apps with your AI tool. You can read more on the Security page.
Updated: November 2026