Imagine your AI assistant just produced 200 lines of code. Legally, you may not own a single line of it but legally, you're still on the hook for every bug it ships. Here's the gap between those two sentences, and what it means for the code you merge tomorrow.
That's the gap this whole topic lives in. The tool that produced the code can't be sued. The model can't be held accountable. The vendor's contract has already made it clear, in language most developers never read, that responsibility flows downhill, to the human who pressed Tab.
The interesting part isn't that this gap exists. It's that almost nobody in engineering treats it like it does. We've spent two years celebrating the productivity, and a much smaller fraction of that time figuring out what to do when the velocity meets a copyright claim, a compliance audit, or a production incident. Let's break it down: what courts have actually said, what your tool's contract actually says, where the legal cliffs are, and how a sane engineering team handles the whole thing without either banning AI or pretending the question doesn't exist.
The Handoff That Nobody Signed
Software ownership used to be a settled question. You wrote the code, your employer paid you to write it, your employment contract assigned the copyright to them, the company shipped it under whatever license they preferred. Three parties (you, your employer, the user) and the lines between them were clean. If something broke, the user complained to the company, the company looked at the commit history, and someone got a quiet conversation in a one-on-one.
AI assistants slide a fourth party into that picture, and the contract for that party doesn't look like any of the others. The model didn't sign your employment agreement. The vendor isn't part of your release process. Their EULA isn't shaped like a hiring contract; it's shaped like a disclaimer. You get the suggestion, you keep the suggestion, and you also keep everything that comes attached to it: the bugs, the license obligations, the security holes, and whatever future regulator decides to inspect how the suggestion got there.
That handoff happens silently. There's no checkbox in your IDE that says "I accept legal responsibility for this completion." You just hit Tab. The interface is designed to feel like autocomplete, and most developers extend the mental model of autocomplete to it: the editor is helping me type faster, the code is still mine, my ownership of the codebase is unchanged. That mental model is almost right and almost completely wrong, depending on which question you're asking.
What Courts Have Actually Decided
Two things sit at the heart of the legal picture in the United States right now, and both of them surprise developers when they hear them.
The first: in the U.S., copyright protection requires a human author. That isn't a new rule. It's the same rule that decided a monkey couldn't claim copyright on a selfie back in 2018, but it got freshly stress-tested in Thaler v. Perlmutter, a case about an image generated by an AI system without meaningful human input. In March 2025, the D.C. Circuit affirmed the lower court's ruling: the Copyright Act of 1976 "requires all eligible work to be authored in the first instance by a human being." No human author, no copyright. The output sits in the public domain.
The second, which is where developers actually live: the U.S. Copyright Office spent 2024 and early 2025 trying to draw a line for AI-assisted work that does involve a human. In January 2025, the Office published guidance saying that AI outputs are eligible for copyright only when a human contributes "sufficient expressive elements." Prompting alone, even sophisticated, iterative prompting, isn't enough. One comment quoted in the Office's report reached for a metaphor that hit developers harder than they expected: repetitive prompting is like spinning a roulette wheel. The human chose, but the human did not control the expressive elements of the output with enough specificity to be considered the author.
That metaphor matters more than the wording around it. "Tab to accept" is, in copyright terms, spinning a wheel. "Tab to accept, then rewrite four lines, restructure the function, add a guard clause, and integrate it into a class you already designed" is something else. That's where the human contribution starts becoming the kind of expressive control the Office is looking for.
The practical fallout: code that comes out of your AI tool more or less untouched may not be your company's property the way the code your senior engineer wrote last week is. It isn't stolen, but it also isn't copyrightable to your employer in any way that gives them the usual enforcement options. They can't sue someone who copies it. They can't claim it as a defendable asset. They can publish it, ship it, modify it, but the legal moat around it is thinner than they think.
The picture changes once you cross a border. The United Kingdom has had Section 9(3) of the Copyright, Designs and Patents Act 1988 on the books since the late 1980s, and it explicitly addresses "computer-generated works," assigning authorship to "the person by whom the arrangements necessary for the creation of the work are undertaken." India follows a similar approach. The EU is in the middle of a more ambitious reframing through the AI Act, which we'll come back to. The point: there is no single global answer right now. The code your team writes from a London office may have a clearer ownership story than the same code written from San Francisco, on the same model, in the same week.
What Your Tool's Contract Actually Says
Here is the sentence in GitHub's Copilot Product Specific Terms that does most of the work, and the sentence nobody quotes at AI adoption meetings:
"You retain all responsibility for your Code, including Suggestions you include in your Code or reference to develop your Code."
That sentence is doing two things at once. It hands you something: GitHub says it doesn't claim ownership of the suggestions, so they don't show up as a competing claim against your codebase. And it hands you something else: every legal risk that travels with those suggestions. Open-source license obligations from training data. Copyright claims from other developers whose code looked similar. Defects in the suggestion itself. The vendor's terms are explicit that you are responsible for determining whether your use of an output requires a third-party license and for complying with any such license.
If you read GitHub's Customer Agreement the way developers read README files, skimming for the install instructions, you miss that line. If you read it the way a lawyer reads it, that line is the whole document.
This shape isn't unique to Copilot. The same pattern shows up in nearly every AI coding assistant's terms: vendor disclaims ownership of outputs, customer accepts responsibility for outputs. The reason it's the same pattern is that it's the only shape that lets the vendor operate. Imagine the alternative, where the vendor warrants that every suggestion is clean of license obligations, free of bugs, and immune to copyright challenge. They can't make that promise about a model trained on the entire public corpus of GitHub. So the contract pushes the risk to the only party who can plausibly evaluate it: the human merging the code.
The model can't read your codebase's license terms. The vendor doesn't know what regulator your industry answers to. The IDE doesn't know whether the project you're working on is a hobby site or a payments processor. The only place to anchor responsibility is where the merge button lives.
The Indemnification Gap Nobody Mentions In Onboarding
Here's where the contract gets uncomfortable, and where most engineering org charts have a blind spot.
GitHub does offer IP indemnification for suggestions, if you're on a Business or Enterprise plan. If you get sued for copyright infringement because Copilot reproduced a snippet of someone's code, Microsoft will step in to defend you and pay damages under its Customer Copyright Commitment. The same pattern holds across the industry: most major AI coding tools offer some form of indemnification at the enterprise tier.
If you're on the Individual plan, none of that applies. You get the same model, the same suggestions, the same risk surface, and zero legal cover. If a court eventually rules that a snippet Copilot suggested to you was a substantial reproduction of someone else's GPL-licensed code, you, personally, are the one with the problem.
The reason this matters beyond the lawyer's office: a lot of professional software still ships from teams where engineers use their personal Copilot subscriptions, either because the company hasn't standardized yet, or because someone signed up six months before the company adopted an enterprise tier, or because they like their personal account's settings better. The code those engineers produce flows into the company codebase, and the indemnification that the company assumes it has, because the company is paying for Enterprise, doesn't actually cover suggestions that were made through the personal subscription.
Engineering leaders almost never audit this. The procurement team thinks the Enterprise contract covers everything. The developers don't know the contract draws a line at which subscription emitted the suggestion. The CISO finds out only if a lawsuit lands.
A clean accountability story requires every IDE, every developer machine, and every shared environment to be running the indemnified tier. "We bought Enterprise" is not the same as "every suggestion that touches our repo came from Enterprise."
The 65-Lexeme Filter And What It Doesn't Catch
If you read GitHub's safety documentation, you'll find a feature called the duplicate detection filter. The filter checks suggestions against public code on GitHub, and if a suggestion contains a code segment of about 65 lexemes or more (roughly 150 characters, the length of one or two paragraphs of dense code) and matches public code closely enough, the suggestion is suppressed. Administrators can enable this filter at the enterprise level, and most reasonable adoption guidelines tell you to keep it on.
The filter is the single most-cited mitigation when teams talk about Copilot license risk. It's also a great example of the gap between "a feature exists" and "the feature solves the problem."
The 65-lexeme threshold isn't arbitrary. It's a tradeoff between recall and usefulness. A filter that suppressed any three-token match against public code would suppress almost every Copilot suggestion, because three-token sequences appear in nearly all open-source projects. So the threshold sits well above that, in a band where matches are likely to be intentionally similar rather than accidentally similar. Reasonable design. The cost is that anything under that threshold flows through unfiltered.
A 30-lexeme function body that exactly matches a snippet from a GPL-licensed repository can land in your codebase, and the filter never sees it. A 50-lexeme idiom, a common algorithm implementation, a parser fragment, a serialization helper, can land identical to dozens of repositories without ever crossing the line. The filter isn't claiming to catch everything. It's claiming to catch the long-form near-duplicates that are most likely to support a copyright claim. The short-form stuff lives in a grey zone where the law itself hasn't decided what "substantially similar" means.
This is the part where you make a defensible call instead of a perfect one. The filter helps. Treating it as a complete solution doesn't. Treat it like the spam filter in your inbox: useful, often quietly correct, but not a substitute for not opening attachments from strangers.
The Regulators Don't Care Who Wrote It
The U.S. copyright conversation focuses on ownership. The European regulatory conversation focuses on responsibility for outcomes, and the framing is genuinely different.
Three pieces of EU legislation are converging into what some practitioners are calling the "Compliance Trinity": the AI Act, the Cyber Resilience Act (CRA), and the Product Liability Directive (PLD). Each one approaches AI from a different angle. The AI Act regulates AI systems by risk class, the CRA imposes cybersecurity obligations on connected products, the PLD attaches liability for defective products including software. They all share a common assumption: regulators do not care whether your code was written by a human, an AI tool, a contractor, or a small team of trained ferrets. They care about the product that reaches the market.
August 2, 2026 is the milestone most developers will hear about. It's when many of the AI Act's substantive obligations kick in, including transparency requirements for AI-generated content and active enforcement powers. Plain developer-assistance AI use generally doesn't drag a system into the high-risk category by itself, but AI used for things like worker evaluation or critical-component generation absolutely can. The classification depends on what the system does in the world, not on what tool helped write it.
The harder shift is the cultural one this implies. Before AI assistants, the was-it-written-carefully question and the is-the-product-safe question pointed at roughly the same thing: the people who wrote the code were also the people responsible for it. With AI assistants involved, the two questions can drift apart. The product can be unsafe even if everyone who reviewed the diff would swear they read it carefully. The regulator doesn't accept "the AI suggested it" as an explanation any more than they would accept "the contractor wrote it." You shipped it; you're responsible for it.
That's a clean framing, once you accept it. The discomfort comes from a half-formed expectation that AI tools come with a kind of distributed responsibility, that the vendor shares the blame because they trained the model. They don't. They explicitly don't, contractually. And the regulators have politely declined to invent that kind of shared responsibility either.
The Cultural Problem Nobody Warns You About
Outside the legal text, there's a softer pattern that quietly erodes accountability inside engineering teams, and it has nothing to do with contracts.
Researchers studying AI-assisted development have started to document something most senior engineers already feel: code that comes out of an AI assistant tends to get less careful review than code a human typed. Reviewers spend less time on it. They flag fewer issues. They're more likely to wave through a function that compiles and looks reasonable. Part of this is fatigue, because there's more code to review now than ever, now that the typing constraint that used to throttle output is gone. Part of it is implicit trust: the model has read more code than any reviewer alive, so its output gets a small unconscious authority bump. Part of it is just the design of the interface, which makes acceptance the default and rejection the friction.
The problem isn't that any of those reactions is unreasonable on its own. It's that they compound in the direction of less accountability, not more. The diff is twice as long, the review is half as careful, and the person who would normally have asked a sharp question about a defensive null check is busy scrolling through the next three suggestions. The unit of human attention per line of merged code drops, and so does the chance of catching the bug, the license issue, or the subtle authorization mistake that the model didn't realize it was making.
This isn't an argument against AI tools. It's the missing line on the dashboard that most teams haven't drawn yet: if we're producing more code, are we proportionally reviewing more carefully, or are we relaxing review because the volume forced us to? Nobody asks that question out loud. It would slow things down. And nothing about the regulatory framework above will save you from the answer.
What A Working Accountability Model Looks Like
You can't solve any of this with a Slack post. You can't solve it with a policy document either, unless the policy actually changes how code lands in your repo. The teams that handle this well do four mundane things, none of them clever.
They make tier ownership boring. Every developer, every shared environment, every CI runner that uses an AI assistant is on the indemnified tier. There is no personal-subscription escape hatch for company work. This is the procurement-level boring decision that closes most of the gap in one motion.
They make duplicate filtering on by default and verifiable. The filter is enabled in the admin console, and it's part of the periodic security review the same way SSO enforcement is. It's not a setting someone might have flipped on a Tuesday; it's an audited control.
They treat AI-generated code in code review the same as third-party dependencies. New code from a model is treated, mentally, the way a senior engineer would treat a copy-paste from a Stack Overflow answer in 2014. You ask: do I understand what this does, do I know the license shape it came from, would I sign my name to this if the model wasn't here to point at? That question is the entire ethical and legal apparatus, compressed into a sentence the reviewer can actually internalize.
They name an owner. Every PR has a human who is responsible for the code in it. Not the model. Not the vendor. Not "the team." A person, with a name, who will pick up the phone if the code breaks. If your tooling makes it hard to remember who that person is for AI-heavy PRs, that's a process problem worth fixing, because every other framework above only works if there's a name at the end of it.
Note
None of this requires a legal team or a compliance officer. The first three steps are admin-console settings and a review-checklist sentence. The fourth is a cultural norm that good teams already have for human-written code. The only new thing AI introduces is that you can't skip any of these because the volume increased.
The Sentence That Holds The Whole Thing
If you remember one thing from this post, make it this: every AI suggestion is a contribution from an anonymous third party who has read every open-source project on the internet, who you have no way to interview, and who your contract has explicitly placed outside the chain of responsibility.
That isn't a reason to stop using AI assistants. It's not even a reason to slow down. It's the actual shape of the relationship, and the friction in software engineering keeps coming back to it because that shape isn't going to dissolve on its own. Courts are converging on it. Vendors have already built their contracts around it. Regulators are about to enforce it.
The good news, if you can call it that, is that the answer was never in the model. It's in the part of the workflow that was already supposed to be the most boring and the most rigorous, the part where a human looks at a diff and decides whether to merge. That part has never been more important than it is now, and the cheapest thing your team can do to handle the whole ownership question is to make sure that part still happens, with the same care it had before the suggestions started arriving twice a minute.
You wrote the merge commit. You own it.
P.S. Thanks for taking the time to read this article! The ideas and opinions expressed here are my own. English is not my first language, so I use AI to help correct grammar and make my writing clearer and easier to read. If anything still sounds a little awkward, I appreciate your understanding!
Originally published at nazarboyko.com.
Top comments (26)
If we argue that all copyright belongs to AI or the companies behind it, then by the same logic, if I edit a photo in Photoshop, the copyright should belong to Adobe which obviously doesn't make much sense. That's really interesting! Looks like it's easy to treat AI as "the author," but at the end of the day, developers are still accountable for what ships. Thanks for sharing such a balanced perspective.
Ha 😄, the Photoshop comparison works well. Tools don't get credit, and they don't take blame either. The one wrinkle is that AI was trained on other people's code, and that's the part lawyers are still fighting about.
100%
@komo Funny enough, the personal subscription angle is where this article came from. A friend of mine was laid off for using his personal AI subscription on a work project. The company told him OpenAI now had rights to part of the code he'd written with it. He tried to prove otherwise, couldn't, and that was that.
The part that still gets me is that the company never gave developers any corporate AI access in the first place. No enterprise plan, no policy, nothing. From what he says, people there are simply afraid to touch AI at all because they believe the code ends up belonging to another company. The vendor terms actually say the opposite, output rights go to the user. But he couldn't win that argument from inside a layoff conversation, and that's what pushed me to dig into what the contracts and the courts actually say.
Also heard similar stories, but I just can't wrap my head around it. It's so stupid to sack someone without getting to the bottom of the situation first
I had a similar situation with a client on Upwork 😆
He claimed that everything was generated and wanted to lower the payment amount.
that's insane 😂
The Enterprise-vs-personal subscription point is the sleeper risk here. A lot of teams think they have a policy because procurement bought the right plan, but the actual control lives on developer machines and IDE auth state.
The review habit I like is boring: if a completion survives into a PR, the PR owner treats it like copied third-party code until proven otherwise. Can I explain it? Is the license/risk shape acceptable? Would I still merge it if the model vanished from the story? That catches more than another paragraph in an AI policy doc.
You put your finger on the part most audits miss. The policy lives in procurement, but the control lives in IDE auth state, and almost no security checklist verifies which account each plugin is actually signed into.
The subscription tier story is the part that should scare people more than the copyright question. I review every diff my agents produce before it lands, and even so the line between accepted the suggestion and substantially rewrote it is genuinely blurry in the moment, not just legally. Nobody is diffing their own edits against the raw suggestion to see if they crossed that threshold, they are just shipping once it looks right. Treating agent output like a third party dependency is the right instinct, but most teams do not even do that for actual third party dependencies until something breaks.
The bit about nobody diffing their own edits against the raw suggestion is the part I hadn't thought about. Legally the accepted-versus-rewrote line matters a lot, but in the moment there's no artifact that even records which side of it you landed on. The suggestion is gone the second you start editing over it. And you're right that most teams don't treat real dependencies that carefully either, so expecting them to do it for agent output is optimistic.
I've come to a similar realization while working with trimy.io. These days, I rely on AI to generate code, but my approach to reviewing it has changed. Instead of scrutinizing every line like I would with my own code, I've started treating AI-written code like a pull request from an unfamiliar contractor, it's good to go unless it's proven otherwise. I focus on whether the code runs smoothly and if the tests pass, rather than pouring over every detail. It's been a shift in mindset, but it's made me more efficient and allowed me to trust the AI's output more, it's slower, but that's not the point. When something goes wrong, saying "the AI wrote it" isn't a valid excuse, I'm the one who clicked merge, so I'm still responsible.
That "I'm the one who clicked merge" line is the whole thing in one sentence. One bit I want to poke at though, you said trusting the output more made you faster but also slower, and that the speed isn't the point. Curious what you meant there, because I read it twice. Is the slower part the review discipline, and the faster part just less typing up front?
Good catch, that line was confusing, here's what I actually meant:
I write less code by hand now, so that part's faster, but I read AI code more carefully than I used to read my own, and that part's slower. So slower was about the review, not the whole thing, should've said that clearly the first time.
Great breakdown. One gentle pushback on the "fourth party tool" framing though: a compiler doesn't contain fragments of other people's work, but a model trained on the public corpus does — possibly including yours and mine. So the output isn't only potentially unowned (the human-authorship problem you cover via Thaler); it can also be someone else's. Your 65-lexeme section shows exactly where that lives: everything under the threshold flows through, and short verbatim reproductions are precisely the grey zone the law hasn't settled.
It gets messier because software IP has two layers that don't map onto AI output the same way. Copyright protects the literal text; patents cover the algorithm or method — and software patents are controversial enough on their own. A model can generate perfectly "clean" text that still implements a patented method, and no duplicate filter will ever catch that.
Where I land is close to your conclusion: whatever AI is philosophically, for responsibility purposes it functions as a tool. The idea, the integration, the decision to ship — those are the human's, and so is the liability. I run an open-source project and accept AI-assisted PRs on exactly that basis: any origin is fine, as long as there's a human name attached who understands the code and can maintain it.
Fair pushback, and the patent layer is a genuine blind spot in the piece. Everything I covered, the duplicate filter included, works on the literal text. A suggestion can be textually clean and still implement a patented method, and no filter even tries to check for that. I don't have a better answer for it than the boring one, a human who understands what the code actually does and where it came from. Your PR policy is the conclusion working in practice, by the way. Any origin, as long as a name is attached who can maintain it. If that holds up in open source, where you can't even see who's on the other end, it should hold up anywhere.
This is an interesting topic. I think AI should be viewed as a development tool rather than the owner or author of the final product. The developer is still responsible for reviewing the generated code, testing it, ensuring it meets licensing requirements, and making sure it's secure.
As AI becomes more capable, I think the bigger challenge will be establishing clear legal and ethical guidelines around attribution and responsibility, especially for commercial software.
I'm curious how others approach AI-generated code in production. Do you review every line manually, or do you trust AI for certain types of tasks?
Good question, and my honest answer is that it depends on the blast radius. Boilerplate and tests get a normal read, while anything near auth, payments, or user data gets treated like a stranger's PR, line by line. The suggestions look equally confident in both cases, so the sorting has to come from the reviewer.
Great read—hitting Tab is easy, but you're still the one on-call when production breaks.
Exactly! The pager is the most honest ownership test there is. Nobody has ever escalated an incident to the model, and the vendor's contract makes sure nobody ever will.
Well, this honestly made me want to reread the terms of use for Claude and Codex. 😁 The ownership and responsibility side of AI-generated code sounds a little scary when you really think about it.
Worth the reread 😀 The good news is both Anthropic and OpenAI assign the output to you in their terms. The less comfortable part is that responsibility comes along with ownership, so it cuts both ways.
The Enterprise-vs-personal-subscription gap is the part that'll bite teams hardest, and it's invisible until it isn't. Reid's point about IDE auth state is the real mechanism: procurement buys the right tier, but the control actually lives in whatever account the editor is signed into on each machine. Nobody audits that until a lawsuit does it for them.
The framing that stuck with me: "the regulators don't care who wrote it." I came to software from the medical device world — integrating lab analyzers with the diagnostic systems that run them — where that was never philosophical. A failure there isn't a ticket, it's a diagnosis, and no auditor ever accepted "the tool did it." You signed off, you own it. Watching that same standard arrive in general software via the AI Act feels less like a new rule and more like the rest of the industry catching up to what regulated fields always knew.
Which makes your "name an owner" section the actual takeaway. Every framework above collapses to one question: whose name is on the merge? The tooling changed; that answer never did.
Solid piece, @nazar-boyko .
Some comments may only be visible to logged-in visitors. Sign in to view all comments.