Does a contract need to say the vendor is allowed to use AI to write code?

Most contracts do not name the tool a vendor uses to write code, the same way they do not name which editor an engineer typed in. What the contract needs is a definition of done that does not depend on trusting the process, because that protects you whether the code was typed by hand or generated in seconds.

Why does acceptance criteria matter more when a vendor uses AI?

Because AI can produce a large amount of working-looking code fast, and fast output is not the same as correct output. A demo that runs only proves the demo runs, so the contract should require a check suite, written from the specification before the code, that you can run yourself and that fails when a stated guarantee breaks.

Can AI-generated code be copyrighted?

The US Copyright Office ruled in a report dated January 29, 2025 that a work with no human authorship cannot be registered for copyright, and a U.S. appeals court reached the same conclusion in March 2025 in a case about a fully AI-generated image. Code written entirely by an AI system with no human direction sits in the same uncertain position, which is why a contract should state who directed the work and assign ownership explicitly rather than assuming copyright will sort it out.

How should an IP ownership clause be written for AI-assisted code?

It should say plainly that the vendor assigns all rights in the delivered code to the client, describe the human role in producing it (specification, review, direction), and require the vendor to disclose any third-party or open-source code the AI output may have drawn on. That disclosure matters because pending litigation over AI coding tools centers on exactly this question: whether AI-generated suggestions can carry someone else's license terms with them.

Does liability change when AI writes the code?

The standard should not change: liability sits with the vendor company, not with whichever engineer or tool produced a given line. What should change is that a "named engineer reviewed this" clause stops meaning much, since a person can review generated code quickly without having reasoned through the same decisions they would have made writing it by hand. A better liability anchor is the check suite: what it proves, what it does not, and who is on the hook when something breaks that no check caught.

What stays the same in a contract when a vendor uses AI to write code?

Payment terms, the exit and handover list, warranty periods, confidentiality, and data handling do not change because the code was AI-written. Those clauses protect you against risks that have nothing to do with how the code was produced: a vendor going quiet after final payment, a warranty period with no teeth, or data leaving your systems in ways you did not agree to.

Should a contract require a human to review every AI-generated pull request?

A review requirement is worth less than it sounds, because reviewing a plausible-looking pull request quickly is easy and catching a subtle logic error is not, whether the code was written by a person or a model. A check suite that runs the specification's guarantees against the code is a stronger and more checkable commitment than a line saying someone looked at it.

What happens if the contract is silent on AI-generated code and a dispute comes up later?

Silence usually resolves in the vendor's favor, because the client has no written standard to point to and ends up arguing about intent instead of evidence. Naming the acceptance method, the ownership assignment, and the accountable party in the contract removes that argument before it starts, regardless of which side would have won it.

Is a fixed price still workable when AI speeds up delivery?

Fixed pricing was never about how fast the code gets written, it was about how well the work is specified. AI changes the speed of typing, not the difficulty of knowing what "correct" means for a novel piece of business logic, so the same rule applies: price fixed only what a specification can describe precisely enough to check.

What changes in a contract when AI writes the code: Reveneau

A client sent us a draft services contract last month and asked a fair question: what has to change in here because you use AI to write the code? Their legal team had marked up the whole document, worried that an AI-written codebase needed a different kind of agreement from top to bottom. We read it and found three clauses that actually needed new language. The rest of the contract, the parts about payment, exit rights, confidentiality, was already fine.

That gap, between what people expect to change and what actually changes, is what this piece is about. Here is what needs rewriting, and what a good contract already covered.

Acceptance criteria has to point at a check, not a demo

The old version of "done" was a sign-off meeting. Someone from the vendor walks the client through a demo, the client asks a few questions, everyone nods, and the invoice goes out. That was always a weak standard, because a working demo only proves the demo works. It says nothing about the paths nobody clicked.

AI-assisted delivery makes that weakness expensive instead of just risky. A vendor using AI to write code can produce a large volume of plausible, functioning-looking code in a fraction of the time it used to take. Volume was never proof of quality. When volume gets cheap, a client still grading on volume or demo polish is grading on the wrong thing.

The fix is to write acceptance as a check suite, not a meeting. That means a set of automated tests, written from the specification before the code exists, that the client can run on their own infrastructure and that fails when a stated guarantee breaks. This is not a new legal concept. Acceptance testing clauses already exist in standard technology contracts, and the well-established version sets a review period, a defect-reporting method, a standard for what counts as a material failure, and a process for correction and retesting, as described in Thomson Reuters Practical Law's summary of acceptance testing provisions. What changes is which artifact does the proving. Instead of a person watching a walkthrough, the contract should name a runnable suite as the thing that has to pass.

If your contract still says "delivered to the agreed specification" with no attached method for checking that, rewrite that line first. It is the single clause where the gap between a fast vendor and a careful one shows up.

