“Everyone is worried about being sued over AI-generated code. The quieter risk is owning less than you think: discovering at the diligence table that meaningful parts of your crown-jewel codebase were never protected at all.”
Vibe coding, “the use of artificial intelligence prompted by natural language to write computer code,” went mainstream fast enough that Collins Dictionary named it the 2025 Word of the Year,1 and the practice outran the label: Google’s chief executive wrote in April 2026 that 75% of new code at Google is AI-generated and engineer-approved, and 84% of respondents in Stack Overflow’s 2025 developer survey use or plan to use AI tools.2 The copyright consequence has not caught up with the adoption curve: purely AI-generated code has no human author, and without a human author there is no copyright. That is not a compliance technicality. A software company’s core asset is its codebase, and every development agreement, financing, and acquisition rests on the assumption that the company owns its code. Vibe coding quietly breaks that assumption, and the break surfaces first not in a lawsuit but at the diligence table, when a buyer asks the company to prove it owns what it is selling. Here is where the law actually stands, what survives, and what to put in place before someone else’s lawyers start asking.
Key Takeaways
- Copyright requires a human author. The U.S. Copyright Office’s January 2025 copyrightability report concludes that prompts alone do not give the prompter sufficient control to be the author, and the D.C. Circuit in Thaler v. Perlmutter held that the Copyright Act “requires all eligible work to be authored in the first instance by a human being.” Purely AI-generated material is not registrable.
- The consequence is an ownership gap, not just a registration problem: an assignment clause cannot transfer a copyright that never existed, so “we own all our code” reps in financings and acquisitions are softer than they read.
- Protection does not drop to zero. Human-authored portions, meaningful human selection and arrangement of the codebase, trade secrets, and contract terms all survive; the copyright layer becomes thinner and patchier, not absent.
- The infringement risk runs the other way too: AI coding tools can reproduce training data, including copyleft open-source code, and the GitHub Copilot litigation is testing whether stripping license metadata violates the DMCA.
- The fix is governance, not litigation: human-authorship provenance records, an engineering AI-use policy, and contracts that disclose AI use and allocate the risk honestly.
Is Vibe-Coded Software Protected by Copyright?
Mostly not, for the portions the AI generated on its own. Copyright protects original works of human authorship, and it protects expression rather than ideas.34 In vibe coding those two limits converge on the same result: the human supplies the idea and direction in natural language, and the AI supplies the expressive implementation, which inverts the relationship copyright is built to protect. The U.S. Copyright Office addressed this directly in Part 2 of its artificial-intelligence report, issued January 29, 2025: “prompts alone do not provide sufficient human control to make users of an AI system the authors of the output,” and “[c]opyright does not extend to purely AI-generated material.”5 The courts have reached the same result. In Thaler v. Perlmutter, the D.C. Circuit held that the Copyright Act “requires all eligible work to be authored in the first instance by a human being,” and the Supreme Court denied review on March 2, 2026.4
Two doctrines are doing the work here, and they are worth keeping separate. A prompt supplies the idea, and an idea is outside copyright’s reach under section 102(b), so the prompt itself earns its drafter nothing in the output.3 And separately, the basis the Copyright Office actually rests on, the person prompting does not exercise enough creative control over the resulting expression to count as its author, partly because the same prompt yields different outputs and the model does not reliably follow instructions.5 Those are different reasons that happen to point the same way, and together they cover both ends of the vibe-coding workflow.
The nuance that matters in practice: none of this is all-or-nothing. AI-assisted work remains protectable to the extent of the human’s own creative contribution, analyzed case by case, and under the Office’s 2023 registration guidance, still the operative practice, AI-assisted works register with the AI-generated portions disclaimed.6 The Thaler court itself noted that the Office “has allowed the registration of works made by human authors who use artificial intelligence.”4 Pure accept-all, ship-it vibe coding is the weak case. Disciplined human-in-the-loop development, where engineers meaningfully select, arrange, and rework the output, is the strong one. One more fact worth knowing: as of August 2026, no published Copyright Office Review Board decision applies the human-authorship line to AI-generated code. The Office’s published Review Board opinions on AI authorship concern visual works, and its closest code-adjacent precedent refused machine-captured light-data files on grounds including the want of human authorship without ever reaching generative code, so software companies are mapping doctrine onto codebases without a code-specific precedent.7
If your engineering organization uses AI coding tools, the copyrightability of your codebase is now a fact question about your own development process. The company that can show its human contribution wins that question; the company that cannot document it loses by default.
Who Owns AI-Generated Code?
For the purely AI-generated portions, often no one, because there is no copyright to own. That answer sounds academic until you read it against the contracts every software company signs. Virtually every development and contractor agreement assigns “all right, title, and interest” in the work product to the client, and that clause silently assumes the work product is ownable. To the extent specific code is purely AI-generated, the assignment has nothing to grab for those elements. You cannot assign a copyright that never existed.
Precision matters here, because the asset is thinner than the rep assumes, not zero. The assignment still transfers everything that does exist: the human-authored portions, the codebase’s protectable selection and arrangement, trade-secret rights, and, through standard future-assignment language, whatever rights later arise. The problem is that nobody at the signing table has measured which parts of the codebase fall on which side of the line, and the measurement only happens when money forces it.
That is why the risk direction in most coverage is backwards. The reported worry is infringement, that AI code will get the company sued. The quieter and larger exposure is non-ownership, that the company has less to enforce, license exclusively, or sell than it believes. Everyone is worried about being sued over AI-generated code. The quieter risk is owning less than you think: discovering at the diligence table that meaningful parts of your crown-jewel codebase were never protected at all. In a financing or acquisition, the company reps that it owns its intellectual property, and if the codebase was substantially vibe-coded that rep is soft. Expect acquirers and their counsel to start demanding human-authorship provenance: who wrote, reviewed, and meaningfully modified what.
The competitive-copying angle follows from the same premise. If the distributed code is not copyrightable and a competitor obtains it lawfully, through a departing engineer, a leaked repository, or lawful reverse engineering, copyright supplies no claim against copying that expression. The moat the company assumed copyright provided is simply not there for those portions.
Before your next financing or exit, run the provenance question internally, on your own timeline, rather than discovering the answer during someone else’s diligence.
What Still Protects an AI-Built Codebase?
More than the headlines suggest, and the honest framing is a layer-by-layer inventory rather than a verdict. Copyright thins; it does not vanish. Even where individual generated blocks are unprotectable, the selection, coordination, and arrangement of the codebase, its architecture, module structure, and integration, can be independently copyrightable as a compilation to the extent a human made those choices.8 Compilation copyright is thin, as the Supreme Court said of factual compilations, and it protects the arrangement rather than the underlying blocks themselves, but it is real, and it is the reason “the codebase has no copyright” overstates the problem in the other direction.
{{table:protection-layers}}
| Protection layer | Survives vibe coding? | What it requires from you |
|---|---|---|
| Copyright in specific code | Only for human-authored or meaningfully human-reworked portions | Provenance records showing who wrote, selected, and modified what |
| Compilation copyright (architecture, selection and arrangement) | Yes, where humans made the structural choices | Human-designed architecture, documented design decisions |
| Trade secret | Yes, and it becomes the lead protection | Secrecy discipline: access controls, NDAs, no public repositories |
| Contract | Yes | Development, employment, and license terms written for AI-assisted work |
| Patent | Narrowly, for genuinely novel methods | Human inventors, early filing, budget |
The practical consequence of the table is a strategy shift. Copyright is quietly becoming the wrong moat for AI-built software, and the protections that still work, trade secret, speed of execution, contractual restrictions, and in narrow cases patents, are the ones worth building around now. Trade secret in particular does not care whether a human or a model wrote the code; it cares whether the company kept the code secret and can prove it took reasonable measures. That is a governance program, not a registration form.
Reweight your IP strategy toward the layers that survive: secrecy discipline and contract terms first, copyright provenance second, registration last.
Can AI-Generated Code Infringe Someone Else’s Copyright?
Yes, and this is the flip side that keeps the risk two-directional. AI coding tools generate output shaped by their training data, and the output can reproduce protected code, including open-source code carrying copyleft licenses. A few generated lines under a GPL-family license can pull obligations into a proprietary codebase that reach far beyond those lines, silently. The live test case is the GitHub Copilot litigation, Doe v. GitHub. The district court dismissed the developers’ DMCA Section 1202(b) claim, the theory that stripping copyright-management information such as author and license metadata violates the statute, with prejudice, reading case law from courts in the Ninth Circuit to require that the output be identical to the original work, and what survives in the district court is the contract side of the case, led by breach of the open-source licenses themselves.9 Whether Section 1202(b) actually imposes that identicality requirement is now before the Ninth Circuit on interlocutory appeal, argued and submitted February 11, 2026, with no decision as of late August 2026.9 However it lands, what the case is testing matters to every company shipping AI-assisted code.
The transactional translation is the part that lands in contracts. A vendor building with AI assistance often cannot honestly give a buyer a clean intellectual-property warranty in either direction: it cannot fully promise chain of title on the ownership side, and it cannot fully promise the output copies nothing on the infringement side. That double uncertainty has to be allocated somewhere, and most templates in circulation are silent on it. The parties who address it expressly, with AI-use disclosure, scoped warranties, and indemnities matched to what can actually be promised, are the ones who will not be renegotiating under deal pressure.
Audit your inbound risk too: an AI-use policy that governs which tools your engineers use, and what open-source scanning runs on generated output, is now part of basic IP hygiene.
What Should a Software Company Do Now?
Treat this as a governance problem with a paperwork solution, because that is what it is. Three moves cover most of the exposure.
First, provenance discipline. Document human authorship across the development lifecycle: design decisions, architecture, meaningful edits, review. The case-by-case protectability test rewards the company that can show its human contribution, and the registration practice of disclaiming AI-generated portions requires knowing which portions those are. Registration has teeth here: the Office’s guidance says AI-generated content that is more than de minimis “should be explicitly excluded from the application,” warns that a registration obtained without that disclosure risks cancellation, and notes that a court may disregard a registration in an infringement action under section 411(b) where the applicant knowingly provided inaccurate information that would have caused the Register to refuse registration.6 The pure-vibe shop cannot reconstruct this after the fact.
Second, an AI-use policy for engineering. The legal profession spent the last two years writing AI-use policies for lawyers; software companies need the same for their developers. Which tools are approved, what code and data may be fed into them, what human review happens before output ships, and what gets logged. The policy is also the diligence artifact: it is the document that turns “we think our engineers were careful” into a showing.
Third, contract allocation. Development, SaaS, employment, and M&A documents should stop assuming clean ownership and start allocating the risk expressly: human-authorship and provenance representations, AI-use disclosure, assignment language drafted for a world where some work product is unownable, and indemnities scoped to what can honestly be promised. The companies that build these practices now will be grandfathering a clean record when the questions arrive; the ones that vibe and ship are building an asset they may not own and cannot fully sell.
Astraea Counsel advises software, AI, and fintech companies on technology transactions, AI governance, and intellectual-property strategy for AI-assisted development. Explore our AI counsel practice or contact us to talk through your codebase’s provenance posture.
This article provides general information for educational purposes only and does not constitute legal advice. Copyright law’s application to AI-generated works is evolving rapidly. Consult qualified legal counsel for advice on your specific situation. Attorney Advertising.
Footnotes
-
Rachel Quin, “Collins’ Word of the Year 2025: AI meets authenticity as society shifts,” Collins Dictionary Language Blog (Nov. 6, 2025) (announcing “vibe coding” as Collins’ Word of the Year 2025, describing it as “the use of artificial intelligence prompted by natural language to write computer code,” and crediting the coinage to Andrej Karpathy), available at https://blog.collinsdictionary.com/language-lovers/collins-word-of-the-year-2025-ai-meets-authenticity-as-society-shifts/. ↩
-
Sundar Pichai, “Cloud Next ‘26: Momentum and innovation at Google scale,” Google (Apr. 22, 2026) (“75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall.”), available at https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/; Stack Overflow, 2025 Developer Survey, AI section (reporting that “84% of respondents are using or planning to use AI tools in their development process,” and that 51% of professional developers use AI tools daily), available at https://survey.stackoverflow.co/2025/ai. ↩
-
17 U.S.C. § 102 (protection subsists in “original works of authorship”; § 102(b) excludes ideas, procedures, processes, systems, methods of operation, concepts, principles, and discoveries). ↩ ↩2
-
Thaler v. Perlmutter, No. 23-5233, slip op. at 3, 19 (D.C. Cir. Mar. 18, 2025) (reported at 130 F.4th 1039), available at https://media.cadc.uscourts.gov/opinions/docs/2025/03/23-5233.pdf, cert. denied, No. 25-449 (U.S. Mar. 2, 2026). ↩ ↩2 ↩3
-
U.S. Copyright Office, “Copyright and Artificial Intelligence, Part 2: Copyrightability” at iii, 18–20 (Jan. 29, 2025), available at https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf. ↩ ↩2
-
U.S. Copyright Office, “Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence,” 88 Fed. Reg. 16190 (Mar. 16, 2023), available at https://www.copyright.gov/ai/ai_policy_guidance.pdf; see 17 U.S.C. § 411(b)(1) (a certificate supports an infringement action despite inaccurate information unless the applicant included the information “with knowledge that it was inaccurate” and the inaccuracy, “if known, would have caused the Register of Copyrights to refuse registration”). ↩ ↩2
-
See U.S. Copyright Office, Review Board Opinions index, https://www.copyright.gov/rulings-filings/review-board/ (no published opinion addressing AI-generated software as of Aug. 31, 2026; the AI-era human-authorship opinions concern visual works); U.S. Copyright Office Review Board, Decision re Sunset LumenScript and LumenScript for Replicating the Sun as Seen from Mount Fuji (Mar. 16, 2017) (refusing registration of computer-program claims in spectrometer-captured light-data files because the data “are not the product of direct human authorship, but rather were created by a computer,” and analogizing to auto-generated HTML: “[i]f the website design software automatically creates the HTML code, the website designer is not considered the author of the resulting markup language” (quoting Compendium of U.S. Copyright Office Practices § 1006.1(A) (3d ed.))), available at https://www.copyright.gov/rulings-filings/review-board/docs/sunset-lumenscript.pdf. ↩
-
17 U.S.C. §§ 101, 103 (§ 101 defines a compilation by materials “selected, coordinated, or arranged” into an original work; § 103 makes compilations copyrightable subject matter, with the copyright limited to the compiler’s own contribution); Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340, 349–51, 357–58 (1991) (originality in the selection, coordination, and arrangement of preexisting material; “the copyright in a factual compilation is thin,” and “the copyright is limited to the particular selection or arrangement”). ↩
-
See 17 U.S.C. § 1202(b) (prohibiting the intentional, unauthorized removal or alteration of copyright management information by one knowing, or having reasonable grounds to know, that it will induce, enable, facilitate, or conceal an infringement); Doe v. GitHub, Inc., No. 4:22-cv-06823-JST, ECF No. 253 (N.D. Cal. June 24, 2024) (order dismissing the § 1202(b) claim with prejudice on the identicality rule; open-source-license contract claims survive), interlocutory appeal argued and submitted, No. 24-7700 (9th Cir. Feb. 11, 2026); posture verified as of August 31, 2026. ↩ ↩2