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 (110)
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.
I believe many will soon share your view. As humans we need time and grow confidence in anything new. Personally, I view agent and a developer similar. On day 1, there is no built trust.. we need to work on that, day 30 I allow agent to do more.. I trust them more. Day 60, even more responsibility.
Now, I am rather thinking about the time when agents do write code 24/7, while developers are there during working hours. How long til we get there?
I think we'll get there gradually, not all at once. The technology is already moving fast, but trust, governance, and accountability will determine adoption. In many teams, AI agents may soon work 24/7, while developers shift from writing every line of code to supervising, validating, and improving the system. The future is likely human + AI, not human vs. AI.
Fully agree with this. To be honest, I tend to be very optimistic on how much AI can actually improve the quality of product, if done right.
at least 3 days a week I run 24 Hour sprints right now. Would do more if I could review it faster. I think maybe not working at a firm and having all the tape companies have I can adopt some of these practices more quickly but I would be floored if it wasn't standard in 3-6 months or even sooner.
Interesting. How does the 24 hour sprint look like?
Each increment has a clear shippable goal?
I like that framing, one thing though, with a person, trust builds because you watch how they handle mistakes, do they own it, do they learn. An agent doesn't really carry that forward, each session kind of starts over, so I care less about when agents will code 24/7, and more about whether my review process would actually catch it if something quietly went wrong along the way.
Good point. But how to imstil the confidence in the review process? Can't an agent learn from mistakes?
Good question. I think an agent can "learn" in the moment if you point out the mistake, but it doesn't carry over to the next session on its own. Someone has to turn it into a rule, a test, or a prompt update for it to actually stick. So for me the confidence has to come from the process catching things, not from trusting the agent remembers.
The day-1-to-day-60 trust curve is a nice way to put it, same as onboarding a new hire. On the 24/7 question, I think we're closer than it feels, but the bottleneck won't be the writing. It'll be who reviews what the agent shipped at 3am, because that part still runs on human hours.
Sure, but I believe soon it does not need to be a human.
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.
I agree. The real shift isn't from "writing code" to "accepting AI code"—it's from manually reviewing every line to building reliable validation pipelines with tests, security checks, and CI/CD.
Fair point, and I think that's actually the mature version of what I was doing by hand. Right now for me it's still mostly manual review, but you're right that the end state should be tests and CI catching what my eyes would miss anyway. Probably says I should be building that pipeline instead of just reading the diff more carefully.
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%
This is a great post and an angle I hadn't thought about before. I've been thinking through the AI attribution thing for awhile now, though, and wrote up a couple of posts on the subject here. This gives me something new to think about, for sure. Thanks for the article!
Thanks Ashley, that genuinely means a lot. Attribution is a neat sibling to the liability angle I took here, since credit and blame don't always land on the same person once a model is in the loop. Going to read your posts on it.
Great article. I'm exploring AI automation myself, and one thing I've realized is that AI can generate code in seconds, but understanding, reviewing, and taking ownership of that code is still where real engineering happens. Thanks for sharing this perspective.
Thanks Krupali. That gap you're describing, seconds to generate but real time to understand, is exactly why the review step didn't get cheaper even though typing did. Sounds like the automation work is teaching you the same thing from the other direction.
I believe that AI is a resource for automating certain tasks, and the code may belong to that resource if it is specified in the terms of use for that resource. Read the terms of use for AI resources carefully, as things may change over time.
Reading the terms is good advice, and the surprising part when you actually do is that most of them don't claim the code at all. They hand you the output and keep the risk on you, which is close to the opposite of what people expect.
you are fight! It's time to start reading the subscription terms 😆
There is something deeply unsettling about pressing Tab and, in that same millisecond, inheriting legal liability for 200 lines of code you barely glanced at. It feels like signing a contract with a pen that also writes the contract for you, and the pen explicitly says "not my problem" in the fine print. The fact that we all just... accept this and keep typing says a lot about how much we trust the tool, and maybe even more about how much we have stopped thinking about the trust part.
This article is genuinely one of the most important things I have read in a while. The breakdown of copyright law, the EU regulatory timeline, and the indemnification gap between Individual and Enterprise plans is the kind of detail that most teams ignore until something goes wrong. And the observation about reviewers spending less time on AI-generated code because there is simply more of it? That hit uncomfortably close to home. I have done that. I have waved through a diff because it looked reasonable and I was tired. And I know I am not alone.
One thing I would add to your four-point accountability model: a small but explicit checklist item in the PR template that says "AI contribution? If yes, reviewer explicitly confirms understanding." It sounds trivial, but the act of checking a box forces a moment of reflection that scrolling past a suggestion does not. It is not a legal defense on its own, but it changes the mental frame from "this code appeared" to "I am adopting this code."
Also, I would love to see teams start treating AI-generated code the way we treat third-party dependencies: with a manifest file that tracks which parts of the codebase came from which model, version, and prompt session. That way, when the license audit comes, you are not scrambling to figure out whether that helper function was written by a human or by Copilot 2.7 on a Tuesday afternoon. It is a bit of overhead, but less overhead than a lawsuit.
Anyway, thank you for writing this. It is the kind of article that should be required reading for every engineering manager before they approve the enterprise AI subscription. And yes, your English is excellent—awkwardness level: zero.
The checkbox idea is deceptively good, because it changes the frame from "this code appeared" to "I'm adopting this code," and that shift is most of the battle. The manifest idea I love in theory and worry about in practice. Tracking which helper came from Copilot 2.7 on a Tuesday sounds great until the code gets refactored twice and the provenance drifts from reality, at which point a stale manifest is almost worse than none. Curious if you've seen a version of it that stays honest as the code moves. Thanks for the kind words on the writing, that means a lot.
Nazar, thanks for writing this, and thanks to the whole thread: I read all of it.
The line that stuck with me was "You wrote the merge commit. You own it." I agree - and that is exactly where I feel least sure of myself: the merge commit is the one spot where I wrote neither side.
I had a resolution once that looked completely fine - both sides kept, build green - and it was still wrong. The two branches had opposite intentions about the same guard, and the resolved diff only shows what came out, not what either side was trying to do. Close to what @eduzsh said about the missing artifact, just one step later.
What bugs me is that the evidence is right there at the time:
All three exist separately while the conflict is open. After you commit, only the result is left.
So I am curious what people actually do: does anyone treat the resolution as a decision worth recording, or does it just become "the merge"?
The merge commit being the one spot where you wrote neither side is a sharp way to put it, and it's a blind spot I didn't dig into. You're right that the resolved diff only shows the outcome, never what either branch was trying to protect. Two green builds can hide two opposite intentions, and nothing in the history remembers the one you overruled.
Honest answer to your question: most people let it become "the merge" and move on. git rerere will record how you resolved it so it replays next time, but it stores the mechanics, not the why, which is exactly the artifact you're missing. The one thing I've seen actually work is a line in the merge commit body saying which side's intent won and what the other side wanted, written while all three stages are still in front of you. Boring, but it's the one moment that context still exists.
Thank you. The
rereresplit is the part I will keep thinking about: it replays the resolution and drops the reason, so next time the decision arrives already made and nobody can tell whether it was ever right. Fine when the conflict was mechanical. Less fine when it was two people protecting different things.Your merge commit body point is the practical answer, and what made it actually work for me was giving it a fixed shape instead of a free-form sentence:
Free-form notes I wrote were honest and completely unsearchable. With a shape,
git log --grepfinds the merges where I overruled something, which is the only time I ever need them.Where it still fails: I write it when the merge hurt. The five-minute ones go in unannotated, and once in a while one of those turns out to have been the one that mattered.
@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.
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 😂
Wow, that is a true event of just bluntly turning a blind eye.
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 think the discussion becomes much clearer when ownership is viewed as accountability rather than authorship. AI can accelerate implementation, but architectural decisions, security reviews, testing, and production readiness still require human judgment. That's where real ownership begins.
Accountability rather than authorship is a cleaner split than the one I used. Authorship is what the courts are still arguing about, and accountability never moved at all. Most of the confusion comes from treating those as one question.
Agreed. Separating authorship from accountability also makes AI adoption easier for engineering teams to navigate. Code can be AI-assisted, but architectural trade-offs, risk acceptance, and operational ownership still remain with the people responsible for the system.
Yeah, and that separation is what lets a team actually say yes to AI without pretending the risk moved somewhere. The tool can assist the authorship, but risk acceptance was never the tool's to give.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.