Code ownership when half the code came from an AI

Published 2026-05-11 by Owner

A question that has started showing up in team Slacks and engineering all-hands: if Copilot wrote sixty percent of the function, who owns it?

The legal answer and the practical answer are both “you do” — but for different reasons, and the practical answer comes with more consequences. The legal answer is mostly good news. The practical answer contains a trap.

This is not legal advice. The law in this area is unsettled and jurisdiction-dependent. What follows is a description of where the norms and case law are trending as of 2026, and what engineering teams have started doing in response. For anything with real legal stakes, consult counsel.

The legal picture as of 2026

The US Copyright Office has declined to register works where a human did not exercise sufficient creative control. The threshold cases have consistently landed on the side of “AI output alone is not copyrightable.” The human who directed, curated, and integrated the AI’s output is the author — but the AI’s contribution itself does not attract copyright protection.

The practical implication for working engineers: the code that Copilot, Cursor, or Claude produced is not owned by Microsoft, OpenAI, or Anthropic by default. The standard terms of service for these tools assign output to you, the user. The AI company does not claim copyright in the suggestions; it cannot, because the underlying output isn’t independently copyrightable.

What this means in practice:

Your employer owns the code under work-for-hire doctrine the same way it would own code you typed manually
You can ship AI-assisted code under an open-source license — the AI company has no claim to assert
Third-party training data copyright concerns (i.e., did the model regurgitate someone else’s code verbatim) remain a live question, but the cases litigated so far have mostly not succeeded on those grounds

The directional summary: you have more ownership than many people assume, and the AI company has less. The interesting legal risk is not “who owns this” — it’s “does this snippet reproduce copyrighted training data without sufficient transformation,” which is a separate question and not the main concern for most original application code.

One nuance that matters for teams using AI coding tools at scale: if a developer takes a model’s output with minimal modification and ships it, the human creative contribution is thin. The Copyright Office’s threshold language is “sufficient creative control” — directing, selecting, curating. A developer who reviews, integrates, adapts, and tests AI-generated code is well inside that threshold. One who pastes suggestions without engagement is at the fuzzier edge. This is not a legal exposure most teams face in practice, but it’s worth knowing the principle that separates “I directed this” from “I forwarded this.”

Attribution conventions teams are adopting

When AI tooling generates a meaningful portion of a commit, a small but growing set of teams have started adding an attribution line to the commit message. The convention borrows from the Co-Authored-By: trailer format that GitHub already surfaces:

Co-Authored-By: Claude Sonnet 4.5 <claude@anthropic.com>
Co-Authored-By: GitHub Copilot <copilot@github.com>

The email is notional — there’s no inbox — but the trailer format is parseable, and some tooling has started indexing it.

Why bother? Three reasons:

Auditability. If a compliance question comes up about provenance of a specific function, the commit history can answer it. The alternative is everyone trying to remember, which doesn’t work.

Honest PR descriptions. A PR description that says “implemented X” when Copilot produced the core implementation and the human did the integration and cleanup is not wrong, but it obscures something. “Implemented X; core data transform was AI-generated, manual work was integration and tests” is more accurate.

Team calibration. If a team tracks attribution over time, they can see which kinds of work are AI-generated at what rates. Some teams find this useful for estimating and resource planning. Others find it anxiety-provoking and skip it. Either is a valid choice.

What most teams do not require: attribution on every single line, comments in source files marking AI-generated sections, or separate branches for AI vs. human contributions. That overhead is not worth the signal it provides.

A few things to consider before adopting any attribution convention:

Retroactive incompleteness. If the convention starts mid-project, the absence of a tag on older commits says nothing about whether AI was involved. This is fine — just document when the practice started.
Granularity is a judgment call. Some teams tag any session where AI touched the code; others only tag when AI wrote more than half. Either is defensible. The goal is reviewer awareness, not archaeological precision.
It’s a norm, not a control. Attribution in commits is for humans reading the history. It doesn’t change what the code does, doesn’t affect licensing, and can’t be automatically enforced. Treat it as a professional convention, not a compliance mechanism.

A worked PR description convention from a mid-size fintech team:

feat: add idempotency key validation to payment endpoint

- Added idempotency key header check before processing
- Returns 409 if duplicate key found within 24h window
- Tests cover happy path, duplicate key, and key expiry

AI assist: Claude drafted the Redis key schema and
the 409 error branch. Manual: business logic for
expiry window, integration with existing auth middleware.

This took about 30 seconds to write and answers any future questions about what was reviewed carefully vs. what was spot-checked.

The “I didn’t write this but I own it” mindset

Here is the shift that matters more than any policy: the moment a developer accepts an AI suggestion, the code is theirs. Not “theirs to use” — theirs to own, maintain, debug, and explain.

This sounds obvious but the behavior it should produce often does not follow. A common pattern: a developer accepts a suggestion without fully reading it, the suggestion has a bug or a subtle incorrect assumption, and the developer’s mental model of the code does not include that section because they didn’t write it. Six months later, something breaks, and the developer has to orient in code that is partly theirs and partly a foreign object.

