Three contract clauses I added after AI changed how I deliver code
At the last project handoff, the client asked: "Can you show me where you wrote the code yourself and where the AI did it?"
Two years ago I'd have scrambled — pulled up git blame, started explaining things that weren't actually in question. Today there's one contract clause that ends that conversation in five seconds. Not because it's a legal shield, but because it sets the right framing before the question even comes up.
There are three of these clauses now. Here's where they came from.
Why old contracts don't cover this
Most development contracts were written before AI tools became part of daily work. They cover deadlines, code ownership, payment terms. They don't answer the questions clients are asking in 2025 and 2026.
One in five handoffs I've been part of recently touches the AI topic. Not because clients are adversarial. They read the same news you do. They've heard AI writes code. They're not sure what that means for their project, their IP, or their support contract.
Silence in the contract isn't a neutral position. It's an open invitation to improvise at the worst possible moment. I've done that improvisation. Then I wrote three clauses.
Clause 1: AI tools are the contractor's tools
AI assistants are my tools, the same way a code editor or a linter is. The result belongs to the client in full. Responsibility for quality is mine, regardless of which tool was used to produce it.
Clients sometimes assume that if "AI wrote the code," then "the AI made the error, not the developer." This clause removes that ambiguity directly: it doesn't matter what was used. What matters is what was signed.
I use Claude Code to write tests, refactor, and triage logs. If a test is wrong, it's my wrong test. The contract fixes that position before any dispute, not during one.
It also closes IP questions. "Who owns the prompts?" — nobody, that's my workflow. "Who owns the output?" — you do, as stated in the rights section.
One client asked: "If AI generated a sorting algorithm, is that your code or OpenAI's?" I pointed to the clause, read two sentences aloud. The conversation ended. Without it, I'd have spent forty minutes explaining and still left them uneasy.
Clause 2: tooling dependency
If a tool the contractor uses changes its terms or shuts down, that doesn't affect the project timeline or contract terms. Support for the deliverable is provided by the contractor, not by any specific AI tool.
Without this clause, clients worry: "You use Claude Code. What if Anthropic closes the API or raises prices?" And "I'll find another tool" isn't a real answer. It's a new anxiety.
The clause turns that into: these are my tools, they can change, your code is a static artifact that runs in your infrastructure. My dependencies are my problem, not yours.
I ran into this after Microsoft shut down one of its AI integrations. A client read the news and messaged: "Do we have anything about this in our contract?" As of that moment, yes.
The clause also works in reverse. If a client later asks "do you still use AI?" — same answer. I can change tools. Your code doesn't change.
Clause 3: completion is defined by results, not method
Work is considered complete when the result meets the agreed acceptance criteria. The contractor's methods, time spent, and tools are not part of the acceptance process.
This is the most important of the three. Because it directly addresses the core question of the AI era for studios and freelancers: "You used AI so you worked less — shouldn't it cost less?"
No. Work isn't priced by hours. It's priced by the result, the risk assumed, what the client walks away with. If I can solve a problem faster, that's my expertise, not your discount.
A surgeon with a better instrument doesn't refund the difference because the procedure took less time. That's a blunt argument — but it's the one that stops this conversation. The contract clause gives it a foundation: "We actually wrote this down, here it is."
This pairs well with the AI discount conversation I wrote about earlier. That post was about handling the negotiation in real time. This one is about preventing it from starting.
How these three clauses work together
They're not legal armor. A good lawyer can pull them apart in a meeting.
But I'm not trying to win a dispute. I'm trying to not have one.
These clauses frame the conversation before it becomes a conflict. Clients read the contract before the project starts. Or I walk through the key points at kickoff. Questions about AI come up there, where they're easy to answer, not at handoff where stakes are high.
My internal rule — AI for internal tools only, never client-facing features — created the context for Clause 1. An honest answer to "how I work with AI" became part of the contract, not something I improvise under pressure.
What to do tomorrow
No lawyer required to start.
Open the current contract. Find the "rights to deliverables" and "acceptance criteria" sections. That's where these additions go.
In the tools section, add: "The contractor may use any software tools, including AI assistants, at their discretion. Full responsibility for deliverable quality remains with the contractor."
In the acceptance criteria, add: "Acceptance is based on the deliverable meeting the agreed specifications. The contractor's methods and tools are not subject to acceptance review."
That's enough to make the next handoff conversation go differently.
More on how I set expectations with clients before projects start: closing risks, not tickets.