The Engineer Who Shipped Less Code Got the Promotion — Here's Why

Day 3: The Agent Writes The Code. So What Gets You Promoted?

Your agent can turn a ticket into a working diff in ten minutes. So a sprint full of merged PRs, green dashboards, fifteen tickets closed — none of that proves anything anymore. What actually gets measured now is what you did before you told the agent to run, and what you did after it handed the result back.

Day 1 and 2 covered what agents change about your actual work — how tasks get scoped, run, reviewed. Today's about what that same shift changes about how you get evaluated.

The old proxy just broke

PR count and velocity dashboards used to be a decent stand-in for judgment. Not because anyone genuinely believed lines of code equaled value — but because typing was the bottleneck. Writing correct code took real time and real thought, so an engineer who reliably shipped more of it usually had more judgment behind it too. The two were correlated by construction, and everyone quietly started treating the proxy as the real thing.

Agents remove the bottleneck. Typing is cheap now, for everyone. An engineer with mediocre judgment can prompt an agent, skim the diff, and merge fifteen PRs in a week — dashboard lights up green, and it means almost nothing. The proxy didn't get worse. It just stopped measuring what it used to measure.

The moment at PhoenixDX

Same sprint, two engineers, both leaning on an agent for most of the implementation. Engineer A shipped the most PRs on the team — fast turnaround, agent-generated code, light review, mostly correct. Engineer B shipped fewer. But before touching the agent, B wrote a two-paragraph spec that ruled out an approach the ticket practically begged for — one that would've broken an existing integration. Mid-review, B caught an edge case the agent's implementation quietly mishandled: a null state that only showed up for a slice of customers. And B talked a stakeholder out of a feature request that, as scoped, would've burned the next sprint on a use case touching almost nobody.

B got the promotion. Not despite shipping less code — because the code was the smallest part of what B contributed that sprint.

What the promoted engineer actually did differently

• ▹Wrote the spec first — constraints, non-goals, and the one wrong assumption baked into the ticket — before the agent could go build against it.
• ▹Read the diff for what the agent couldn't know. Not 'does this compile,' but 'does this break for the customer segment on the old pricing tier.' That's where the edge case surfaced.
• ▹Killed a feature before a single agent-hour got spent on it, because the request wasn't worth a sprint for the sliver of users it would've helped.

Reframe: impact is decisions, not lines

When an agent does the typing, your seniority shows up at three points around its execution — not inside it.

• ▹Before — the spec. What problem, what constraints, what's explicitly out of scope. Hand an agent a vague prompt and you get a fast, confident, wrong implementation.
• ▹During — the steer. Catching a bad assumption mid-run, redirecting the agent, or just stopping it before it burrows further into the wrong approach.
• ▹After — the call. Deciding what actually ships, what gets cut, and which technical debt you're knowingly signing up for versus what you're refusing to accept.

The uncomfortable part

This makes 'busy' look worthless and 'quiet' look like it might be the most important work on the team — and that messes with people who built their whole identity around output. If your sense of self-worth at work has been 'I ship a lot,' this shift feels like the floor moving. Shipping didn't stop mattering. It just was never the point. It was always a proxy, and the proxy just lost its cover.

Before Day 4

Pick one task this week. Before you let an agent near it, write the spec and your review notes first — what you expect the agent to get wrong, what the non-obvious constraint is, what 'done' actually means. Then run the agent and check its output against what you wrote. Whatever it missed that you'd already flagged — that's your judgment, showing up in a form no dashboard is currently counting.

Extend your knowledge

• ▹Pull your last five merged PRs. Count the decisions in them — scope calls made, edge cases caught, things you refused to build — against lines changed. See which ratio your team actually rewards.
• ▹Look at your team's promotion packet or review template. Does it ask for PR or commit counts, or for decisions and their outcomes? If it's still counting commits, that's worth raising with your manager.
• ▹In your next 1:1, ask your manager point-blank what they'd point to as your highest-impact decision this quarter — not your highest-output week.
• ▹Read Gergely Orosz's (The Pragmatic Engineer) writing on how senior and staff-level impact actually gets evaluated. It predates agents, but it maps onto this shift almost exactly.