Together with the technical barrier, the natural point of review has also disappeared: the moment when someone with expertise would ask:<\/p>\n
That moment is no longer there.<\/strong> As a result, these questions often surface later, in conversations with lawyers.<\/p>\n The term was introduced in early 2025 by Andrej Karpathy, a former head of AI at Tesla and OpenAI. It describes a way of creating software where you explain what you want, AI generates code, and you repeat the process until the tool works, without needing to read or understand the code itself.<\/p>\n The most popular platforms used by entrepreneurs and managers today include Cursor<\/strong>, Bolt<\/strong>, Lovable<\/strong>, Replit<\/strong> and v0 by Vercel<\/strong>. Each offers a way to build a working application in a few hours without hiring a developer.<\/p>\n \u00a0<\/span><\/p>\n Not every use of AI to create software involves the same risk. It can be a reasonable choice in situations such as:<\/p>\n These cases share a low cost of failure. If something goes wrong, the consequences are manageable.<\/p>\n The problem begins when a tool built \u201cas a test\u201d becomes part of the company\u2019s operations.<\/p>\n Personal data processing<\/strong><\/span><\/p>\n The GDPR does not ask how the software was created. If your tool processes personal data, such as customer, employee or contractor data, you are responsible for how those data are stored, protected and deleted.<\/p>\n <\/p>\n AI-generated code rarely accounts for Privacy by Design and Privacy by Default<\/a><\/strong>, which call for data protection to be built into a system at the design stage. It even less often respects data-retention and secure-deletion rules<\/strong><\/a> that follow directly from the regulations.<\/p>\n A working tool is not necessarily a compliant tool.<\/p>\n Integrations with other systems<\/span><\/strong><\/span><\/p>\n Connecting a tool you built yourself to a CRM, e-commerce platform, accounting system or external API adds complexity that AI does not handle well. Authorization errors, unencrypted data transfers and missing exception handling are common problems in code generated without engineering oversight.<\/p>\n <\/p>\n The NIS-2 Directive<\/strong><\/a> also imposes information-system security and incident-reporting obligations on a growing group of companies. Software whose operation you cannot explain is difficult to defend during an inspection or after a breach.<\/p>\n Responsibility for decisions made by the system<\/strong><\/span>\u00a0<\/span><\/p>\n If your tool supports decision-making by assessing applications, generating recommendations or filtering data, you enter an area regulated by the AI Act<\/a>.<\/strong> The EU law on artificial intelligence distinguishes systems by risk level and imposes specific duties on providers and users. Depending on its use, a tool built in a weekend with Bolt may qualify as a high-risk AI system<\/a>.<\/strong><\/p>\n Control over external providers<\/span><\/strong><\/span><\/p>\n If you use a vibe-coding platform as a SaaS service, data you process through it often reach the provider\u2019s servers. Have you signed a data-processing agreement with the provider? Do you know where the data are physically stored? The GDPR regulates oversight of personal-data processors<\/strong><\/a>, whether a tool took five minutes or five months to build.<\/p>\n Before making a tool you built available to a wider group of users, ask yourself one question:<\/p>\n What would happen if someone asked you whether the tool was completely safe?<\/strong><\/p>\n If your answer is I don\u2019t know<\/em>, this is a good time to check. It does not mean you have to discard what you built. It means you should understand what you actually have.<\/p>\n <\/p>\n An independent code review can turn a prototype into something you can safely build on, or clearly show that it is better to start again. In either case, you have information instead of relying on \u201cif it works, it must be fine.\u201d What such a review looks like and what it costs in practice<\/a><\/strong> is worth checking before you decide.<\/p>\n Vibe coding lowers the barrier to software development in a way we have not seen before. It is a real change that gives entrepreneurs new options, especially when testing ideas.<\/p>\n <\/p>\n It also creates a new category of risk: systems that look like finished products but have had no technical or legal review.<\/p>\n The law does not distinguish between code written by a person and code generated by AI. It distinguishes who controls the data, who is responsible for system security and who makes decisions with the system\u2019s help.<\/p>\n Build quickly.<\/p>\n Test boldly.<\/p>\nWhat is vibe coding?<\/h2>\n
Where vibe coding makes sense<\/h2>\n
\n
When vibe coding becomes a legal problem<\/h2>\n
One question to ask before deployment<\/h2>\n
Summary<\/h2>\n