The Scarce Skill Isn't Writing Code. It's Knowing What Shouldn't Exist.

Two engineers on the same team, same seniority, both good.

The first one is fast. Agent-fluent, ships a lot, closes tickets nobody else wants. Their PR count is the highest on the team and their name is on half the recent merges.

The second one shipped less this quarter. What they did instead: they wrote down why the notification service must never call the identity service directly, turned it into a dependency lint rule, and killed three agent-proposed changes that would have violated it. They noticed that a generated retry implementation would have hammered a partner API and wrote the rate-limit constraint into the repo so nobody — human or agent — would rediscover it the hard way. They redesigned the verification for the auth path so a whole class of regressions became impossible to merge.

At review time, which one has the better case?

In most organizations today, it’s the first one. Throughput is legible. Judgment is invisible. Every performance system we have was built to measure output, and output is exactly the thing that stopped being scarce.

That asymmetry is the biggest career risk in engineering right now, and it’s the thing this article is about.

The scarce skill is no longer producing code. It’s knowing what should exist, knowing what must not exist, and being able to bound a system so that neither is left to chance.

This is part three of Rethinking the SDLC. The first piece named the inversion. The second replaced the ticket with an intent package. This one is about the human at the center of it — what the role actually becomes, and how to survive the transition with your value visible.

The argument seniors keep losing

#

Here’s the conversation happening in engineering orgs everywhere, usually in a slightly hostile tone.

A senior engineer says AI-generated code is worse. They’re often right. Veracode ran 80 curated tasks across more than 100 models and found risky security flaws in 45% of them. A January 2026 study of autonomous coding agents found static-analysis warnings up 18% and cognitive complexity up 39%. Developer trust in AI output is falling, not rising: 29%, down from 40% the year before, with 46% actively distrusting the output and only 3% saying they highly trust it.

So the senior has data. And they still lose the argument in the quarterly review. Every time.

They lose because “the code is worse” is an unfalsifiable claim in a system that measures merges, and because the counter-argument is simple: then review it. Which sounds reasonable right up until you notice it converts the senior engineer into a permanent verification appliance. That’s exactly what’s happening. A survey of 2,147 engineers found 71% often feel like a middleman between AI output and actual results. LeadDev documented an organization that lost three mid-level engineers in six to eight weeks while shipping 40% faster — right up until the production incidents arrived.

I’ve watched this dynamic form up close, and the diagnosis is uncomfortable: the senior engineer’s objection is correct and their position is wrong. Defending code quality by volunteering to read more diffs is a losing move at any volume. It doesn’t scale, it doesn’t get measured, and it burns out the person doing it.

The winning move is different. Stop arguing that the code needs a human. Start building the system that decides which code needs a human, and make yourself the person who designs that system.

What “governor” actually means, because it isn’t a title upgrade

#

I use the word deliberately. A governor, in the mechanical sense, is the component that bounds a system’s behavior — it doesn’t produce the power, it determines the limits within which power is allowed to operate. That’s the job.

Not manager. Not reviewer. Not prompt engineer. The engineer’s work shifts from producing the change to defining and enforcing the space of acceptable changes, and then owning what comes out.

Concretely, five jobs.

1. Decide what should exist

#

Someone has to know which system we’re building and why this shape rather than the four alternatives an agent will happily generate. Machines can produce architectures. They can enumerate tradeoffs. What they cannot do is hold your business, your organization, your five-year cost structure, and your partner contracts in mind and say this one, because of that.

This was always the senior job. It just used to be bundled with implementation, which made it look like a bonus rather than the product.

2. Decide what must not exist

#

This is the underrated half, and it’s where I’d spend most of a senior engineer’s week.

An agent will never refuse to build something on the grounds that it’s a bad idea. It has no stake. It doesn’t carry the pager, doesn’t sit in the postmortem, doesn’t explain the incident to a customer. Refusal is a judgment that requires consequences, and consequences are attached to humans.

So the governor’s job is to make refusals explicit and durable: this service does not talk to that one; this data never leaves this boundary; we do not add a third caching layer; we do not take this dependency; this module has one owner and one entry point. Every one of those is a decision that prevents an entire family of future systems from existing. Written down, it’s leverage. Left in your head, it’s a bottleneck with a heartbeat.

3. Design the verification

#

If you only take one thing from this article: the highest-leverage engineering artifact in an agentic organization is the verification strategy for a change class.

Not the change. The strategy. “Any change to the notification-delivery path must demonstrate idempotency under duplicate delivery, must not increase p99 beyond X, and must pass a property test over the following invariants.” Write that once and every future change in that class arrives pre-verified, by machines, forever.

Anthropic’s engineering team, describing what it took to point 16 parallel agents at building a C compiler, put the whole problem in one line: “it’s important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem.” That’s the sentence that reorganizes a career. In a world of cheap execution, the person who designs the verifier has more effect on system quality than the person who writes the implementation — by orders of magnitude, and permanently rather than once.

4. Bound the blast radius

#

Every agent lane needs limits that hold when the agent is wrong, because it will be. Which credentials. Which environments. Which actions are reversible. What requires a human between the work and its effect. What can never be executed without a named person saying yes.

Most organizations set these limits by accident, inheriting vendor defaults and calling it policy. Setting them on purpose, per workflow, with escalation and demotion rules, is engineering work — and it’s the difference between an incident and a non-event. I’ll take this apart properly in the pieces on infrastructure, incidents, and security.

