The Senior Engineer Signal: The 2026 Risk Your Velocity Metrics Hide

What the seniors are actually looking at#

Start with the code itself, because that is where their nose twitches first.

Lines classified as “copy/pasted” rose from 8.3% of changed code in 2021 to 12.3% in 2024. Refactored (“moved”) lines fell from about 25% of changes to under 10% over the same window. That was the first time in the dataset that copy/paste outpaced refactoring.

— GitClear, AI Copilot Code Quality 2025 (211 million changed lines, 2020–2024)

Read that again, because it is the whole section. We are pasting more and reshaping less. The codebase is getting wider, not cleaner. Duplication is cheap to generate now, so it gets generated, and the boring work of folding five near-copies back into one function is exactly the work an AI will not volunteer for and a junior will not notice is missing.

A senior notices. That is the job. They have maintained the system that got wide and then got brittle, and they can smell the early version of it.

The delivery numbers point the same direction.

A 25% increase in AI adoption was associated with a 7.2% drop in delivery stability and a 1.5% drop in throughput. AI makes it easy to write more code, batch sizes go up, and bigger changesets carry more risk.

— Google’s DORA, State of DevOps 2024

Throughput down too. That one surprises people. The story everyone sold was “AI writes the code faster, so we ship faster.” What actually happens is the batch gets bigger, the review gets harder, and the thing that breaks costs more to unbreak. Net, slightly slower. Measurably less stable.

So the seniors are not wrong, and they are not nostalgic. They are looking at a real second-order effect that the first-order metric hides.

The trust line keeps dropping#

Here is the part that should bother you most, because it is moving the wrong way over time.

Trust that AI output is accurate fell from 40% to 29% year over year. Favorability dropped from 72% to 60%. More developers now actively distrust AI accuracy (46%) than trust it (33%). The top frustration, named by 45%, is “AI solutions that are almost right, but not quite.”

— Stack Overflow Developer Survey 2025

“Almost right, but not quite” is the expensive failure mode. A wrong answer you catch. A nearly-right answer you ship, and then you debug it three sprints later with no memory of why that line is there. The cohort best at spotting “almost right” is the senior cohort. They are also the cohort whose trust is lowest and dropping fastest.

Hold that next to the number from Part 1. Across the Sonar 2026 survey, 96% of developers do not fully trust that AI-generated code is functionally correct, yet only 48% always check it before they commit. Half the industry is shipping code it does not trust, unverified. The other half, the half that does check, is carrying the verification load for everyone. Guess which half is senior.

None of this is an argument against AI. I use it every day. It is an argument about who is holding the line, and whether you have noticed.

Why the velocity dashboard hides the bill#

Walk into a 2026 board meeting and you will see the throughput chart. Commits up. PRs up. Story points up. AI adoption up and to the right. Everyone nods.

The chart is real. It is also the wrong chart.

What it does not show: churn. The share of code rewritten within two weeks of landing has been climbing, which means more of that throughput is rework, not progress. It does not show the duplication creeping in. It does not show delivery stability sliding 7% for every 25% of adoption. And it definitely does not show the trust line falling off a cliff inside your own engineering org.

You are measuring the bump and not the bill. The bump lands this quarter, on a slide. The bill lands later, in an incident review, in a security finding, in the three weeks it takes a senior to untangle a “mostly working” subsystem nobody fully understands. By then the person who flagged it early has stopped flagging.

This is the same failure I described in Part 1: the dangerous stuff is the stuff your instruments do not surface. There it was parallel agents with no audit trail. Here it is code-quality decay with no panel on the dashboard. Same disease. The number that would scare you is the number nobody is plotting.

The talent math nobody puts on the board deck#

Now the part that turns a code-quality story into a people story.

The read a lot of leaders took from “juniors get the biggest AI boost” was blunt: we need fewer expensive seniors. Salesforce said the quiet part on the record. Marc Benioff told investors the company would hire no new software engineers in 2025, citing a 30% engineering productivity gain from AI, while growing the sales team by up to 20%. “We are the last generation to manage only humans,” he added.

