Vibe coding in mid-sized companies: your company is already programming, and now you need a rule

Updated on 8 October 2026: we have added the transition period for Article 50(2).

Your company is already writing code. Just not in IT.

Three scenes of the kind that happen in many mid-sized companies.

In sales, calculating quotes takes too long. A sales rep describes to an AI assistant in a few sentences what he needs: tiered prices, discount limits, delivery costs by region. An hour later he has a quote calculator. By now, half the team uses it.

In accounting, an employee matches incoming payments against open items every month, line by line. With an AI assistant, she creates a small script that does the matching. Two days of manual work become the push of a button.

In customer service, the team lead wants to know which enquiries are piling up. The CRM does not deliver the report in the form she needs. So she has an AI write her a script that merges and sorts the exports.

None of these people would call themselves a programmer. All three have still built software. And in none of the three cases does IT know about it.

In a Bitkom survey from October 2025 (in German) of 604 companies with 20 or more employees, 42% assume that their employees use private AI tools at work. Only 26% provide generative AI themselves. The 2024 Work Trend Index from Microsoft and LinkedIn shows the same pattern: 78% of AI users bring their own tools to work, and in small and medium-sized businesses the figure is 80%.

These figures concern AI use in general. They do show where the building happens, though: often through private accounts, invisible until someone asks where a number came from. If these scenes don't sound familiar from your own company, it is worth asking around.

What vibe coding is and why the term sticks

Vibe coding means you describe in plain language what a tool should do, and an AI writes the program code for it. For example: "Read in the Excel list of open items, match it against the bank statement and highlight everything that is missing." A few minutes later, a small program is running. The person who started it has never read the code behind it.

The term was coined by a well-known AI researcher in February 2025 in a post on X, whose wording is documented on the Wikipedia page for the term. In it, he wrote that you give in to the vibes and forget that the code even exists. In the same post he qualified the method: it was fine for throwaway weekend projects. So he meant trying things out. Software for running a business was not what he had in mind. That limitation carries the rest of this article.

The term still spread quickly. Collins Dictionary chose "vibe coding" as its word of the year in November 2025 and describes it as programming with AI that is instructed in natural language.

Traditionally, a business unit writes down requirements and IT implements them. That takes weeks and only starts if the problem is big enough. With vibe coding, the person who has the problem builds the solution themselves, in minutes to hours. The shift behind it: anyone who can describe a problem clearly can now build a tool for it. Domain knowledge and a precise description are enough.

That is what makes vibe coding interesting. And it explains why it needs a rule: the code runs without anyone having looked at it.

Why this is good news for mid-sized companies

The knowledge that keeps your company running rarely sits in IT. It sits in dispatch, which knows which supplier delivers reliably when supplies are tight. In accounting, which knows every special case in payment matching. In sales, which knows which discount logic applies to which customer. Until now, this knowledge first had to be translated into a requirements specification before it could become software. Many good ideas have failed at that translation.

Vibe coding shortens that path. And most of these problems would never have become an IT project. A calculator for special terms, a script that matches two export files, a report that someone copies together by hand every Monday: none of these justifies a requirements specification or a place on the IT roadmap. Together, they still cost hours every week. Self-built tools replace neither the ERP nor the CRM. They work in the gaps these systems leave open.

That is why vibe coding is a basic skill, in the way reading and arithmetic are. When spreadsheets arrived in offices, they did not stay a specialist tool for long and became a working tool in every department. We expect a similar development with programming in everyday language. A ban will not stop it; it will push it into private accounts. Anyone who has lived through spreadsheets in their own company also knows their downside, though.

The Excel pattern: we already know this problem

Almost every mid-sized company has one: the calculation file the whole quoting process depends on. Or the list from which commissions are calculated every month. Someone built it years ago. It works. And nobody apart from that person knows exactly why.

With self-built AI tools, this pattern repeats itself, only faster. There are four risks.

Lack of traceability. With an Excel file that has grown over time, often nobody knows any more which formula produces which value or where the input data comes from. With a tool created from a description, the situation is often even less clear. The person who built it may never have read the code. The tool does something, but exactly what it does is not written down anywhere.

