Vibe coding has reduced the barrier to developing a working application to virtually zero. In many cases, programming skills are no longer required. Instead of writing code manually, users simply describe in natural language what they want an application to do, and an AI generates the corresponding code. In the most extreme cases, the generated source code is adopted without modification—even though the creator may not fully understand it due to a lack of programming knowledge.
This is where the real challenge begins. There is a significant difference between an application that works and one that can be operated securely. The primary risk of vibe coding is therefore not a technical one; it quickly becomes an issue of cybersecurity, data protection, and ultimately, legal liability.
The problem does not necessarily start with the source code itself. Modern AI models often generate well-structured and functional code. The real risk arises because inexperienced users are unaware of the security requirements that must be considered and therefore fail to include them in their prompts. As a result, security-related decisions are often left to the AI—or omitted entirely. The reason is simple: people cannot ask for security measures if they do not know those measures exist.
In practice, this can lead to serious security vulnerabilities. An experienced software developer or security engineer automatically considers topics such as secure authentication, encryption, authorization concepts, logging, input validation, and API protection against known attack vectors during development. An inexperienced vibe coder, on the other hand, often evaluates only the visible result: the application works, so it is considered finished. The fact that functional software is not automatically secure software is frequently overlooked.
Another commonly underestimated aspect is the infrastructure on which an application is deployed. Secure software is not defined solely by secure source code—it must also run within a properly secured environment. Secure server and cloud configurations, well-designed access control, encryption, regular security updates, monitoring, and professional vulnerability management are just as important as the application code itself. Anyone who does not understand the requirements of secure operations will not be able to instruct an AI accordingly. The result may be applications that function as intended but contain significant security weaknesses and fail to meet cybersecurity and data protection requirements.
There is also a psychological factor that is often overlooked. An application that launches successfully and performs all expected functions quickly creates the impression that it has been professionally developed. In reality, however, a functional user interface says nothing about the security of the underlying architecture or compliance with applicable legal requirements. This false sense of security often results in applications being released without ever undergoing a qualified security assessment.
This leads directly to the question of legal responsibility. The fact that an application was created partially or entirely by an AI does not shift responsibility to the AI model. Anyone who develops, distributes under their own brand, or operates software remains responsible for ensuring that it complies with applicable laws and reflects the current state of the art in cybersecurity. This includes implementing appropriate technical and organizational measures to protect personal data and adhering to recognized security standards.
The General Data Protection Regulation (GDPR) already requires organizations to implement Data Protection by Design and Data Protection by Default. Security measures must reflect the current state of the art. Anyone processing personal data is legally required to implement appropriate technical and organizational safeguards, regardless of whether the underlying software was written by a human developer or generated by artificial intelligence.
The European Union's Cyber Resilience Act (CRA) further strengthens these obligations. Beginning in September 2026, manufacturers will be subject to mandatory reporting requirements for actively exploited vulnerabilities and significant cybersecurity incidents. From December 2027, the CRA's full manufacturer obligations will apply to software products. These include providing security updates for several years, maintaining a Software Bill of Materials (SBOM) documenting all software components used, and meeting additional cybersecurity documentation and compliance requirements. These obligations apply regardless of whether software was developed traditionally or created through vibe coding. This raises an important question: How can security vulnerabilities be reliably fixed over many years if the developer does not fully understand the AI-generated source code?
Product liability law is evolving as well. Under the new European Product Liability Directive, software is explicitly recognized as a product. As a result, security flaws may lead to significant legal and financial consequences for manufacturers and distributors. Claiming that the code was generated by AI is unlikely to constitute a valid legal defense.
