Possibly nobody, and the intellectual property clause in your development agreement does not fix that. It transfers whatever rights your vendor holds. If the code was generated by an AI without meaningful human authorship, your vendor holds no copyright in it, so a clause assigning all right, title and interest to you conveys an empty set. Nothing has been drafted badly and nobody has breached anything. You can hold a perfectly performed contract and still own nothing a competitor could be stopped from copying.
This is a general explanation of how US copyright doctrine interacts with a software development contract, not legal advice, and a vendor in another country may be governed differently. It is worth reading anyway, because the thing that determines the answer happens during development and cannot be reconstructed afterwards.
The rule itself is not controversial
The intellectual property firm McDonnell Boehnen Hulbert & Berghoff put the baseline plainly: in the United States, copyright protection hinges on human authorship, both case law and the Copyright Office agree that protection is available only for works created through human creativity, and so works predominantly generated by AI without meaningful human authorship are not eligible for copyright protection. They cite Naruto v. Slater in the Ninth Circuit and the Copyright Office’s own Part 2 Copyrightability Report.
Then comes the sentence that should interest anyone buying software. “When code is produced solely by an AI, companies cannot obtain copyright protection for that code. Because such output is ineligible for copyright, it may be freely used by anyone unless safeguarded by another form of legal protection.”
Writing on O’Reilly Radar, Sena Evren makes the same point from the builder’s side: code that a coding agent generated and you accepted without meaningful modification may not be copyrightable by anyone, and if a competitor copies it you may have no recourse, because it “sits in the public domain in everything but name.”
None of that is contested. What is striking is who the advice is addressed to.
Two layers, and your contract only touches one
Search this question and almost everything you find is written for an employee or a founder using a coding tool themselves. The advice is about reading your employment contract. Two law firms rank, a technical publisher ranks, an advisory firm ranks, and the vendor relationship, which is the single most common commercial setting in which somebody else writes your code, goes essentially unaddressed.
The advisory firm Sule is the only source in the set to name the distinction that makes the vendor case different. Ownership, they write, “works on two layers: what copyright law will protect, and what the AI provider’s terms give you by contract.” And then the line worth committing to memory: “You can win on the contract layer and still hold a weak copyright.” A provider’s terms “transfer whatever rights exist; they do not manufacture a strong copyright out of thin human input.”
They are describing an AI vendor’s terms of service. The same structure governs your outsourcing agreement, and with the same consequence.
What that does to a development agreement
Eight consequences follow for anybody buying software under a contract like this, set out below in roughly the order a buyer tends to run into them.
1. An assignment clause transfers rights, it does not create them
Every development contract contains some version of the same clause: the vendor assigns to the client all right, title and interest in the work product. That language is a conveyance. It moves existing property from one party to another, in the same way a bill of sale moves a car. It does not bring the property into existence.
So if a substantial part of your codebase was generated with little human direction, the position is not that your contract failed. It is that the clause worked exactly as written and there was less on the other side of it than you assumed. Your vendor did not withhold anything, did not breach, and may be entirely unaware of the issue. The gap is invisible in every document you would normally check: the statement of work looks fine, the deliverables were accepted, the invoices were paid, the assignment was executed.
The practical result is that a buyer who wants enforceable rights cannot get them from the assignment clause alone. What produces enforceable rights is the presence of human authorship in the work itself, which is a fact about how the vendor’s team actually worked, not a fact about your paperwork.
2. Work for hire does not put you in the vendor’s shoes
The O’Reilly piece lists among the settled propositions that the work-for-hire doctrine applies regardless of how code was generated, and that is right for the case it describes. An employee writing code within the scope of their employment produces work owned by the employer, who is treated as the legal author, and reaching for a coding agent during work hours does not change that.
The trap for a buyer is assuming the same rule reaches their vendor. It generally does not. An outsourcing vendor’s developers are that vendor’s people, not yours. In US copyright law the work-for-hire route reaches commissioned work only through a signed writing and only within a limited set of enumerated categories, and software is not comfortably one of them, which is precisely why development agreements are built on express assignment language rather than resting on work-for-hire.
That is not a technicality. It is the reason the reassuring in-house answer gives false comfort across a vendor boundary. When an employer owns an employee’s work, ownership arrives by operation of law and there is no gap to fall through. When a client buys from a vendor, everything depends on an assignment, and an assignment depends on there being a right to assign.
4. The fallback is trade secret, and outsourcing strains it
When copyright is unavailable, the standard answer is trade secret protection, and MBHB give it as theirs. They also, to their credit, undercut it in the next breath: there is an open question “whether AI-generated code qualifies as a trade secret when it was previously known and provided to the AI as training data”, and it would be a fact-specific analysis. Their recommendation is strict confidentiality and security measures to keep any trade secret claim viable.
Which is the problem, because trade secret protection requires that the thing actually be kept secret, and an outsourcing arrangement is the hardest environment in which to establish that. The code is written by people who are not your staff. It sits on infrastructure you do not control. The vendor’s commercial model frequently depends on reusing internal frameworks and components across clients, which is a feature they will advertise. Developers rotate onto other accounts, sometimes onto competitors’ accounts.
So the protection that survives the copyright failure is the protection that outsourcing itself puts under most pressure. That does not make it unavailable, and plenty of vendors run genuinely tight confidentiality regimes. It does mean the fallback needs to be actively engineered in the agreement rather than assumed.
5. The other half: licence contamination
Ownership is one exposure. The other runs the opposite way, and it is the risk of having taken on somebody else’s licence obligations without knowing.
Copyleft obligations travel with code. If you distribute software derivative of GPL-licensed code, you are required to release your own source under the same licence, and as the O’Reilly piece puts it, “‘I did not know’ is not a defense to a copyleft violation.” The relevant standard is substantial verbatim reproduction rather than functional similarity, which matters: a tool producing code that works like GPL code is a different thing from a tool reproducing GPL code word for word. The difficulty is that you cannot tell which side of that line your repository sits on without scanning it. FOSSA, Snyk Open Source and Black Duck are the tools named for the job.
Doe v. GitHub, which asks whether Copilot reproduces licensed code without attribution, is on appeal in the Ninth Circuit after the district court dismissed most claims. Both law firm sources report it. One widely discussed 2026 episode involving an AI rewrite of the chardet library relicensed as MIT was a public community dispute rather than a filed case, and it did not resolve. Worth knowing precisely because it is often cited as though it settled something.
6. Who is liable when the code fails
Separate question, equally unresolved. MBHB note that while traditional negligence and product liability principles still apply, “courts have yet to clarify exactly how responsibility for errors should be apportioned between AI tool developers and the companies that utilize these tools.”
Meanwhile the tool providers have been busy narrowing their end. As MBHB observe, providers display warnings to verify output and include warranty disclaimers that “seek to push much of the due diligence burden back onto the businesses integrating AI-generated code.” The O’Reilly piece adds a detail worth carrying into any vendor conversation: provider indemnification varies by plan tier, with consumer tiers typically narrower than commercial or API agreements, and no tier’s indemnity covers a downstream copyleft violation caused by contamination in your own codebase.
Stacked up, that means the liability for a defect or an infringement tends to land on whoever shipped the product, which in an outsourcing arrangement is usually the client rather than the vendor and is essentially never the tool provider.
7. What is settled, and what is still being argued
The O’Reilly piece does something rare in this genre and labels its own confidence, which is worth reusing. On its account, three things are settled: works lacking human authorship are uncopyrightable, work-for-hire applies regardless of how code was generated, and verbatim copying of GPL code violates the licence. Two things are emerging consensus without definitive rulings: how much human direction establishes authorship in an agentic workflow, and whether AI output reproducing training patterns counts as verbatim copying.
It also places two limits on the Thaler case that most commentary drops. That case involved a work created with zero human involvement, and it involved visual art, so “no court has yet applied the human authorship doctrine specifically to code output from an AI coding tool.” The Supreme Court declining to hear the appeal in March 2026 leaves the lower ruling standing and settles nothing nationally, since a cert denial is not an endorsement.
The nearest thing to a map for partial protection is the Zarya of the Dawn decision, where registration was granted for human-authored text and refused for AI-generated images. The principle a buyer can use today is that human-authored elements may be separately protectable even where generated code is not, which is why design documents and architectural records matter. Allen v. Perlmutter, involving hundreds of prompts plus manual editing, is undecided, and the Copyright Office there acknowledged the manual edits while still refusing registration for the AI-generated underlying elements. Anyone telling you this question is resolved in either direction is overstating it.
8. Where this becomes real, which is not a courtroom
Most code copyright claims never reach litigation, and framing this as a lawsuit risk misjudges where it bites. As the O’Reilly piece observes, the place these unsettled questions become concrete today is mergers and acquisitions due diligence and institutional fundraising, where acquirers and investors ask as a condition of closing. Acquisition diligence now routinely includes an AI codebase licence scan.
That reframes the whole thing for a company buying development. The scenario to plan for is not a competitor copying your product and you failing to stop them, though that is possible. It is a diligence questionnaire eighteen months from now asking what proportion of the codebase was AI-generated, what evidence of human authorship exists, and whether a licence scan has been run, at a moment when the answer changes a valuation and there is no time to fix it.
Every one of those questions is answerable cheaply if the artifacts exist and unanswerable at any price if they do not.
What to ask for before work starts
This is the useful conversion. Because authorship turns on how the work was constructed, the evidence lives in the vendor’s process, is invisible from outside, and cannot be reconstructed later. So it has to be a requirement in the agreement rather than a question at handover.
Ask for disclosure of which AI coding tools are used and on which plan tier, since indemnification differs. Ask for retained prompt logs or session records for the components that matter most. Ask that commit messages record architectural decisions and rejections rather than only outputs, because “restructured the module architecture and rewrote the error handling” is evidence of authorship in a way that “add rate limiting module” is not. Ask for architecture decision records that predate the code they describe. Ask for licence scan results at delivery, and ask who pays to remediate what a scan finds. Ask what the vendor reuses across clients, which is where the confidentiality question and the trade secret question meet. Then have a lawyer in the relevant jurisdiction look at whether your assignment clause is doing what you think, given all of the above.
None of this requires distrusting your vendor, and a firm that has thought about it will have answers ready. Some publish their approach: PowerGate Software, for instance, sets out how it uses AI in software development on its own site. Treat a published approach as a good place to start the conversation rather than as an answer to it, here and with any vendor, because what protects you is the artifacts in your repository at delivery and not a description on a website, including this one’s account of it.
What this page is not
It is not legal advice, and the two law firms quoted here say the same about their own writing. It describes United States copyright doctrine, and a vendor operating under another country’s law may face a different analysis, which is a reason to ask rather than a reason to relax.
There is no contract wording here, deliberately. Clause language copied off a web page into a real agreement is worse than no clause, because it reads as though somebody considered the problem. There is no ranking of vendors either, since we have not audited any, and the argument of this page is that you verify this with documents rather than reputation. The adoption figures sometimes quoted in this debate, including Microsoft’s chief executive estimating around thirty percent of production code as AI-generated and Meta’s projecting roughly half of its codebase, are reported here as statements those executives made, relayed via MBHB’s footnotes, and not as numbers we have checked.