The practical fix: review AI suggestions as carefully as you would review a PR from a senior colleague you trust but do not always agree with. That colleague might be right. They might be wrong. They might have missed context you have. You are the one who knows the full system; they only know what was in the prompt.

Some specifics:

Don’t accept suggestions you can’t explain. If a Claude suggestion produces a working result but the mechanism isn’t clear, spend two minutes understanding it before accepting. If it takes longer than two minutes to understand, it probably needs a comment — which you write.

Variable names and idioms are part of ownership. If the AI generated a function with variable names that don’t fit your conventions, rename them. Accepting a suggestion without adapting it to your context is how codebases end up with inconsistent style in the same file.

Spot-checking tests is not enough. AI-generated tests often test what the code does, not whether what the code does is correct. Writing at least one test yourself forces you to engage with the specification rather than the implementation.

Read the whole function, not just the output. Inline completions are the easiest place to accept something without reading it fully. The function looks right in the diff because the visible change matches expectations. The problem is often in what the function does in an edge case the prompt didn’t mention. If a function is more than five lines, read all five — or however many — before accepting.

One org’s policy

A 40-person SaaS company that ships developer tooling has this in their engineering handbook (paraphrased):

When an AI tool generates more than roughly half the substantive logic of a function or module, note it in the PR description. No specific format required — the intent is that reviewers know which sections to focus on. Reviewers should treat AI-generated sections the same as any other code: they are responsible for approving it. Once a PR is merged, the attribution note is informational; the author of record is the engineer who submitted the PR.

What they explicitly do not require:

Line-by-line attribution comments in source files
A separate review process for AI-generated code
Tracking AI usage rates for performance evaluation

The rationale from their CTO: “We want people to use AI tools productively. The attribution note exists so reviewers don’t skim the AI sections under the assumption that a human carefully wrote them. That’s it.”

This is a reasonable baseline. It adds minimal friction, surfaces the relevant information at the moment it’s useful (code review), and doesn’t create ongoing maintenance overhead in the source files.

When the AI wrote the bug

The accountability structure here is simple and worth stating directly: if an AI wrote the bug and you accepted it and shipped it, you wrote the bug.

Not in the sense that you deserve blame for the tools available to you. In the sense that the accountability stops with you, not with the tool. You can’t escalate a production incident to Anthropic. You can’t explain in a postmortem that Claude was responsible for the misconfigured timeout. The engineer who accepted the suggestion and the engineer who approved the PR are the accountable parties.

This isn’t punitive — it’s structural. The AI has no stake in the outcome, no ability to respond to an incident, no context about your production environment. The humans in the loop are the ones who can respond, who knew (or should have known) the requirements, and who made the deployment decision.

The practical consequence: “I didn’t write this” is not a useful frame once the code is in production. The useful frame is “I own this” — even if that means owning a bug that a tool produced and you accepted.

This also affects how postmortems should be written. An incident postmortem that says “AI generated the flawed logic” is not useful unless it goes on to explain why the review process didn’t catch it, what context was missing from the prompt, and what the team will do differently. The AI is a contributing factor at best; the postmortem should focus on the human process around it.

A pattern that helps: when an AI generates infrastructure-adjacent code (database queries, authentication logic, data serialization), the bar for personal understanding before acceptance should be higher than it is for utility functions or boilerplate. The bugs in infrastructure code are the ones that matter in production.

One earned insight from teams that have been through this: the engineers who have the best outcomes with AI coding tools are not the ones who generate the most code — they’re the ones who accept the least AI output without understanding it. Volume is not the metric. The metric is how much of your codebase you can explain under pressure.

The ownership mindset is not a constraint on AI tooling — it’s what makes AI tooling sustainable. Teams that treat AI suggestions as foreign objects to be copy-pasted accumulate code nobody fully owns. Teams that treat AI suggestions as drafts to be reviewed, integrated, and claimed end up with codebases that function like any other: maintainable, understandable, and the clear responsibility of the people who built them.

This distinction also matters for onboarding. A new engineer joining a team where AI-generated code is clearly marked and actively owned can get oriented quickly — the code has authors, has intent, has been adapted to the context. A new engineer joining a team where large sections were accepted from AI sessions with minimal review encounters a codebase that is technically functional but harder to reason about. The original prompts are gone; the AI’s implicit assumptions are not documented; nobody remembers why a particular approach was taken. Attribution and ownership practices are partly for today’s reviewer and partly for next year’s new hire.

The norms described here are still forming. The Co-Authored-By convention is ad hoc. The attribution policies vary by org. The legal framework is still catching up to how widely these tools are used. What is not forming — it’s already settled — is where the accountability sits. That part is not going to change.

The tools are going to keep getting better at generating plausible-looking code. The human judgment about what to accept, what to modify, and what to discard is what keeps the codebase coherent. Ownership is not a formality imposed by policy — it’s the practical prerequisite for a codebase that a team can continue to build on.