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 spotted that a generated retry would have hammered a partner API, and wrote the rate-limit constraint into the repo so nobody — human or agent — would have to find it the hard way again. 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 easy to see. Judgment is invisible. Every performance system we have was built to measure output — and output is exactly the thing that stopped being scarce.

That gap is the biggest career risk in engineering right now, and it is what 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 fence a system so 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 in the middle of it — what the role actually becomes, and how to come through the change with your value still visible.

The argument seniors keep losing

#

Here is the conversation happening in engineering orgs everywhere, usually in a slightly sharp 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 a claim nobody can disprove in a system that counts merges, and because the answer is so simple: then review it. That sounds reasonable right up until you notice it turns the senior engineer into a permanent verification machine. 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 have watched this play out up close, and the diagnosis is uncomfortable. The senior engineer’s objection is right, and their position is wrong. Defending code quality by offering 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 on purpose. A governor, in the mechanical sense, is the part that limits how a system behaves. It does not produce the power. It sets the limits the power has to work inside. That is the job.

Not manager. Not reviewer. Not prompt engineer. The engineer’s work moves from making the change to defining and enforcing which changes are acceptable, 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 list the tradeoffs. What they cannot do is hold your business, your organization, your five-year costs, and your partner contracts in mind at once and say this one, because of that.

This was always the senior job. It just came bundled with the implementation, which made it look like a bonus instead of the product.

2. Decide what must not exist

#

This is the half nobody values enough, and it is where I would spend most of a senior engineer’s week.

An agent will never refuse to build something because it is a bad idea. It has nothing at stake. It doesn’t carry the pager, sit in the postmortem, or explain the incident to a customer. Saying no is a judgment that needs consequences, and consequences attach to humans.

So the governor’s job is to write refusals down and make them stick: 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 stops a whole family of future systems from ever existing. Written down, it is leverage. Left in your head, it is 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 — deliver the same thing twice, get one effect — 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 turns up already 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 is the sentence that rearranges a career. When execution is cheap, the person who designs the verifier affects system quality far more than the person who writes the code — by a huge margin, and permanently instead of 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 can be undone. What needs a human between the work and its effect. What can never run without a named person saying yes.

Most organizations set these limits by accident, inherit vendor defaults, and call it policy. Setting them on purpose, per workflow, with rules for moving up and down, is engineering work — and it is the difference between an incident and a quiet Tuesday. 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 is the part you cannot hand to anything else.

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 is not a nice moral touch — it is the load-bearing part of the whole operating model. An organization where nobody owns agent output has no feedback loop, and a system without a feedback loop gets worse until it fails in public.

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 really 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 skill that fades is trained suspicion — the ability to look at a neat, confident, believable change and feel that something is off. You build that instinct exactly one way: by being wrong, in production, about something you understood deeply. It is made 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 is why the org-design question underneath all of this — how do people get scar tissue when the machine does the work that used to produce it — is the most important unsolved problem in engineering management right now. A training course will not solve it. You solve it by sending certain work to humans on purpose because it builds judgment, and paying for that as an investment instead of putting up with it as waste.

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, doesn’t scale, and never gets rewarded. Judgment that becomes an artifact is visible, enforceable, and reusable. So convert it, every time.

Every time you make a judgment call, ask one question: 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 is what it is. Every row moves something out of your memory and into the system’s memory. The invisible senior becomes the person whose name is on the constraints that everyone’s agents run inside. That is a far stronger position than being the person who read the most diffs.

And you can measure it, which matters more than it should. “I made these four kinds of defect impossible to merge” is a claim someone can check. “I have good judgment” is not.

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

#

Six moves, roughly in order of how much they pay off.

1. Stop volunteering as the verification layer. Every hour you spend checking an agent’s output by hand is an hour you should have spent building the thing that checks it automatically. Read one diff, ask what gate would have caught it, then build the gate. This is the single biggest 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 has to arrive with. Make it non-negotiable. Now your impact lasts, shows, and builds on itself.
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. Turn your review comments into rules. If you are leaving the same comment twice, you are doing by hand what a rule should do. The third time 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 agents can’t do and nobody assigns, which is exactly why it is where your value stands out.
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 plotting against you. Most of them measure throughput because nobody gave them anything better to measure. Give 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 is real grief in this change, 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. Limit the damage when you are wrong. Stand behind the result in front of a customer.

That is not a smaller job. That is the job senior engineers always said they wanted, without the part where they had to type it all themselves. The craft didn’t disappear when the typing got cheap. It moved 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 is my question for you, and I mean it as a real 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.