An autonomous vehicle strikes a pedestrian at an intersection. The company claims the accident resulted from a flaw in the decision-making algorithm that controls braking. But when lawyers ask the software engineers who developed the system to explain how the algorithm decides when to stop, they cannot. The code was generated by an AI in response to a natural language request, never read by any human engineer nor reviewed before deployment. No one in the organisation can explain what it does or why it made the decision that led to the collision. When the victim’s family files a lawsuit seeking accountability, they discover a legal void: the engineers didn’t write the code, the company who created the AI claims the AI is just a tool, and the manufacturer deployed the software but doesn’t understand how it works. When the court asks who is responsible for this harm, the answer is silence. This scenario describes an emerging crisis at the intersection of software development, law, and artificial intelligence: the responsibility vacuum created by ‘vibe coding’.
Vibe coding, a term coined on X by AI researcher Andrej Karpathy in February 2025, describes a development paradigm where developers use natural language prompts to ask large language models (LLMs) to generate code, accepting the AI-generated output without human review or comprehension. For software engineers, vibe coding promises speed and democratisation. For legal systems, it creates an accountability crisis that existing frameworks are wholly unprepared to address. Vibe coding is not simply using GitHub Copilot or coding with AI assistance. Rather, it represents a deliberate shift in development methodology: the developer does not write code, read code, or necessarily understand code. Instead, the developer describes intent and accepts whatever the AI generates. Vibe coders have described generating thousands of lines of code in minutes without reading any of it. This represents a fundamental departure from conventional development practice.
Traditional software development assumes that human developers understand their own code. When a developer writes a function, they know what it does. When another developer reviews it, they read it. This review cycle is where security vulnerabilities, bugs, and logical errors get caught. It is also where legal responsibility naturally lies: with those who wrote and reviewed the code. Vibe coding inverts this entirely. The developer becomes a prompter and acceptor rather than an author and reviewer. This shift seems like an efficiency gain, and empirically it often is. Vibe-coded systems can move from concept to deployment in weeks rather than months. But this efficiency comes at a profound cost: the traditional mechanisms of accountability vanish.
The legal systems governing software development have never faced a situation where code exists that no human author comprehends. Product liability, employment law, intellectual property law, and data protection law all assume that a human being understands the code and bears responsibility for it. Vibe coding dissolves that assumption. While no court has yet confronted a case specifically involving harm from vibe-coded systems, recent AI product liability cases suggest how such disputes might unfold. Product liability law holds manufacturers responsible for defects. The law assumes the manufacturer designed the product, tested it, understood it, and made a decision to market it. This knowledge grounds responsibility. But consider a vibe-coded AI system deployed in a lending algorithm or medical diagnostic tool. A court investigates harm and asks: ‘Who designed this defect?’ The answer becomes impossibly tangled. The AI company trained the large language model. The developer prompted it. The company deployed it. None of them designed the algorithm in the traditional sense. It emerged from training data patterns that no individual actor could have predicted or controlled.
The security vulnerabilities in vibe-coded systems underscore this problem. A 2024 report from Jessica Ji and her coauthors published by the Georgetown’s Center for Security and Emerging Technology found that nearly half of code snippets produced by major AI code generation models contain bugs that are often impactful and could potentially lead to malicious exploitation. A systematic literature review written in 2024 by Negri-Ribalta and coauthors examining AI-generated code security found universal agreement across nineteen empirical studies that ‘AI models do not produce safe code and do introduce vulnerabilities, despite mitigations,’ with particular concern around languages like C where manual memory management is critical. In another study from 2025 on iterative AI code generation, Shivani Shukla and her coauthors discovered that vulnerabilities actually increase through iterations: when developers refine AI-generated code through multiple prompts, critical vulnerabilities increase by 37.6% after just five iterations.
These vulnerabilities create direct legal liability. The European Union’s Cyber Resilience Act (CRA), which is set to enter into force in December 2027, requires that manufacturers identify and fix vulnerabilities, with fines up to 15 million euros or 2.5% of global turnover for noncompliance. But the CRA assumes manufacturers can identify vulnerabilities. If a vibe-coded system contains hidden security flaws that no developer comprehended when accepting the AI’s code, can they really be held liable? The law says yes. The developer’ capacity to fulfill that responsibility says no.
The EU has chosen a relatively strict approach to attributing responsibility for flaws in AI systems, codified in the Product Liability Directive (PLD) (2024/2853) and the CRA. Under the PLD, software and AI systems are explicitly ‘products’ subject to strict liability. A defect includes non-compliance ‘with mandatory cybersecurity requirements.’ For vibe-coded systems, this creates a difficult choice: companies can either invest in human review to ensure vibe-generated code meets security standards, or they can avoid vibe-coded systems in products sold to EU markets. The regulation does not ban vibe coding; it simply makes it expensive to use in regulated contexts. The deadline for compliance is 9 December 2026 for the PLD and 11 December 2027 for the CRA. Organisations placing software on EU markets are already beginning to reckon with these requirements.
The United States has taken a different approach in proposed legislation. The AI LEAD Act, introduced in Congress, would create a federal cause of action for product liability claims against AI system developers and deployers. The bill classifies AI systems as ‘products’ subject to traditional product liability principles. Developers could face claims for defective design, failure to warn, breach of express warranty, and strict liability. Deployers could be liable for unauthorised modifications or intentional misuse. The bill also explicitly forbids companies from including liability waivers in user agreements. What is significant about the U.S. approach is its focus on liability for failures rather than prescriptive security requirements. Companies can choose how to manage vibe coding, but they face consequences if their systems cause harm. However, the bill’s approach inherits a critical weakness: it does not solve the causation problem. If a vibe-coded algorithm discriminates, establishing that the discrimination was caused by a ‘defect’ requires understanding why the algorithm made that decision. But if no one understood the algorithm when they deployed it, how can anyone prove the defect exists?
Data protection law creates an additional crisis for vibe-coded systems. The EU’s General Data Protection Regulation requires organisations to provide data subjects with ‘meaningful information about the logic’ of automated decision systems. This creates an impossible situation. How do you explain the logic of a system that no human comprehends? Consider the autonomous vehicle scenario: if the system fails to brake and causes a collision, what can the manufacturer say when asked to explain the braking algorithm’s decision? ‘An AI generated the code using patterns from billions of training examples, and we never read it, so we don’t know why auto failed to brake.’ This is not a legal explanation. It is a confession of non-compliance. The new EU Product Liability Directive explicitly names non-compliance with ‘safety-relevant cybersecurity requirements’ or ‘failure to provide security updates’ as product defects. The CRA requires manufacturers to provide ‘technical documentation’ explaining their systems’ security measures. But can you document the security of code you do not understand?
The Post Office Horizon scandal in the UK illustrates why this matters for government systems. Between 1999 and 2015, the British Post Office deployed the Horizon accounting system, which contained bugs and defects that led to false shortfalls in branch accounts. More than 900 subpostmasters were wrongfully convicted of theft and fraud based on data from the faulty system. The scandal revealed that the Post Office was aware of at least two known defects but continued using the system and prosecuting subpostmasters. What would have happened if Horizon had been vibe-coded? The Post Office could not point to anyone who designed it. The developer could claim they were merely using AI tools. No one could explain how the system worked. The accountability crisis would have been exponentially worse. Governments are increasingly exploring vibe coding for systems that affect citizens’ lives directly: welfare eligibility determination, tax assessment, child benefit allocation, parole recommendations. When these systems fail, citizens have no recourse against algorithms they cannot understand.
The emerging legal frameworks reflect competing theories of responsibility. Under developer liability, developers bear responsibility for validating AI output. But this requires developers to read and understand code, which defeats the purpose of vibe coding. The theory is legally coherent but technically incoherent. Under company liability, companies deploying vibe-coded systems are strictly liable for defects. This creates strong incentives for human review and quality assurance but potentially stifles vibe coding development entirely in regulated sectors. Under labor frameworks, developers should have rights to understand systems they are responsible for. This protects professional integrity but does not solve the liability question. Under AI company liability, the producers of the AI coding tools bear responsibility for deployers’ misuse. This protects deployers but requires AI companies to police their users.
Different jurisdictions are adopting different combinations. The EU is moving toward company liability combined with AI company liability. The United States is experimenting with developer and deployer liability. Labour movements push for professional standards. Technology companies advocate for minimal responsibility. These choices are not merely technical; they are fundamentally political. They reallocate accountability, shift risk, and change the relationship between developers, companies, and the systems that structure modern life.
Some proposals require that any vibe-coded system include a ‘code genealogy,’ a traceable record of which portions were generated by AI and which were written by humans, with documentation of what review occurred. This does not solve the comprehension problem, but it creates accountability. If harm occurs, investigators can trace which parts were unchecked AI output. A growing consensus holds that vibe coding should be permitted in non-critical systems but restricted in regulated sectors. Healthcare, finance, government, critical infrastructure, and automotive systems require more stringent standards. In practice, vibe coding will likely thrive in consumer applications and non-regulated software while remaining constrained in critical sectors.
Vibe coding represents a fundamental shift in how we distribute responsibility for complex technological systems. Developers ostensibly gain speed; they actually lose comprehension. Companies gain faster deployment; they lose capacity to explain their systems to regulators and citizens. The legal frameworks currently being developed will determine whether this accountability crisis gets solved through strict manufacturer liability, developer validation requirements, labour protections, or some combination of these approaches. How we resolve this question will shape the future of software development and reveal what we actually believe about expertise, professional judgment, and the relationship between humans and the machines they create.
Xiaolong (James) Wang is a graduate student in foreign service at Georgetown University and a Schwarzman Scholar at Tsinghua University.