IP ownership needs an explicit clause, because the default is unsettled

Most software contracts assume copyright will just work: the vendor writes it, the contract assigns it to the client, done. That assumption weakens when a person did not write most of the code by hand.

The US Copyright Office addressed this directly. In a report dated January 29, 2025, the Office confirmed that human authorship is required for copyright protection, and that a work generated entirely by AI, with no meaningful human creative contribution, cannot be registered, a position it had first stated in guidance back in March 2023, according to Skadden's summary of the report and Jones Day's analysis of the same ruling. A federal appeals court reached the same conclusion in March 2025 in Thaler v. Perlmutter, a case about an image generated entirely by an AI system with no human author, and the U.S. Supreme Court declined to review that ruling in March 2026, leaving the human-authorship requirement in place, as reported by Holland & Knight.

That case was about a single image, not a codebase, and the courts have not ruled on where the line sits for software written with heavy AI assistance but real human direction: a specification, a review process, deliberate editing. That is precisely why leaving it unaddressed in a contract is a bad idea. If nobody states who directed the work and assigns ownership on that basis, you are relying on a legal question that has not been fully settled to protect an asset you paid for.

The clause should do two things. First, it should describe the human role in producing the code: who wrote the specification, who directed the generation, who reviewed and accepted it. Second, it should require the vendor to assign all resulting rights to the client and disclose any third-party or open-source material the AI output may have drawn from. That disclosure is not a formality. A pending case against GitHub, Microsoft, and OpenAI over the Copilot coding assistant, filed in 2022 and still working through appeal at the Ninth Circuit as of early 2026 according to BakerHostetler's case tracker, turns on exactly this question: whether AI-generated code can carry someone else's open-source license terms with it, unlabeled, into a codebase that did not ask for them. You do not want to discover that question inside code you have already shipped.

Liability has to name the company, never a person

Contracts used to lean on a person's name as an informal quality guarantee: a senior engineer signed off, so the risk felt covered. That guarantee was always soft, since people leave and the responsibility leaves with them. It becomes actively misleading once a person can review a large volume of AI-generated code quickly. Reading through a plausible-looking pull request is fast. Reasoning through every decision the way you would if you had written it yourself is not, and skimming does not carry the same weight it used to when the code in front of you took a human day to produce.

So the liability clause should not lean on who touched the code. It should name the company as accountable for the outcome, full stop, through delivery and after release. And it should tie that accountability to something checkable: the same check suite from the acceptance clause, plus a stated warranty period and a defined response time if something breaks that the checks did not catch. Standard limitation-of-liability structures in technology contracts already do something close to this: a cap tied to fees paid over a set period, with carve-outs for things like confidentiality breaches or willful misconduct, is common in commercial software agreements, as described in Koley Jessen's overview of limitation of liability provisions. None of that structure needs to change. What needs to change is dropping any clause that implies a named individual's review is the safety net. That safety net was always thinner than it looked, and AI-assisted delivery is the moment it stops holding weight at all.

What does not change

Payment terms do not change. Whether code was typed by hand or generated from a specification, the question of what triggers an invoice is the same question it always was, and the right answer is still a verifiable milestone rather than elapsed time.

The exit and handover list does not change. Repositories, credentials, infrastructure definitions, and a runbook are what let you leave a vendor without losing the system, and that list has nothing to do with how the code was produced.

Confidentiality and data handling do not change. Those clauses protect against a different risk entirely: information leaving your systems in ways you did not agree to.

Fixed-price scoping does not change either, and this one surprises people. A fixed price was never about how fast a vendor could type. It was about how precisely the work could be specified in advance. AI changes the speed of production, not how well-defined a novel piece of business logic is before anyone starts building it. The old rule holds: price fixed only what a specification can describe precisely enough to check, and treat anything vaguer as a phase you scope separately.

The short version

A vendor using AI to write code is still the same vendor: something you have to verify, own, and hold accountable when it breaks, only faster now. Three clauses need new language to keep up with that speed. Everything else in a well-written contract was already built to survive it.

Sources

US Copyright Office report via Skadden, Arps, Slate, Meagher & Flom: confirms the January 29, 2025 Copyright Office report requiring human authorship for copyright protection.
Jones Day analysis of the Copyright Office report: additional detail on the human authorship requirement and mixed human-AI works.
Holland & Knight on Thaler v. Perlmutter: confirms the March 2025 appeals court ruling and the March 2026 Supreme Court denial of certiorari.
BakerHostetler's GitHub Copilot litigation tracker: status of the pending Doe v. GitHub case over AI-generated code and open-source license terms.
Thomson Reuters Practical Law on acceptance testing clauses: standard structure of acceptance testing provisions in technology contracts.
Koley Jessen on limitation of liability provisions: standard structure of liability caps in software license agreements.