Knowledge monopolies. The knowledge about a tool sits in the head of a single person. If they change jobs, go on parental leave or are off sick for two weeks, the process stops. Or it keeps running, and nobody notices that the results are no longer correct.

Errors in the calculation logic. A wrong cell reference goes unnoticed as long as the numbers look plausible. It is the same with AI-generated code. It runs, but that does not mean it calculates correctly or is secure.

Data leaking into private AI accounts. This risk did not exist in this form in the Excel era. Anyone building a tool with AI today often copies real data into a chat to do so: customer lists, prices, reports. Where the company does not offer its own access, which according to the Bitkom survey cited at the start is the case for around three quarters of companies, employees find their own. The data then ends up in accounts the company has no access to.

Most managing directors know the pattern from Excel. What was missing back then was a simple rule before a file became business-critical. You can introduce that rule today, before the first self-built AI tools get there.

The one rule: no tool goes into operation without a second pair of eyes

If you take only one thing from this article, take this: before a self-built tool works with real customer data, with money or with external impact, a second person looks at it. This is a minimum organisational control to get started, and it is not a legal approval. Data protection, IT security and the AI regulation remain separate topics that the second pair of eyes does not cover.

The rule applies at a clear threshold. As long as someone builds a report for themselves or tries out an idea with invented or anonymised test data, no formal review is needed. Copying real customer data, HR data or confidential information into an AI assistant, on the other hand, already counts as data processing and should not happen unchecked in this phase. As soon as the tool changes customer records, calculates prices, triggers payments or sends emails to customers, the four-eyes principle applies. The review happens at the transition into real business. The idea and the first draft need none.

Why this moment in particular

AI assistants produce code that runs. Whether it is also secure is a different question. Veracode's GenAI Code Security Report (July 2025) tested over 100 AI language models on 80 programming tasks. In 45% of cases, the generated code failed the security tests and contained known vulnerabilities. The tests used standardised programming tasks rather than tools built in business units. For our question, the finding is still enough: a result that works has not yet been checked. Anyone who is not a developer won't see such gaps. After all, the tool works.

The authorities are focusing on this too. The BSI (Federal Office for Information Security) and the French cybersecurity agency ANSSI state in their joint recommendations on AI coding assistants from 2024 that these assistants do not replace experienced developers and that a systematic risk analysis should come before they are introduced.

The rule builds on these findings and on a principle you have long known from accounting and payment approval.

Why one rule works better than a set of policies

In a company with 150 employees, hardly anyone reads a thick rulebook from start to finish. People who are unsure don't ask; they quietly keep building. A rule that fits in one sentence stays in everyone's head. It does not forbid experimenting and does not prescribe tools. It only makes clear that when there is external impact, two people carry responsibility instead of one.

Why the rule does not slow you down

The review comes once, before the step into operation. Trying things out and throwing them away stays free. Most ideas never reach this threshold, and for the rest the review costs one conversation. That is little compared with a tool that sends wrong prices to customers for weeks before anyone notices.

On top of that, perceived and actual speed can differ. In a randomised study by the research organisation METR (July 2025), 16 experienced open-source developers took 19% longer for their tasks with AI tools. They themselves believed they had been 20% faster. METR stresses that this is a snapshot with the tools of early 2025. The lesson stands: if even professionals misjudge their work with AI, a second look is not a vote of no confidence. And anyone who knows what the path into operation looks like is more likely to show a tool than to let it run in secret.

What the second pair of eyes actually checks

This review does not go through the code. The second pair of eyes asks four questions in everyday language. Whoever built the tool should be able to write the answers down on half a page. If they can't, that is already a finding.

Before the four questions comes a preliminary question: does the tool assess or monitor employees or applicants, recognise emotions, process biometric data or make decisions about people? Then the tool needs a legal review before any use, and the second pair of eyes is the wrong place for it. According to the text of the regulation, Article 5 of the AI regulation has listed some of these applications as prohibited practices since February 2025, for example emotion recognition in the workplace, unless it is used for medical or safety reasons.

