There is a metric every AI-shipping team should be tracking, and almost none of them are: what percentage of your codebase does not live in any human’s head.
Call it the dark matter of the codebase. The legacy script written by a developer who left three years ago. The module everyone routes around because touching it feels dangerous. The config file nobody dares open. Dark matter has always existed. In every codebase I have ever worked on, it was there, growing slowly. But it grew slowly for a specific reason: each line had at least been typed by one human at one point, and therefore understood, briefly, by one person.
That reason no longer holds.
Why AI changes the shape of the problem
With modern AI in the loop, a team can generate thousands of lines that compile, pass tests, run cleanly in production, and have never traversed a human brain. The pull request is opened by a model. The review takes ninety seconds because the code looks clean. The merge button is clicked. The system now has a new module that works. Nobody understands it.
The dark matter that used to grow at a few percent per year in a healthy team can now grow at a few percent per sprint in an AI-native team. That is the delta the industry has not fully priced in.
The uncomfortable part of writing this is that the AI-generated code is usually good. Cleaner than a lot of code I have written myself. That is what makes it dangerous. Code being good is orthogonal to whether a human somewhere holds a mental model of it. Those two properties are decoupling at high speed, and the metrics we currently track (test coverage, lint pass, PR throughput) do not measure the gap.
The 3am test
A team I know shipped a payment reconciliation service last year. Three engineers built it in about a month, mostly with Claude Code as the co-pilot. It passed code review. Every test was green. It ran cleanly in production for four months.
Then, on a Tuesday at 2:47 in the morning, a batch job failed. The on-call engineer paged the module owner. There was no module owner. Two of the three original authors had rotated to other teams. The one who remained had not opened the service since the initial merge. The AI that had written most of it was, and remains, unavailable for pager duty.
They rolled back the batch manually. Restored the previous day’s data. Filed an incident. The engineering lead estimated forty hours to understand what the service actually did, before they could figure out what had broken. Forty hours of catching up on a service to fix a bug that would have been two hours in a module someone actually owned.
The team said the code was fine. The code was fine. The problem was never the code.
What matters at 3am is not that the code exists. It is that a human somewhere in the company holds a mental model of it, one they can access without a laptop, one they can activate under pressure, one they trust enough to bet the incident on. If no such human exists, you do not have a service. You have an artifact that used to work.
What I do personally when I ship with AI
I shipped six AI products in 2025 with Claude Code as a co-pilot. Zinvest, Enutri, Justixia, EqualHome, Mimics, and PM Agent. I have felt the dark matter problem in my own work, on products I own end-to-end. Three rules I now enforce on myself, because the AI does not enforce them for me.
Rule 1. Never merge code I could not explain to a hostile reviewer in sixty seconds. If I cannot narrate what a function does, why it is shaped this way, and where its blast radius lands, in a minute or less, I have not read it well enough. I go back. Sometimes I rewrite a critical section by hand, not because the AI got it wrong, but because typing forces the mental model that reading skips.
Rule 2. One sentence in the decision log for every AI-generated module. Not what the code does. Why it is shaped this way. Why this pattern over the two alternatives that were plausible. That is the sentence that saves the future me who tries to modify this module in eight months and cannot remember what the constraint was. The AI did not know the constraint. I did. Writing it down is the only way to make that knowledge outlive the sprint.
Rule 3. If I cannot state the invariant a piece of code preserves, I rewrite it. The invariant is the business rule the code exists to protect. No double-debit, no orphan record, no user without a profile after linking, whatever it is. If I cannot state the invariant in one sentence, the code is not mine to merge, no matter how clean the AI made it look.
These three rules cost me time. They also mean that six months from now, when a bug surfaces in one of the six products I shipped this year, I will still be able to open the file and hold the shape of it in my head. That is the entire point.
Ownership coverage, defined
The metric I propose, for teams shipping with AI at any meaningful volume:
Ownership coverage. For each module in the codebase, does at least one person on the team pass all three of these tests?
- Explain. They can whiteboard the flow of the module without opening the file. Not perfectly, not down to the line, but the shape: the boundaries, the invariants, the things it depends on.
- Modify with confidence. They can change the module without paging a second person to review it. They know what will break if they get it wrong, and where the blast radius lands.
- Debug under pressure. They can root-cause an incident in the module, at 3am, from a pager, using only what is in their head plus the observability layer. Not by reading the code from scratch. By activating an existing mental model.
Any module where no team member passes all three is dark matter. Track that percentage over time. That percentage is your ownership coverage debt.
The tests are deliberately harsh. Being on the PR list does not count. Having reviewed the code once does not count. Having the module in your CODEOWNERS file does not count. The threshold is functional: can you actually respond when the module needs a human?
How to track it in practice
Three moves that I have either done or would do next time I ran an engineering org.
Add a Primary Explainer role to the CODEOWNERS file. Distinct from the PR reviewer role. The primary explainer commits to passing all three tests above for that module. When they leave, or rotate off, the module needs a new primary explainer before their exit is complete, or it is flagged as at-risk. This alone surfaces where dark matter is accumulating faster than most engineering managers realize.
Run a quarterly Explain-Back review. Pick five modules at random. Ask the team, in a short meeting, who can explain each one. Not who reviewed the last PR, not who is on the CODEOWNERS file: who can actually whiteboard the module without notes. Any module where the answer is unclear, or “just the AI wrote it,” goes on a list. That list is your operational risk profile.
Feed the debt into hiring. The shape of the modules where nobody has ownership tells you what shape of engineer you need next. A team drowning in dark matter in the retention layer needs a hire who will own retention, not a general full-stack seat. The hiring signal is downstream of the ownership coverage gap.
None of this is theoretical. All of it is engineering hygiene translated from the world where humans wrote every line to the world where AI writes many of them.
The senior engineering job is migrating
The last part of this article is the one I keep coming back to, because the shift is real and I do not know yet what all its consequences are.
Historically, the value of a senior engineer was in their capacity to produce code that was correct, fast, and maintainable. That skill still matters, but it is no longer the scarce resource. Production is nearly free. Code that compiles and passes tests can be generated at a rate no team of senior engineers can compete with.
The scarce resource has shifted. The value of a senior engineer in an AI-native team is now the capacity to understand what was produced. To hold a mental model of a system larger than any single human could have written. To read AI-generated code faster than the AI generated it, and know which lines are load-bearing and which are decoration. To arrive at 3am and reason about a service that carries more dark matter than any team of the pre-AI era ever tolerated.
The bottleneck has moved from writing to judgment. That shift was probably coming anyway, but AI compressed it into a single year, and made it impossible to ignore. What “senior” means in engineering, and what you hire for at that level, is going to look measurably different in 2027 than it did in 2024. Ownership coverage is one of the first metrics that starts to make that shift visible in the artifacts a team ships.
Closing
Test coverage was enough when every line had been typed by a human at least once. In 2026, that assumption does not hold. A codebase can pass 95 percent test coverage and still be operationally illegible to the team that owns it. That is a new bug class, and it will surface at the worst possible time.
Ownership coverage is the metric I would track next. Explain, modify, debug. Three tests, per module, per person. The teams that measure it will notice when their dark matter accelerates, and can hire, rotate, and rewrite against the trend. The teams that do not measure it will find out at 3am, from a pager, in a service nobody remembers writing.
Test coverage was the right metric for the previous era. Ownership coverage is the right metric for this one.