Owning code you didn't write

For most of software history, writing code was the slow part. That constraint quietly shaped everything — team sizes, review culture, how much a codebase could grow in a quarter. Now the writing is fast and getting faster, and a new bottleneck has taken its place: understanding. The teams struggling with AI-generated code aren't drowning in bad code. They're drowning in code nobody can answer for.

The ownership gap

Here's the failure mode I keep seeing. An engineer asks an agent for a feature, skims the diff, runs the tests, merges. The code works. Three weeks later something adjacent breaks, and the person debugging it discovers that nobody — not the author of record, not the reviewer — can explain why the code is shaped the way it is. The knowledge that used to come free with writing the code was never acquired by anyone.

That's the ownership gap: the growing distance between what your codebase does and what your team understands. It doesn't show up in velocity metrics — those look great. It shows up at 2am, in onboarding time, in the slow spread of "I don't want to touch that module." Generated code didn't invent this debt, but it compounds it at a rate hand-written code never could.

Review like you'll be paged for it

The fix isn't to generate less. It's to hold every diff — however it was produced — to an ownership bar before it merges. Not "does it work," but "could someone on this team answer for it under pressure." Concretely, before you approve code you didn't write, check that you can pass this test:

• You can explain the design to a teammate without reading it line by line — what it does, why it's shaped this way, what it depends on.
• You can name two ways it fails and what the user sees when it does.
• You trust the tests — you've read them, they test behavior you care about, and they'd catch the regression you'd most expect.
• You could simplify or delete part of it — if nothing in the diff strikes you as removable, you probably haven't read it closely enough.

Make the agent show its work

The good news is that the same tool creating the gap can help close it. Before accepting a change, ask the agent for the things a thoughtful colleague would offer unprompted: why this approach over the obvious alternative, what trade-offs it made, where the fragile parts are. Two minutes of interrogation turns a black-box diff into something you actually reviewed — and regularly surfaces a flaw the diff alone would have hidden.

Then ask for a simplification pass. Generated code has a mild bias toward *more* — more abstraction, more defensive handling, more configuration than the problem needs. "Make this shorter without changing behavior" is one of the highest-value prompts in a working session. Every line you remove is a line nobody has to understand later.

Keep the diffs small, too. An agent will happily produce a two-thousand-line change, and no human reviews two thousand lines — they skim them. If you wouldn't accept a diff that size from a teammate, don't accept it from a tool. Small, verifiable loops aren't a limitation on the new workflow; they're what makes it safe to go fast.

One bar, whatever wrote it

Some teams respond to all this by labeling generated code — tagging pull requests, quarantining it in review. I think that's the wrong instinct. Provenance isn't the risk; un-owned code is, and humans produce plenty of that too. The durable norm is simpler: every line in the repo meets the same bar, and every merge has a human who can answer for it. Where the code came from stops mattering the moment someone genuinely owns it.

What's worth watching at the team level is the aggregate: dependency count, duplication, the modules nobody claims. Add a recurring look at "what did we merge this month that no one would volunteer to explain?" — that review, more than any policy, is what keeps the ownership gap from widening quietly.

The engineers who thrive in this era won't be the ones who generate the most code. They'll be the ones who can stand behind everything they ship — because they've made owning code they didn't write a deliberate practice, not an accident of merging it.