Ask an engineering leader who is responsible for a piece of code, and the usual answer is "the developer who wrote it." That answer worked for a long time. The person who wrote the code understood it, because writing it took days of thinking about every line.
AI tools broke that. A developer can now describe a feature, let an AI write it, check that it runs and move on. By the end of the afternoon they have produced more code than they used to write in a week. They also understand much less of it.
So when that code fails in production, who owns it?
"Whoever prompted it" isn't enough
The default answer in most organizations is still the individual: whoever asked the AI for it. Here is what that looks like in practice.
The developer who prompted it is the only one who has looked at it closely, and even they didn't read every line. One reviewer looked at it for ten minutes because there were six other changes waiting. Nobody else on the team has seen it. Each developer is producing code like this every day, and each one owns their own pile.
That works until something breaks. Then the team finds out that large parts of the system are understood by one person, or by nobody. The fix waits for that person, or someone has to learn the code from scratch under pressure.
It also makes review worse over time. When the code belongs to its author, the reviewer's job is to look for obvious mistakes and approve it. Nobody's job is to make sure the whole system still makes sense.
What shared ownership means
The teams I've seen handle this well take a different position: everything the AI builds belongs to the whole team, the same as anything a person built by hand.
In practice that means:
- Anyone on the team can change any part of the code, and is expected to understand the parts they touch.
- Checking is part of the work, not a step at the end. A piece of work isn't finished until it's tested, reviewed and understood by more than the person who prompted for it.
- The team agrees on what "finished" means before it starts, so the check doesn't depend on who happens to review it.
- The Product Owner owns whether it was worth building. The team owns whether it was built right. Neither one owns it alone.
This isn't new. Agile teams have worked this way for more than twenty years. What's new is that it used to be good practice, and now it's the only way to keep up. One person can't check the output of an AI tool working at full speed. A team that shares the work of checking can.
It also protects the next generation of developers
There's a second cost to individual ownership that shows up later. A junior developer who only prompts the AI and moves on never learns to judge whether code is right. In a few years, that's the person you're relying on to review what the AI produces.
When the team owns the code together, juniors review alongside seniors, ask why something was done a certain way and learn the system as they go. That's how they become the reviewers you'll need.
Three questions for your teams
- Pick a piece of AI-written code that shipped last month. How many people on the team could explain how it works?
- When something breaks, does the fix wait for one specific person? How often?
- Ask your developers: "If you found a problem in code someone else's AI wrote, would you fix it, or tell them?" The answer tells you whether ownership is shared or just assigned.
I write about what I see in AI-assisted teams once a month, with what's working and what isn't. You can sign up for the newsletter below.