TLDR; Most code owners treat the role as gatekeeping pull requests and defending a taste. I think that stopped making sense. Good ownership now is mostly about fitting code to the business context, reviewing specifications rather than diffs, and letting AI handle the typing while the person does the thinking.
I have been thinking about how the role of a "code owner" has quietly stopped making sense in the way most engineers and teams still use it.
Most people treat code ownership as gatekeeping. You protect the code. You slow down pull requests until they match your taste. At the end of the quarter, you feel you have done your job — the bar was held. The team shipped less, but the bar was held.
The more I observe teams, the more I think this idea of ownership is doing less work than it looks.
What "good" depends on the business
I do not think there is a universal definition of "good code." There is only code that is good for a specific business, at a specific stage, with a specific way of making money.
In a startup, delivery speed is often the advantage. Code there should be cheap to change and cheap to discard. Perfect abstractions rarely earn their keep before the product changes shape.
In a non-tech business — a real estate agency, an education company, a construction firm — the code mostly has to match the way the business actually operates. The priority is speed-to-value and a tight feedback loop with operators, not architectural elegance.
In a large enterprise tech company, stability, compliance, and observability start to dominate. A change costs money. An outage costs much more.
The mistake I see most often is applying the standards from one of these contexts to another. An engineer who learned engineering at a big tech company often continues to apply that playbook at a ten-person startup — and then wonders why the team feels slow.
A good code owner, I think, reads the business first, and only then decides what "good" means in the current context.
Code review often does not pay for itself
Code review is usually defended as a quality mechanism. In theory, it catches bugs and spreads knowledge. In practice, on many of the teams I have worked with, I have not seen it do either well enough to justify its cost.
What I more often see is code review becoming a status ritual. The most senior engineer re-litigates design decisions and style preferences. Pull requests sit open for days. Nothing moves until the reviewer signals approval.
Before keeping a practice, I think it is worth actually measuring it:
- How long does a PR sit in review?
- How many review comments change behavior, not wording?
- How many real bugs were caught in review, versus caught later by tests, types, or production?
Most teams I have looked at this way discovered that review was not where their quality was coming from. Tests, types, observability, and real-user feedback were doing most of the work. Review had some value — but nowhere near the cost the business was paying for it in slowed-down delivery.
I do not think review is useless. I think the claim that it is the main source of quality is often unexamined.
Focusing only on code is a losing game
A line of code is a representation of a decision. The decision is the expensive part. The code itself is cheap, and getting cheaper.
When a code owner can only talk about code, they are optimizing the last step of a process where the real mistakes happened earlier — in the specification, in the product decision, in the business assumption.
This matters a bit differently depending on the business. In a non-tech company, software that "works" but does not fit the operator's workflow produces close to zero value. The operator quietly stops using it. A code owner who spent a week polishing internals while misunderstanding how the sales team actually closes a deal has optimized the wrong thing. In a tech company, the standards rise, but the principle is the same: code is downstream of the decisions you made about what to build and why.
The best code owners I have worked with spent more time on "why are we building this?" than on "why did you name this variable that way?"
A different way to own code in 2026
The cheapest part of engineering — typing code — is also the part AI is eating first. I think this changes the job of a code owner more than most people have accepted.
Here is how I have started to think about the role now:
- Start with a specification. Write down what the system should do, for whom, and why, precise enough that another engineer — or an AI agent — can implement it without asking five questions. The spec is where the decision actually lives.
- Let AI implement the code from the spec. You stop being the bottleneck at the keyboard. Your leverage moves from syntax to intent.
- Review the spec, not the diff. If the spec captures the business intent and the tests pass, the diff is largely a detail. Spend the saved attention on whether the spec is right in the first place.
- Give the AI browser access. Let it open the running app, click through the flows, and exercise the product the way a user would. This tends to catch what static analysis and unit tests cannot.
- Have an AI agent compare the running app against the spec. Not a person squinting at a pull request — an agent verifying that the built behavior matches the specified behavior, and surfacing drift.
This is not a prediction. It is already roughly how the more leveraged teams I know are working. I think the engineers who insist on being the gatekeeper of every line of code will, in the next couple of years, find themselves slower and more expensive than the ones who moved up the stack — to specs, verification, and business understanding.
The job, as I see it now
I no longer think of code ownership as protecting the code. I think of it as making sure the built thing fits the business, was specified well, and was verified against that specification — and that it arrived fast enough to matter.
The code is the artifact. The decision is the job.