Every proxy the industry used for seniority ran through output, and an agent now produces output. So the ladder has to run through something the agent cannot supply. This one uses a single axis, applied five times. At each rung, name the thing you are the last human check on before it is real. Five rungs, each with behaviors you can watch, a tell for how the rung gets faked, and one artifact that settles the question.
They are different documents on purpose, and collapsing them ruins both.
The Comprehension Standard is explicit that its levels grade diffs and not people. A staff engineer merges an L1 dependency bump on Tuesday, and a first-year engineer an L3 pricing-rule change on Wednesday. Read as a career ladder, it becomes an insult and stops being usable as a merge bar.
But teams still need to answer the other question, because somebody has to decide who the team trusts with what. Left unwritten, that decision gets made by tenure, by volume, or by who speaks confidently in meetings. This document exists so the second question has its own vocabulary and stops borrowing the first one's.
| The Comprehension Standard | This ladder | |
|---|---|---|
| Grades | A change, at merge time | A person, over a quarter |
| Asks | Is this change understood? | Who is trusted to be the last check? |
| Changes | Every pull request | Rarely, and in both directions |
| Lives in | The repo, enforced by the harness | A quarterly conversation, enforced by nobody |
| Confusing them | Reading "L3" as a seniority level. Makes the standard an insult and the ladder unfalsifiable. | |
The standard says what a check consists of. The ladder says who the team trusts to be the last one. A team needs both, and neither substitutes for the other.
Not five skills. One question asked about five things, each larger than the last.
R1 EXPLAINS last check on · nothing yet
every change of theirs gets a second reader
R2 MERGES last check on · their own ordinary change
"ordinary" is whatever the charter says it is
R3 REVIEWS last check on · somebody else's change
the rung where approving becomes a decision
R4 CONSTRAINS last check on · the rules that check everyone
stops changing code, starts changing the system
R5 SCOPES last check on · whether the work should exist
the only rung whose main output is deletion
A single axis is a constraint worth defending. Most ladders are a list of adjectives, and a room can argue adjectives into whatever conclusion it already wanted. "Last check on what" is answerable by watching what happens when this person is on holiday.
The rungs are cumulative in trust but not in activity. An R4 still merges their own changes and still reviews other people's. What changed is that something new now stops with them.
Nobody skips. A person who has never held a correct finding under pushback will not author the team's constraints well. Authoring a rule means holding a position, permanently and in writing, against everyone who finds it inconvenient.
Last check on nothing. Everything they produce has a second reader, and the work of this rung is becoming worth reading.
Complete fluency about what the change does, total silence about how it could be wrong. The description is excellent, the mechanism is understood, and the question "what would make this fail" produces a pause and then a guess. That is a person describing code, not a person who has examined it.
Two consecutive changes where all four claims land without prompting: what changed, why it is correct, what it could break, how you would know. Not written down anywhere special. Said out loud, to a person, twice running.
Someone sitting at R1 nine months in is almost never a talent problem. It is nearly always a team that never asked anybody to explain anything, so the fix is on the team's side. The first ninety days exists mostly to keep this rung short.
Last check on their own ordinary change. Nobody reads it after them, which means what they refuse defines the rung, not what they produce.
"Ordinary" is not a vibe, but the exemption list already written in the charter: the changes the team has decided do not need the raised bar. Money, authorization, data integrity, and anything nobody can cheaply roll back stay off this rung, however good the person is. That exclusion is a property of the change, not of the person.
Throughput climbs and escaped defects climb with it. They are merging what passes rather than what is right, and green is doing the deciding. The quieter version of the same tell: six months of history with no record of ever turning down anything the agent proposed. Nobody is that well served by a model.
Sixty days of self-merged ordinary changes with no defect a second reader would have caught. And at least one change they raised to the higher bar themselves. The second half matters more: it shows a person applying the exemption list rather than skipping it.
Last check on somebody else's change. The first rung where approving is a decision with a cost attached to their name.
Findings that are only ever stylistic: a way of participating in review without ever being accountable for the semantics. And its mirror, the review that never ends, where every approval waits behind one more question. Both are strategies for never being the person who said yes to the thing that broke.
One catch in production-bound code that a reasonable person would have missed. And, harder to obtain and more diagnostic, one approval that later broke. They handled it by naming what they would check next time, not by relitigating whose change it was.
The weekly rep for this rung is reverse-review, which exists to produce these two artifacts on a schedule instead of by accident.
Last check on the rules that check everyone else. The first rung whose output is not code.
The charter only ever grows. Every incident adds a paragraph and nobody ever removes one, until the charter is too long to finish. At that point it has stopped applying to anything. The person producing that outcome usually feels the most responsible in the room, which makes this tell hard to raise.
One rule merged with the incident named in the pull request. One rule deleted with the reason named. The deletion is the discriminator: enthusiasm produces rules, and removing one requires knowing what the system still catches.
Last check on whether the work should exist. Measured mostly in things that never got built.
This rung got more valuable, not less, when generation got cheap. When building something took a quarter, the cost of a bad idea was visible and someone usually stopped it. When a plausible implementation appears in an afternoon, nothing external stops it. So the only remaining brake is a person willing to say the work should not exist while everyone is already excited.
The reflexive no, which is cheap, feels rigorous, and is indistinguishable from judgment for about a year. And the reflexive yes rebranded as enablement, which is the same abdication wearing a friendlier word. Both are ways of not deciding, and both scale badly.
A written record of scope calls, including at least one they got wrong and reversed in public. A ledger with no reversals in it is a ledger nobody was checking.
The ladder needs a new axis because the old signals were downstream of typing speed, and typing is now free.
| Proxy | What it used to approximate | What it measures now |
|---|---|---|
| Changes merged per week | Capacity, roughly | Prompting speed |
| Time to first working version | Familiarity with the codebase | Model latency |
| Breadth of API recall | Years of exposure | Nothing at all |
| Lines of code | Very little, even then | Less |
| Rejection rate, with reasons | — | Whether judgment is being applied |
| Escape rate on self-merged work | — | Whether R2 is real |
| Do others' changes improve after this person touches them | — | Whether R3 is real |
| Does work get smaller when they scope it | — | Whether R5 is real |
Notice that every surviving signal is about subtraction: what got rejected, what did not escape, what got smaller. Subtraction is not an aesthetic preference, but a consequence of which half of the work got automated. Production did, so the human contribution shows up in the gap between what got produced and what shipped.
Quarterly, thirty minutes, two people who have actually seen the work. Not a committee.
Never calibrate a person against another person, only against the artifact list. And never run this in the same meeting as compensation. The moment a rung is worth money, people start manufacturing the artifacts and the whole instrument goes blind.
A rung describes what someone is doing now, so it is not a possession, and it moves down as well as up.
The common regressions are specific and recognisable. An R4 who has not deleted a rule in a year has drifted back to R3 with extra paperwork. An R2 who stopped rejecting agent output during a hard quarter is not R2 any more, whatever the tenure says. And an R5 who has said yes to everything since the reorg is doing a different job now. It may be a fine job, but the ladder should say so.
Say it plainly, early, and reversibly. A rung is not a title, does not appear in anyone's email signature, and does not move compensation on its own. That is what makes it safe to move a rung down. Being safe to move down is the entire reason it means anything when it moves up.
Ladders that only ratchet upward produce teams with six senior engineers and no last check. Agent-written code punishes that shape fastest.
Four things this is not for, and one thing to keep if you rewrite it.
Fork it freely. Rename the rungs to match your vocabulary. Cut R5 if your team has no scoping authority, and add a rung if this one misses a layer. Keep the axis: one question, asked about larger and larger things, answerable by looking at what stops with this person. The moment people describe a rung with adjectives instead, it has become unfalsifiable and it will drift.
Take one person and answer the single question honestly: what is the last thing that stops with them? Most teams find at least one person whose real rung and assumed rung are two apart. And the surprise runs upward roughly as often as downward.