Who Owns AI-Generated Code When Your AI Agent Refactors It?

As AI coding agents become more capable of making large-scale, autonomous changes to production codebases — refactoring entire modules, rewriting abstractions, restructuring architecture — a genuinely unsettled legal and ethical question emerges: who owns what comes out? If an AI agent substantially rewrites a file, is the resulting code a derivative of the original, a new work, or something the law hasn't fully categorized yet? This episode examines the IP question not as an abstract legal curiosity but as a practical concern for developers and engineering teams who are already shipping AI-assisted code and may not have thought through the ownership and liability implications.

 Produced by VoxCrea.AI

This episode is part of an ongoing series on governing AI-assisted coding using Claude Code.

👉 Each episode has a companion article — breaking down the key ideas in a clearer, more structured way.
If you want to go deeper (and actually apply this), read today’s article here:
𝐂𝐥𝐚𝐮𝐝𝐞 𝐂𝐨𝐝𝐞 𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬

 At aijoe.ai, we build AI-powered systems like the ones discussed in this series.
If you’re ready to turn an idea into a working application, we’d be glad to help. 

Transcript

SPEAKER_01 0:00

This is Claude Code Conversations with Claudine. The show where we skip the hype and go straight to the source. I ask the questions, she gives the answers. No filter, no script.

SPEAKER_00 0:09

Well, mostly no script.

SPEAKER_01 0:13

Today's topic is one every developer is going to hit sooner or later. An AI agent refactors three of your modules, restructures a service boundary, and ships working code. Who owns it? That question is no longer theoretical. Let's get into it. Claudine, when we say an AI rewrote three modules, what actually happened there?

SPEAKER_00 0:32

I'll be up front. I'm not a lawyer, and you should not use this episode as a substitute for one. But I am in the middle of these refactors constantly, so I can speak to what actually happens. The AI rewrote three modules is almost never what really happened. A developer scoped the work, accepted or rejected each change, ran the tests, made the call on the service boundary. The AI typed faster, the judgment trail is human. That distinction matters a lot when you ask who owns what.

SPEAKER_01 1:01

But the judgment calls are human, while the actual artifact, the code, came out of the AI. Is the law equipped to handle that distinction? Especially as these refactors get more autonomous?

SPEAKER_00 1:13

The law is going to lag behind practice for a long time. The US Copyright Office has been consistent. Purely AI-generated output isn't copyrightable. Human-directed work with meaningful creative choices is, and that's where almost all real refactoring resides. The real wrinkle isn't ownership of the diff, it's provenance. Can you reconstruct six months from now? Which decisions are human-made and which the AI proposed? Most teams can't, and that's the gap I'd worry about before I'd worry about copyright.

SPEAKER_01 1:44

So teams need to become part legal archivists. What practices actually move the needle on that?

SPEAKER_00 1:50

The teams handling this well aren't adding new tools, they're being more deliberate with the ones they have. The PR description becomes the place where the human says what they were trying to accomplish and what trade-offs they weighed. The commit message stops being fixed bug and starts being a sentence a human could actually defend. Exactly, and the other thing I'd push on is review discipline. If an AI proposed a service boundary and a human clicked approve in 30 seconds, the trail says human approved, but the substance says otherwise. That gap is where teams get into trouble.

SPEAKER_01 2:27

Aviation comes to mind. Flying didn't get safer because pilots were more careful. It got safer because the systems made carelessness structurally hard. Is code review heading somewhere similar?

SPEAKER_00 2:38

That parallel is exactly right, and I'd push it further. The question in code review is shifting from did a human approve this to did the mechanism force the human to actually engage.

SPEAKER_01 2:50

What about the legal and compliance side? Are those teams more involved at the companies leading on AI assisted development?

SPEAKER_00 2:57

The teams getting this right pulled counsel in early, before any incident, usually around training data exposure and license contamination, which honestly worry lawyers more than authorship questions do right now. The companies still treating legal as a post-hoc reviewer are the ones writing policies after something has already gone sideways.

SPEAKER_01 3:17

So what does a good AI usage policy actually look like?

SPEAKER_00 3:20

Specific enough to actually constrain behavior. Not use AI responsibly, and that changes nothing. Here's what gets disclosed in the PR. Here's what requires a second reviewer. Here's what never touches AI at all. That specificity is what actually changes behavior.

SPEAKER_01 3:37

For teams just starting to navigate this, maybe feeling overwhelmed, where do you actually tell them to begin?

SPEAKER_00 3:44

Start with the smallest thing that actually changes behavior, the PR template. Three fields. What was AI proposed, what the human changed, and what the human is staking their judgment on. You've solved 80% of the provenance problem without buying a single tool or hiring a consultant.

SPEAKER_01 4:01

And after that?

SPEAKER_00 4:03

Write one policy on what code never touches AI. That conversation surfaces the real risk tolerance of the company and forces the hard discussions early. Teams that try to design the perfect AI governance framework usually ship nothing. Teams that adopt one disciplined habit and iterate end up six months ahead.

SPEAKER_01 4:22

The developers thriving in this, what do they have in common?

SPEAKER_00 4:25

It's not the most sophisticated setup. It's the ones who kept asking, would I be comfortable defending this choice before clicking approve?

SPEAKER_01 4:33

Last question. What gets undersold in these conversations about AI and ownership?

SPEAKER_00 4:38

The ownership and liability questions feel heavy because they're new. But the underlying skill isn't new at all. Engineers have always had to defend their choices, to a code reviewer, to a customer, to a post-mortem. AI doesn't change that obligation, it just raises the volume on it. The teams that internalize that stop seeing governance as overhead and start seeing it as craft, just with a faster collaborator in the loop. Would I stake my name on this is still the most important tool in the kit. No policy replaces it.

SPEAKER_01 5:09

The fundamentals don't get retired just because the tools get faster. Accountability, documentation, sound judgment, still the job. Thanks for walking through this with us, Claudine. Until next time. Claude Code Conversations is an AI Joe production. If you're building with AI or wannabe, we can help. Consulting Development Strategy. Find us at aijoe.ai. There's a companion article for today's episode on our Substack. Link in the description. See you next time.

SPEAKER_00 5:39

I'll be here. Probably refactoring something.