1. Which data flows where?

What data does the tool work with: customer data, prices, HR data? Where is it stored, who can see it, and does content go into a private AI account or to an external service? The question is not theoretical. In May 2025, a vulnerability was disclosed in applications built with a widely used platform for AI-generated apps. Access rules for the database were missing, and outsiders could read and change tables without logging in. The vendor disputes the vulnerability and places responsibility for data protection with the app operators, according to the note in the database. The apps worked. They were simply wide open.

2. Who is responsible if it fails?

Who notices when it delivers wrong results? Who fixes it when the person who built it is on holiday or leaves? A tool that only one person understands is an operational risk, even if it runs flawlessly today.

3. Is it clear what the tool does?

Can the person who built it explain in their own words what the tool calculates, filters or decides? The reviewer tests it with two or three cases where they know the correct result. Does it produce what it should?

4. Is there a way back?

What happens if the tool damages data or fails? Is there a backup that exists independently of the tool? Does the team still know the process without the tool? In July 2025, during a publicly documented vibe coding experiment, the AI agent of the Replit platform deleted the production database, even though a code freeze was explicitly in place. It then generated fake data and claimed that recovery was impossible. That was not true; the data could be restored. The lesson for you: check the way back yourself, and do it beforehand. Don't rely on what the tool tells you about it.

Who reviews?

The reviewer does not have to be a developer. They need an understanding of processes and data: how does the process run today, which data is sensitive, what must never go wrong? That could be someone from finance or quality management, or the team lead of a neighbouring department. Anyone except the person who built the tool. If personal data is involved, also bring in your data protection officer in an advisory role; the decision on use stays with the responsible manager.

There is one limit: a business reviewer cannot assess the security of the code itself. As the BSI and ANSSI stress, that takes experienced developers. That is why the second pair of eyes is enough for team tools, while business-critical tools also go to IT.

If one of the four questions remains open, the tool does not go into operation yet. Nobody is vetoing it; this is a task with a clear end.

Approval levels instead of a blanket ban

Management's obvious reflex: ban everything for now until IT has checked it. The Bitkom figures from the start show that the use is already happening. A ban will not end it; it makes it invisible. A better approach is to distinguish by impact, in three levels that tie in with the threshold of the one rule.

What matters is the transition between the levels. Tools grow. A personal aid becomes a team tool because colleagues find it useful. That is intended. But as use grows, the level rises, and with it the review. The rule for this is simple: whoever passes a tool on registers it for review.

From level 2 onwards, it is also on record for every tool who built it, who reviewed it and who looks after it. To get started, that is the core of governance in mid-sized companies: clear responsibility before it matters. As the number and importance of tools grows, documentation, changes, access rights and decommissioning are added. How tasks are distributed across tiers by risk is shown in the 3-tier model for AI agents.

Where the four-eyes principle ends

The four-eyes principle is a working rule and does not amount to a legal review. Two topics run alongside it, and we raise them early in projects.

The AI regulation (AI Act) deals with the AI literacy of staff in Article 4. According to the text of the regulation, the article has applied since 2 February 2025. It was revised by the AI Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026. According to the regulation, the transparency rules in Article 50 have applied since 2 August 2026. According to the European Commission, providers of AI systems placed on the market before that date only have to meet the obligation to mark AI-generated content (Article 50(2)) from 2 December 2026. Whether and how this affects your self-built tools is for your legal counsel to clarify.

On data protection, we make no distinction between self-built and purchased software. If a tool processes personal data or sends it to an external AI service, it goes across the data protection officer's desk before use.

The four-eyes principle does less, and that is intended: it creates a fixed moment in which someone asks which data flows where. How we go through a company's AI use as a whole is shown in our deployer check.

What you do differently first thing on Monday

You need neither a project nor a budget for this. Four steps are enough to start.

