How to define "senior" when agents compress the output gap

"Senior" used to be visible in the output. The senior engineer shipped more, broke less, and could be left alone with a hard problem. Coding agents have compressed the first part of that signal. At Imprint, Will Larson reports the average engineer merging four times the pull requests of two years ago, two teams at ten times, and one engineer at twenty-five times the old average (Larson, October 2026). When a mid-level engineer with a good agent setup out-produces last year's senior, throughput stops telling you who is senior. Something else has to.

This playbook gives you a working definition of "senior" for 2027 hiring, three criteria you can test, a way to think about senior density on a team, and a warning about the junior pipeline that the data is already flashing.

What do you need before you start?

You need to separate what your seniors produce from what they make possible for everyone else.

• For each senior on the team: their own merged output, and the output of the people whose work they review, unblock, or design for.
• The decisions in the last two quarters that only a senior could have made, and what they cost when they were made late.
• Your current junior and mid headcount, and who is responsible for their growth.
• Your team's trust posture toward AI output: in DORA's 2025 survey, 90% of respondents used AI at work but only 24% reported a great deal or a lot of trust in it (DORA, 2025). Someone on the team sets that posture.

Why doesn't throughput identify seniors anymore?

Because per-engineer output is now dominated by tooling adoption, which is cheap to copy and says nothing about judgment.

Why this matters: Larson's spread, 4x on average and 25x at the top, is a spread in how people use agents, not a spread in seniority. The same month, a Harvard study across 718 firms found that AI agents raised pull requests 23% while review time rose 49% and resolved issues barely moved (Chen & Stratton, August 2026). Output went up; shipped value did not follow. The engineers who close that gap are not the ones producing the most; they are the ones deciding what should be produced, verifying it, and keeping the rest of the team from drowning in review.

What good looks like: a team where you can name the person whose judgment raised everyone else's merge rate, and that person is the one you call senior.

What should "senior" mean now?

An engineer who raises the system's acceptance rate, not their own throughput. Three criteria make that testable.

Why this matters: each criterion maps to a skill that agents do not supply and that the output numbers hide.

1. Verification design. Can they specify how a change will be checked before it is written: tests, contracts, the acceptance criteria an agent never sees? DORA's framing is that AI amplifies what a team already is; verification is what it amplifies on a good team.
2. Review leverage. Does their review make other people's code safer and faster to merge? Measure it: review latency and change-failure rate on the services they own, before and after.
3. Blast-radius judgment. Can they tell a change that is cheap to be wrong about from one that is not, and route each accordingly? Larson's small-change rule is exactly this judgment, written down as policy.

What good looks like: a candidate who, asked to review a generated change, starts with "what does this touch?" rather than "is this correct?"

How do you test for it in an interview?

Replace the "build this" exercise with a "verify this" exercise, and score the reasoning.

Why this matters: a build exercise now measures the candidate's agent setup. Give them a 200-line generated change with one logic error and one design risk, 30 minutes, and ask for a written review plus a merge decision. Score: did they read the whole change, did they find the error and by what means, did they name the design risk, did they ask what the change depends on. Then ask them to design the checks they would want before the next change to that module ships. If you want the full interview segment, The bottleneck moved from writing code to reviewing it walks through it.

What good looks like: two interviewers scoring the same session land within a point on each criterion.

How many seniors does a team need?

Enough that every service has a reviewing authority, and no fewer than it takes to keep a junior pipeline alive.

Why this matters: the temptation in 2027 is to run five seniors with agents and no one else. The data on juniors argues against it. Stanford's analysis of ADP payroll data through June 2026 found employment of 22-to-25-year-olds in AI-exposed occupations 19% below its expected level, driven by reduced hiring rather than layoffs (Brynjolfsson, Chandar & Chen, August 2026). Engineers interviewed by The Pragmatic Engineer describe the same mechanism from inside teams: seniors hand tasks to agents instead of juniors, and the juniors stop growing (Orosz & Nilsson, May 2026). A team with no path for juniors in 2027 has no seniors in 2030.

What good looks like: a stated senior-density target per service, and a junior track with explicit learning time that agents do not get to absorb.

What are the common mistakes?

• Promoting the highest-output engineer. Output now measures tooling. Promote the person whose judgment others depend on.
• Hiring "senior" by years. Years of writing code do not predict skill at verifying code someone else wrote.
• Cutting the junior line to fund agent seats. It balances this year's budget and empties the senior pipeline later.
• Letting trust in AI output be a personal setting. It is a team policy, and a senior should own it.

How does Nexton do this?

Every engineer is interviewed by another engineer before you see the profile, and the written evaluation comes with the candidate. That interview tests the three criteria above on real work, because an engineer running it can tell verification design from fluency and review leverage from confidence.

The average from brief to signed offer is four weeks, and the first matched candidate arrives in under 72 hours, matched, interested, and engineer-vetted. If you are rewriting what "senior" means in your 2027 brief, How to write an engineering brief that hires for judgment, not throughput has the template, and How AI is reshaping engineering roles: what to hire for in 2027 covers which seats are moving.

If your definition of senior still lives in the output numbers, it's worth a conversation.

FAQs

Is a senior engineer still worth the premium if agents do the writing?
More, not less. The scarce work is deciding what to build, how to verify it, and what is safe to merge. Agents raise the volume of that work; they do not do it.

Should I stop hiring junior engineers in 2027?
The data shows hiring of early-career workers in AI-exposed roles already running well below trend. Teams that stop entirely are making a pipeline decision, not a cost decision. Keep a junior track with explicit learning time.

How do I test seniority without a coding exercise?
Use a review exercise on a generated change and a verification-design question. Both measure judgment directly, and neither can be solved by a better agent setup.

Sources: Will Larson, "Speeding up code review with small-change", October 2026 · Chen & Stratton, "Artificial Intelligence in the Firm", Harvard, August 2026 · Brynjolfsson, Chandar & Chen, "Canaries in the Coal Mine?", Stanford Digital Economy Lab, revised August 2026 · Orosz & Nilsson, The Pragmatic Engineer, May 2026 · DORA, State of AI-assisted Software Development 2025. Verified October 2026.