5. Own the outcome

#

Everything above is architecture. This one is accountability, and it’s the part that can’t be delegated to anything.

When the change reaches a customer and behaves badly, a person answers for it. Not “the agent got it wrong.” Not “the model hallucinated.” A name. That’s not a moral flourish — it’s the load-bearing element of the entire operating model. An organization where nobody owns agent output has no feedback loop, and a system without a feedback loop degrades until it fails visibly.

The skill that’s actually atrophying, and it isn’t syntax

#

There’s a real debate about whether engineers lose capability by leaning on AI. Anthropic ran a randomized trial and found that developers learning a new library with AI assistance scored 17 percentage points lower on mastery than those who learned without it. LeadDev’s 2026 Engineering Leadership Report has 38% of leaders worried juniors will get less hands-on experience in AI-heavy workflows. I’ve written before about why I’m pro-AI and still worried about our next senior engineers.

But notice which skill is at risk, because people keep naming the wrong one.

Nobody’s career is going to end because they forgot how to write a for-loop. The capability that atrophies is calibrated suspicion — the ability to look at a plausible, well-formatted, confident change and feel that something is off. That instinct is built exactly one way: by having been wrong, in production, about something you understood deeply. It is the product of scar tissue.

That’s why the governor role is not a promotion you can hand to someone who never did the work. You can’t judge a system you’ve never had to debug at 3 AM. And it’s why the org-design question underneath all of this — how do people acquire scar tissue when the machine does the work that used to produce it — is the most important unsolved problem in engineering management right now. It doesn’t get solved by a training course. It gets solved by deliberately routing certain work to humans because it builds judgment, and paying for that as an investment rather than tolerating it as inefficiency.

Legible judgment: the practical part

#

Here’s the move that makes all of this survivable in a performance-review culture that still counts merges.

Judgment that stays in your head is invisible, unscalable, and unrewardable. Judgment that becomes an artifact is visible, enforceable, and reusable. So convert it. Relentlessly.

Every time you make a judgment call, ask: what artifact could carry this decision without me in the room? The answer is usually one of these:

Read that table as a career strategy, because that’s what it is. Every row moves something from your memory into the system’s memory. The invisible senior becomes the person whose name is on the constraints that everyone’s agents are running inside. That’s a much stronger position than being the person who read the most diffs.

And it’s measurable, which matters more than it should. “I prevented these four classes of defect from being mergeable” is a reviewable claim. “I have good judgment” is not.

What to do if you’re the senior engineer in this story

#

Six moves, roughly in order of leverage.

1. Stop volunteering as the verification layer. Every hour you spend manually confirming an agent’s output is an hour that should have been spent building the thing that confirms it automatically. Read one diff, then ask what gate would have caught it, and build the gate. This is the single highest-return habit change available to you.
2. Pick one change class and own its verification end to end. Auth, the migration path, notification delivery — whatever carries the most consequence. Define what proof a change in that class must arrive with. Make it non-negotiable. You now have durable, visible, compounding impact.
3. Write your refusals down. All of them. The things you’d veto in a design review, phrased as constraints. Put them in the repo, next to the code they govern. Then promote the top three into enforced gates.
4. Make your review comments generalize. If you’re leaving the same comment twice, you’re doing manual work a rule should do. The third occurrence should be a lint error, not a third comment.
5. Take the architecture work nobody scheduled. Boundaries, contracts, data ownership, blast-radius design. This is the work that agents can’t do and that nobody assigns, which is why it’s where the differentiated value is.
6. Renegotiate how you’re measured, in writing, before review season. Go to your manager with the artifacts: the gates you built, the change classes you defined, the defects that are now structurally impossible. Ask for those to be the basis of evaluation. Managers are not conspiring against you — most of them are measuring throughput because nobody handed them anything better to measure. Hand them something better. I’ll come back to this from the management side later in this series.

Craft didn’t leave. It moved up a level.

#

I want to close on the part that gets lost in the noise.

There’s a real grief in this transition, and pretending otherwise is dishonest. A lot of us got into this because we love the act of making something work — the tight loop of writing, running, fixing, understanding. Handing that loop to a machine costs something real, and “you’ll be more productive” is a thin trade for it.

But look at what’s actually being asked of you now. Decide what should exist. Refuse what shouldn’t. Prove behavior instead of assuming it. Bound the damage when you’re wrong. Stand behind the result in front of a customer.

That’s not a diminished job. That’s the job senior engineers always said they wanted, minus the part where they had to type it all themselves. The craft didn’t disappear when the typing got cheap — it got concentrated into the decisions that were always the hard part and never got enough of the week.

The engineers who lose the next five years won’t be the ones who used AI too much or too little. They’ll be the ones whose value was never written down anywhere a system could see it.

The agent writes the code. The engineer owns the outcome. Owning an outcome is a skill, it’s learnable, and almost nobody is being taught it deliberately.

So here’s my question for you, and I mean it as a genuine audit. Look at your last quarter. How much of your judgment is now sitting in the codebase as an enforced constraint — and how much of it is still living in your head, where it will leave with you and help nobody in the meantime?

I lead AI transformation for a global SaaS platform, which means I spend most of my time on exactly this transition: turning what senior engineers know into constraints, gates, and verification that a fleet of agents runs inside. If you’re doing this work and it isn’t being counted, or you’ve found a better way to make judgment visible, tell me. Find me on X, LinkedIn, or Telegram.