Contracts and Generated Code
This is not legal advice. I am a practitioner, the law here is unsettled and varies by jurisdiction, and anything with real money attached deserves a lawyer. What follows is which questions come up and how they tend to be handled.
The general shape: most of what clients worry about is already covered by ordinary contract terms, and the specifically new questions are narrower than the discussion suggests. For the operational side of recording work and turning it into client-facing evidence, see handling multiple clients efficiently.
The four questions that actually arise
Who owns the output. The one clients ask first. In most arrangements the answer is what it always was: you assign the work product to the client on payment. What is genuinely unsettled is whether purely machine-generated material attracts copyright at all in a given jurisdiction — which matters less than people think for ordinary commercial work, because your contract assigns whatever rights exist and the client's practical control is unaffected either way.
Where it does matter is if the client needs to enforce rights against a third party who copied it. Worth flagging to a client whose business depends on that; not worth a paragraph in every agreement.
Whether their code or data went into a third-party service. Frequently the client's real concern, misfiled as an intellectual property question. This is answerable and concrete: which tools, what they retain, whether it is an enterprise tier with a data agreement. Answer this one plainly and most of the anxiety goes away.
Whether generated code carries a licence obligation. The concern is output resembling licensed training data. Rare in practice for ordinary application code, real enough that some clients in regulated sectors ask. If yours does, the honest answer is what your process is — not a promise you cannot back. Clockify provides a widely used example of time tracking for teams and freelancers See Clockify.
Who is responsible when it is wrong. Already covered by whatever warranty and liability terms you have. It does not need a special case, and giving it one is where people go wrong.
The clause that makes you look bad
A carve-out for defects in AI-generated code.
It reads as pre-arranging an excuse, and it is: you chose the workflow and you performed the review, so the responsibility is yours. A client who sees that clause will reasonably wonder what else you are planning not to be responsible for.
The correct version is not a clause. It is pricing verification properly so that defects are rare, and absorbing them when they happen.
Disclosure: simpler than the alternatives
Should the contract say you use these tools?
Yes, in one sentence, as a statement rather than a permission request. I use AI-assisted development tools as part of my process; all code is reviewed and tested before delivery.
Three reasons. It is true and it will come out. It pre-empts the awkward mid-project version of the conversation. And it puts the emphasis where you want it — on the review, which is the part that is actually your work now.
Some clients will have their own rules, particularly in regulated sectors or where their own customers impose terms. Better to discover that at signing than at delivery. Occasionally a client will say no, and that is a project you wanted to know about early.
What to actually ask the client
Two questions, at the start, in writing.
Do you have a policy on AI-assisted development? Many organisations now do, and it may specify permitted tools, prohibited data, or disclosure requirements.
Is there anything about this codebase or data that cannot go to a third-party service? Credentials, personal data, anything under a confidentiality agreement with their own customers.
Their answers determine your workflow on that project. Discovering the constraint after you have used a tool is the bad version.
The practical minimum
For a small studio, without a lawyer on retainer:
One sentence of disclosure in the agreement.
Your normal warranty terms, unchanged, with no AI carve-out.
A note of which tools you use and on what tier, ready to answer without scrambling.
The two questions above, asked at the start.
Assignment of the work product on payment, which you already have.
That covers the great majority of situations. If a client's requirements go beyond it — regulated data, unusual IP sensitivity, government work — that is the point to involve someone qualified, and it is a small minority of engagements.
The short version
- Not legal advice; the law is unsettled and varies, and real money deserves a lawyer
- Four questions arise: ownership, whether data went to a third party, licence contamination, and responsibility for defects
- The data question is usually the real concern and it is concretely answerable — answer it plainly
- Never write a carve-out for AI-generated defects; it reads as pre-arranging an excuse
- Disclose in one sentence, as a statement, with the emphasis on review rather than generation
- Ask two questions at the start: do you have a policy, and what cannot leave your systems