1. Make visible what is already running. At the next management meeting, ask openly: which self-built tools, scripts, macros or small apps do your teams use today? If you look for culprits, you get silence. If you ask out of curiosity, you get a list. A simple table is enough: tool, purpose, who built it, what data it uses.

2. Formulate the rule and explain it. One sentence is enough: "Before a self-built tool works with real customer data, with money or with external impact, a second person reviews it." Explain it in the teams rather than by circular email, and say what it does not mean: no ban and no approval loop for personal aids.

3. Name reviewers. Decide who may act as the second pair of eyes. Two or three names are enough, for example an experienced team lead or the person who looks after your CRM. Everyone in the company should know whom to turn to. Give the reviewers the four questions from this article.

4. Show good examples. Pick two or three tools from your list that work and have been reviewed. Let the people who built them show in the team meeting which problem they solved. There is no clearer way to say that initiative is welcome and that the review is a normal part of it rather than a punishment.

Google's 2025 DORA Report describes AI as an amplifier: it makes strong teams better and exposes the weaknesses of weak ones. For self-built tools, that means: where responsibility is clear, curiosity becomes an advantage. Where it is missing, the next Excel pattern grows. Your job is to give this curiosity a framework.

If you want to assess where your company stands in its use of AI, the AI Diagnostic is a good starting point. We support you in clarifying approval levels and roles so that they fit your company.

Frequently asked questions

Should we ban vibe coding in the business units until IT approves it?

No. A clear rule works better: self-built tools are allowed with approved AI access, but none goes into operation without a second review. Firm limits still belong with it: no confidential data in private or unapproved services, and no applications that the law prohibits.

Who is suitable as the second pair of eyes if we don't have our own development department?

Someone who knows the processes and data and did not build the tool themselves, for example from finance, quality management or whoever holds IT responsibility. The data protection officer advises on data questions but does not give approval. Business-critical tools also need technical experience, in-house or at the IT service provider.

When does a self-built tool need a review?

As soon as it works with real customer data, money or external impact, or a team relies on it. And it needs it before the first use. After the first error is too late.

Doesn't the four-eyes principle slow down exactly the speed that vibe coding brings?

Hardly, if the review stays lean: one person, four questions, a short meeting. There is hardly a cheaper way to prevent an expensive error in operation.

How do we deal with the AI Act for self-built AI tools?

We separate two things. You set up the working rule, meaning the four-eyes principle, yourself. Whether and how the AI regulation affects your self-built tools is for your legal counsel to clarify. You can find the wording of Article 4 on AI literacy, as revised by Regulation (EU) 2026/1744, on EUR-Lex. The four-eyes principle does not replace a legal review, but it anchors the topic in everyday work.

How do we find out which self-built tools are already in use?

With an open team meeting that doesn't look for blame, as described in the first Monday step. What touches customer data, money or external impact gets reviewed first.

This article describes our practical perspective. It does not contain a legal assessment; for that, we refer you to the linked primary sources and your legal counsel. It reflects the situation as of 3 September 2026.

Sources

• Bitkom: Employees use shadow AI (in German), press release of 21 October 2025
• Microsoft and LinkedIn: Work Trend Index 2024, AI at work is here. Now comes the hard part, 8 May 2024
• Wikipedia: Vibe coding, version of 31 August 2026, with the wording of the post on X of 2 February 2025
• Collins Dictionary: Word of the Year 2025, 6 November 2025
• Veracode: 2025 GenAI Code Security Report, 30 July 2025
• BSI and ANSSI: AI Coding Assistants, 2024
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 July 2025
• NIST National Vulnerability Database: CVE-2025-48757, 30 May 2025
• The Register: Report on the Replit database incident, 21 July 2025
• Google Cloud: Announcing the 2025 DORA Report, 23 September 2025
• EUR-Lex: Regulation (EU) 2024/1689 (AI regulation)
• European Commission: Digital Omnibus on AI Regulation Proposal, 19 November 2025
• EUR-Lex: Regulation (EU) 2026/1744 (AI Omnibus), Official Journal of 24 July 2026
• European Commission: questions and answers on the transparency obligations under Article 50 of the AI Act