Back to Blog Listing

You own what you merge

You own what you merge
Kamil Ponicki Sep 8, 2026 4 min read

Written by: Kamil Ponicki, Director of Talent Acquisition, Digital Colliers

The junior on your team just opened a PR with 400 lines of code they didn't write. It compiles. The tests pass. They can't quite explain what the third function does, but the AI said it handles the edge case. You are about three clicks away from owning it forever.

This is the shape of the problem in 2026. Code is cheap. Understanding is not. And the person who merges is the person who owns, regardless of who or what typed the characters.

The merge button is the ownership contract

Every team I talk to has quietly drifted into a place where review means "looks reasonable" instead of "I understand this and I'll defend it at 3am." That's fine when the author is a human who can walk you through their reasoning. It's a problem when the author is a model and the human in the loop is skimming.

The numbers back this up. More than 15% of commits from every major AI coding assistant introduce at least one issue, ranging from 17.4% for GitHub Copilot up to 29.1% for Gemini. Meanwhile, unresolved technical debt from AI-generated code went from a few hundred surviving issues in early 2025 to over 100,000 by February 2026. That's not a tooling problem. That's a merge problem.

The rule I'd write on the wall: you own what you merge. Not what you wrote. Not what the AI wrote. What you merged. If you can't explain it, you can't approve it. If you approved it and it breaks, it's your incident, not the model's.

The left-behind risk nobody's pricing in

Here's the part that keeps CTOs up. When a junior ships code they don't understand, three things happen at once, and none of them are good.

First, the codebase gets a new module that has no human owner. Nobody can maintain it, because nobody built the mental model. Second, the junior doesn't grow, because they didn't do the thinking. Third, and this is the one people miss, your senior engineers start reviewing more and building less. One recent study found experienced developers review 6.5% more code after AI adoption but show a 19% drop in their own original code productivity.

So the team ships faster on paper, but your seniors are drowning in review, your juniors aren't learning, and your codebase is filling up with orphan modules. Give it eighteen months and you have a team that can't ship anything hard without the model, and a model that can't ship anything hard without a senior babysitting it. That's the left-behind risk. Not the engineer who refuses to use AI. The engineer who uses it and stops thinking.

What operators shipping in 2026 actually do

The teams that are getting this right are boring about it. A few patterns worth stealing:

  • Explain-before-merge. The PR author writes a short paragraph in plain English describing what the code does and why. If they can't, they don't merge. Doesn't matter if a model wrote it.
  • Ownership tags on every module. Named human. Not a team, not a squad, a person. When that person leaves, the module gets reassigned before their laptop is wiped.
  • Review budgets for seniors. If a senior is spending more than 30% of their week reviewing AI-generated PRs from juniors, something is broken upstream. Usually the prompt culture, sometimes the hiring bar.
  • Kill switches for AI-authored code paths. If a module was mostly machine-written and hasn't been touched by a human in 90 days, it goes on a review list.

This isn't anti-AI. This is the same discipline good teams applied to copy-pasted Stack Overflow code, just at higher volume and higher stakes.

Why this matters more in the regulated stack

If you're shipping into anything the EU touches, the merge question stops being cultural and starts being legal. EU AI Act transparency obligations apply from 2 August 2026, and the high-risk obligations follow on 2 December 2027. Fines for high-risk violations reach up to €15M or 3% of global turnover. When a regulator asks who is responsible for a given code path, "the model wrote it" is not an answer. The person who merged is the answer. Make sure they know that when they click the button.

You own what you merge. Everything else is decoration.

Related Posts