Seniority is now a verification skill
Most engineering ladders still promote on evidence of production, which is the one input that stopped being scarce. The senior work now is deciding what is true about a change nobody wrote by hand.
Every promotion round has the same argument in it. Someone reads out a packet, the evidence is a list of things the candidate shipped, and a person in the room says some version of “but did they do the hard part”. Nobody can quite say what the hard part was, so the packet with the most shipped work usually wins.
That argument used to resolve itself, because volume of shipped work correlated well enough with judgement. It does not any more. With around 41 percent of production code AI-generated by early 2026, a list of merged changes tells you what an engineer had access to, not what they are capable of.
My position: the durable senior skill is verification, and most ladders do not measure it because they never had to. Fixing that is a smaller job than it sounds, and it is worth doing before your next promotion cycle rather than after.
What the ladder was actually measuring
Read a typical engineering ladder honestly and it measures three things: scope of work produced, independence while producing it, and influence over other people producing it. Every rung is a statement about output and the autonomy with which it was generated.
That was a reasonable design when producing correct code was hard, slow and revealing. Watching someone build a non-trivial system told you about their judgement because judgement was the rate limiter on the building.
Take the rate limiter away and the signal degrades in a specific way. Output volume becomes a measure of tooling and appetite. Independence becomes a measure of how comfortable someone is merging without asking. And influence over other producers matters less when the producers are not people.
What remains scarce is the ability to look at a change and know, quickly and with reasons, whether it is right, whether it belongs, and what it will do to everything around it.
Verification is not the same as review
This is where the conversation usually goes wrong, so it is worth separating.
Review is a step in a workflow. It has a queue, an approver and a state transition. Verification is a capability: establishing that a claim about a system is true. You can do the first without doing the second, and the LinearB 2026 benchmarks suggest a lot of organisations are, with pull requests merged with zero review up over 31 percent and median review duration up over 400 percent on the ones that do get looked at.
Verification breaks down into skills that are teachable and separately observable.
Deciding what would have to be true. Before reading a diff, naming the two or three conditions under which this change is wrong. Engineers who do this find problems in ten minutes that others miss in an hour, because they are looking for something.
Reading for absence. Most agentic failures are not wrong lines, they are missing ones. The error path that was never written. The migration that handles the forward case only. Reading for what is not there is a distinct skill and the one that separates people most sharply.
Knowing the blast radius without looking it up. Holding enough of the system to say “this touches the thing that also feeds billing” without opening another window. This is the part that genuinely takes years, and it is the strongest argument for tenure in a codebase mattering more, not less.
Being usefully unconvinced. Saying “I do not believe this yet” and then naming the evidence that would settle it. Vague discomfort is not verification. A named test is.
Evidence most packets contain
- Systems shipped, with scope
- Projects led end to end
- Volume and pace of merged work
- Design documents authored
Evidence that now discriminates
- Defects found before merge, and how
- Changes stopped, with the reason recorded
- Criteria written that later caught something
- Blast radius calls that turned out right
What this looks like written into a ladder
You do not need to rewrite the document. You need to change what counts as evidence at the top two or three rungs, and say so out loud before the cycle starts rather than during it.
The practical test for whether your ladder has made this shift: can an engineer be promoted on a body of work in which they personally typed very little? If the honest answer in your organisation is no, the ladder is measuring production and the promotion committee will keep having the same unresolvable argument.
The awkward part about juniors
There is a real problem underneath this and I do not want to skate past it. Entry-level developer postings are down around 40 percent, and if seniority is verification, the obvious conclusion is that you should only hire people who already have it.
That conclusion is wrong, and it is wrong on the organisation’s own terms. Verification requires system context, system context is acquired by working in a system over time, and the people who have it in five years are the people you let in now. Some large enterprises have increased junior hiring while startups cut it, which reads as one group pricing a five year input and the other pricing a twelve month one.
The change that helps is not hiring fewer juniors. It is putting them on verification earlier than felt reasonable before, because the traditional apprenticeship of writing lots of code under supervision has lost most of its teaching value.
Where this breaks down
Verification is much harder to evidence than output. A shipped system is visible in a changelog. A defect caught before merge leaves almost no trace, and asking people to log their own saves produces exactly the gaming you would expect. This is the strongest objection to my position and I do not have a clean answer. The partial one is to ask for two or three narrated examples in a packet rather than a count of anything.
It can become a licence for obstruction. If stopping changes is rewarded, some people will stop changes. Any ladder change of this kind needs an explicit counterweight: the reason a change was stopped has to be recorded and has to hold up later, and being wrong about it repeatedly has to cost something.
Production has not stopped mattering. Somebody still has to be able to build the hard thing when the agent cannot, and those situations are exactly the ones where the stakes are highest. A ladder that stops valuing construction entirely will discover this at the worst moment.
Some organisations genuinely still need volume. An early stage company with no users and no compliance surface is right to promote for shipping. The argument here scales with the cost of being wrong, and if that cost is currently near zero, ignore me until it is not.
And this may just be the old craft argument in new clothes. Senior engineers have always claimed the valuable part is the judgement, conveniently the part they have. Discount accordingly, and test the claim against your own incident record rather than against my reasoning.
The takeaway
Ladders were built to measure production because production was the scarce input. It is not any more, and the promotion argument that keeps failing to resolve is a symptom of a rubric measuring the wrong thing.
Seniority now means being able to establish what is true about a change: what would have to be false for it to be wrong, what is missing rather than incorrect, what it touches, and what evidence would settle it.
If you take one thing into next week: before your next promotion cycle, ask two calibrated reviewers to score the same packet on verification evidence alone. If they cannot find any, that is not a candidate problem.