Maybe that math works at Salesforce’s scale. For most orgs it removes two things at once, and they will not notice until both are gone.

It removes the supervisory layer. The seniors are the review capacity. They are the people who catch “almost right.” AI does not reduce the need for that capacity. The GitClear and DORA numbers say it raises it. You are generating more code, more duplication, and more nearly-right merges, all of which need more senior eyes, right when the plan is to have fewer.

And it removes the pipeline. Juniors become seniors by doing the work that AI now does for them and getting it reviewed by someone more experienced. Cut the junior reps and the senior review at the same time and you are not running lean. You are eating the seed corn. There is no 2030 senior bench if 2026 juniors never get past prompt-and-paste.

Then there is the quieter attrition, the kind that does not show up as a layoff. A senior whose job becomes uncredited cleanup of machine output, whose judgment is treated as a tax on velocity, whose “I don’t trust this merge” is overruled by a burndown chart, does not file a complaint. They disengage. Then they leave. And they take the context for your load-bearing systems with them, the context that was never written down because it lived in their head.

You do not get a dashboard alert for that either.

What to actually do about it#

Five things, and none of them is “stop using AI.” That ship sailed and it was the right ship.

1. Treat AI productivity as non-uniform by seniority. The boost is real for juniors on well-trodden tasks and small for seniors on hard ones. Plan and staff around that instead of averaging it into one number that flatters the tool and insults your best people.

2. Make the supervisory layer the senior’s actual job, on paper. Review, architecture, the boundary work I described in Part 1. Not a thing they squeeze in between tickets. The thing they are measured and paid for. If catching “almost right” is now the highest-value work in the building, fund it like it is.

3. Measure quality, not just throughput. Put churn, duplication, refactoring rate, and change-failure rate on the same screen as commit count. If your dashboard only shows the bump, your board only sees the bump.

4. Measure AI’s impact per team, and keep it off individuals. Segment DORA before and after adoption, by team, so you can see who is actually getting faster and who is just getting busier. Tie it to developer sentiment, not surveillance. I wrote up the framework for doing this without wrecking trust in AI Didn’t Fix Productivity. Measurement Did. The moment this becomes a stack-ranking tool, the seniors stop telling you the truth, and the truth was the whole point.

5. Protect the pipeline on purpose. Keep hiring and growing juniors, and keep them paired with seniors on real review, even though AI can fake the output of their early-career work. You are not buying this quarter’s tickets. You are growing the people who will hold the line when the next wave of tooling shows up without its supervisory layer attached.

Three questions for your next board meeting#

Same format as Part 1. Ask them out loud and watch the room.

1. Show me churn, duplication, and change-failure rate next to our throughput chart. If we cannot put them on the same screen, why not?
2. What is our senior-to-junior ratio, where is it heading over the next eight quarters, and who is reviewing AI-generated code today?
3. Which of our load-bearing systems has its context living only in one senior engineer’s head, and what happens to that system if they leave this year?

If those land as uncomfortable silences, you found the work.

The senior engineer signal is the canary. It is quiet, it is unglamorous, and it is the cheapest early warning you will ever get. The organizations that listen keep the people who can tell “looks correct” from “is correct.” The ones that read the throughput chart, call it a win, and thin out the bench will find out the difference the expensive way. In the incident review. With the one person who saw it coming already gone.

That was the more interesting question all along. Not how fast the machine can write. How long you keep the people who know when it is wrong.

GitKraken Ambassador Note#

As a GitKraken Ambassador, I write about how engineering teams actually operate when the tooling changes under them, not about feature launches.

This whole two-part series came down to one idea. The risks that hurt you are the ones your instruments do not show: parallel agents with no audit trail in Part 1, code-quality decay and senior disengagement with no panel on the dashboard here. Instrument the thing you cannot see. Then keep the people who can see it anyway.