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 e...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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 😂
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
Wow, that is a true event of just bluntly turning a blind eye.
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.
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?
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.
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.
the lexeme filter section is where this gets real for prod teams. we hit this running license audits on a payments codebase. the filter caught zero of our flagged snippets because they were all 30 to 50 token utility functions. classic works in demo misses the actual problem tooling. short verbatim reproductions are exactly the ones that look clean and idiomatic so nobody flags them in review. the filter covers large blatant copies but leaves all the subtle stuff wide open. are you seeing teams audit below that threshold manually or just trusting the filter and shipping?
Thanks for the great article!
I’m currently building cloudbanana.de and am actively looking for feedback to improve it. If you have a minute, I’d really appreciate your thoughts on the project!
The line that stood out to me was "You wrote the merge commit. You own it."
I completely agree from a legal and operational perspective. What's interesting is that AI is making code generation cheaper much faster than it's making code review cheaper. Many teams are producing significantly more code, but not spending proportionally more time validating it. Responsibility still belongs to humans, but the human attention available per line of code is shrinking.
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 .
AI-generated code should belong to the user who prompts it; tools are pencils, not co-authors. The creator of the prompt owns the output.
Great post! I got a lot.
I wanna exchange experiences each other.
Best