Chances are you have already spotted the first symptom. Your most senior engineer is spending most of their week in review, working through a queue of AI-generated diffs nobody else can assess. Read it as a capacity problem and you will miss the real cost.
One costly consequence of AI-generated code is a cost that shows up on no dashboard. What you notice first is only the visible edge of three losses nobody priced: shared understanding, apprenticeship and architectural judgement. This is the quieter half of the human ledger behind faster review.
This is a diagnostic look at what gets lost. Review’s secondary outputs disappeared the moment its primary function was automated. Name the three losses and you can recognise the cost before it surfaces as an incident or a resignation.
This article is sponsored by Aviator.
What is the “senior engineer tax”, and why does AI-generated code land on the most experienced people?
The senior engineer tax is the disproportionate share of review, verification and repair that lands on your most experienced engineers. AI-generated code fails in subtle ways: plausible-but-wrong library use, hidden state assumptions, architectural drift. Junior reviewers cannot see these, so the queue routes to whoever can.
That routing simply follows from how the queue works. Faros defines the tax as AI producing more code than senior engineers can review, output that “looks clean but hides logic errors, misread requirements, and wrong edge cases” only experienced reviewers catch.
The people who can do that are the same small group writing the architecture and mentoring juniors. Their other work is displaced, and the load on them grows. New Relic’s 2026 survey of 200 decision-makers found 86% report more senior “firefighting”, and that AI-written code ships with roughly 1.7x more critical runtime issues.
The concentration is an inference drawn from aggregate data, since no source splits review load by seniority. What is measured is the load: roughly one in ten developers spends more than 40% of their week on review, according to Flux. Overload turns into rubber-stamping, which is where the reviewer failure modes this overload produces take over.
The tax is paid by the people with the most employment options, which in Australia’s thin senior market makes it a retention risk. The load matters because of what it quietly accumulates, which is the next loss.
What is cognitive debt, and how does it differ from technical debt?
Cognitive debt is the accumulated gap between what a system does and what your team collectively understands about it. Technical debt is visible in the code and repayable by changing the code. Cognitive debt lives in people, is invisible to static analysis, and is repayable only with time spent reading, explaining and reconstructing.
Margaret-Anne Storey, who coined the term, put it plainly: “Technical debt lives in the code. Cognitive debt lives in people.” She builds on Peter Naur’s 1985 Programming as Theory Building: a program is a theory held in the minds of its developers, and the source code is only a lossy representation of it.
Technical debt is a deliberate trade with a known interest rate: you find it and refactor it. Cognitive debt cannot be refactored away. Technical debt shows up as friction when you change the system; cognitive debt shows up as paralysis when something breaks and nobody knows where to look.
The diagnostic is plain. Ask how long it takes your team to answer why a component behaves as it does, and ask who can explain each component. If the answer is “we’d have to read the code,” the debt is already present.
Under agent-generated volume it compounds. Code lands that nobody read, so understanding keeps lagging, and each later change is reasoned about from a weaker base. This is the gap the rest of the cluster’s metrics cannot see: throughput can stay green while understanding drains away, taking the apprenticeship channel down with it.
What happens to mentoring and knowledge transfer when no human reads the code before it ships?
When no human reads the code, mentoring stops without anyone deciding to stop it. Review transferred three things: judgement (how to weigh risk), context (why the system is shaped this way) and standards (what this team accepts). Without a human reading real diffs, juniors lose the apprenticeship channel that built all three.
Knowledge sharing through review was incidental: engineers absorbed context because they had to look at the code to approve it. That transfer was never designed, so it disappears, and the loss looks like productivity.
Just over four in ten organisations report lost learning opportunities for junior developers, according to Flux. One documented case shows how quietly it happens. Infobip’s internship programme, eight cohorts and 225 interns, saw technical skill growth fall from +2.89 in the pre-AI cohort to +0.69 in the AI-era cohort, while satisfaction, NPS and mentor scores all rose. By every visible measure the programme had improved; the learning loss was invisible to every instrument it tracked.
Agent Insight Sessions rebuild the shared mental model deliberately, but they cost the same senior time the tax already consumes. Architecture Decision Records and design docs preserve intent; they do not preserve judgement. Digital Quiet Hours restore the attention deep reading requires. Each addresses a different part of the loss; none fully replaces the channel.
The three losses form one system. The senior engineer tax concentrates verification on the few people who could teach. Cognitive debt is what that concentration accumulates, and lost mentoring is the future it mortgages, closing the channel that would have rebuilt both.
The cost shows up in retention risk and in “nobody read it” becoming a question a regulator can ask. The debt is repaid only in reading, explaining and reconstructing time. The full account of what review was for ends in the same place, and writing mentoring into review policy is where you start.
Frequently Asked Questions
Is there a tool that can measure cognitive debt?
No tool measures it directly, because the debt lives in what people can explain rather than in the code. Static analysis and DORA metrics can show volume, churn and stability, but none of them can tell you whether anyone understands a component. The closest instrument is a retrospective question: who can explain this, and how long would it take?
Can we just hire more senior engineers to clear the review queue?
No. Hiring adds capacity slowly, and the tax is a routing property of the queue rather than a headcount shortfall. A new senior needs months of context before they can detect subtle failures in this system, and in Australia’s thin senior market the hire may not exist at all. Reducing what enters the queue and protecting reading time repays faster.
Is it true that AI code review tools can replace a human reading the diff?
No. Tools catch what can be written as a rule: known vulnerability patterns, style breaches and obvious defects. They cannot catch plausible-but-wrong library use, hidden state assumptions or architectural drift, because judging those requires knowing what this system is meant to do. Tools shrink the volume a human must read. They do not remove the need for a reader.
Does this mean we should stop using AI to write code?
No, and nothing here argues for that. The losses come from shipping code nobody read, not from generating it. Teams that keep the gain while paying the cost treat reading as part of the work: they cap what enters review, route risky changes to a human and protect time to explain what landed. Generation without comprehension is the problem, not generation itself.
Which AI-generated changes still need a human to read them?
Any change that alters behaviour in a way a test would not describe: authentication, data handling, payments, migrations, dependency upgrades and anything touching shared state. Cosmetic and test-only changes can pass on automation. The sharper test is whether a reviewer would learn something about the system by reading it, because if they would, skipping the read loses that knowledge.
What happens if the senior engineer paying the tax resigns?
The debt becomes visible at once. The code keeps running, but nobody can explain why parts of it behave as they do, and incident resolution slows because the fastest route to the answer has left. That concentration is the bus factor risk in plain form, which is why the tax belongs in retention conversations rather than workload ones.
How long does it take to repay cognitive debt?
It is repaid in hours of reading, explaining and reconstructing, and the total depends on how far understanding has drifted from the code. No refactor clears it, and a rewrite can increase it. The practical approach is continuous repayment: pair a reader with each significant change instead of scheduling a catch-up that never happens.
What are Agent Insight Sessions and do they actually work?
Agent Insight Sessions are structured walkthroughs where an engineer explains a change, human or AI-generated, so the reasoning becomes shared rather than private. They rebuild understanding deliberately, which is what review used to do as a by-product. They cost the same senior time the tax already consumes, so they work only when that time is protected rather than added to the week.
Is cognitive debt just a new name for bad documentation?
No. Documentation records what someone chose to write down. Cognitive debt is the gap between what the system does and what the team can explain, whether or not anyone wrote it down. Accurate docs reduce the gap, but a team can hold good documentation and still be unable to say why a component behaves as it does.
How do I make the case to leadership when none of this appears on a dashboard?
Translate it into things leadership already tracks: incident resolution time, review turnaround for the people who can actually assess risk, and retention risk among senior engineers. Then name the governance angle. Under APRA CPS 234 and the Notifiable Data Breaches scheme, “nobody read it” is a question a regulator can ask, and answering it needs evidence rather than assurance.
Does reading AI-generated code take longer than reading a colleague’s code?
Often yes, but not because the code is worse. Human-written code arrives with shared context: the author, the ticket, the conversation around it. AI output arrives with none, so the reviewer reconstructs intent from the diff alone. That reconstruction is the work, and it is also where the understanding gets built.
Is it worth reviewing AI-generated code if the tests pass?
That depends on what the tests can see. Passing tests show the behaviour someone thought to check, not the behaviour nobody specified. A diff can pass every test and still introduce hidden state, a redundant dependency or a design decision the team will live with for years. Review is how that judgement enters the record.
