The Senior Developer's New Job Is Saying No

AI made code cheap to generate. Senior developers now earn their keep by cutting surface area, protecting architecture, and deciding what should not exist.

The junior developer on your team shipped three new services last week. With AI. All of them start, answer requests, and have tests. None of them should exist.

That used to be a rarer problem. For a long time, software teams spent most of their energy on the question, “Can we build it?” The answer depended on time, headcount, expertise, patience, and how much pain the codebase could absorb before it started pushing back. Those limits were annoying, but they were also useful. They forced prioritization.

That old question is getting cheaper by the month. In Stop Measuring AI by How Much You Use It, I made the case that AI activity is easy to measure and easy to misunderstand. Token burn, seat activation, prompt volume, and all the rest can make a dashboard look busy without proving that anything improved. Same problem here. AI does not remove the need for judgment. It removes some of the friction that used to hide the need for judgment.

So the senior job changes. Maybe not in title or salary band, but in where the real work sits. We still design, debug, mentor, and clean up the weird edges of production systems. The scarce skill is shifting. The harder question is less often “how do we build this?” and more often “why are we building this at all, and who is going to carry it after the demo?”

When “senior” meant friction

Experience has always been a proxy for judgment. We like to pretend seniority is about knowing more frameworks or having stronger opinions about architecture diagrams, but the useful part was usually much simpler. Senior developers had a better sense for which ideas were worth turning into code.

Older delivery systems had built-in brakes. Sprint capacity, story points, quarterly planning, dependency reviews, architecture boards, “we do not have bandwidth for that this quarter.” Teams complained about those things, often correctly. Plenty of them were theater. But even the theater imposed a cost on new work, and cost changes behavior.

For all the complaining, that friction did two useful things.

First, it made stakeholders explain themselves. If an idea had to survive a planning meeting, somebody usually had to define the actual problem, the affected users, and the trade-off.

Second, it made developers ask whether a proposed change was worth the maintenance bill. You could not casually turn every half-formed suggestion into a service, a background job, a dashboard, or an integration because building any one of those things took enough time to trigger an argument.

AI strips out a lot of that delay. I do not mean only autocomplete. I mean the whole stack of “good enough to merge” generation: code, tests, config, docs, YAML, client wrappers, even the cheerful little README that explains the system nobody asked for. The proposal no longer has to survive scarcity. It only has to survive enthusiasm.

That is why senior developers become filters. Not because we enjoy blocking people, and not because every fast change is reckless. The point is that the old brakes are weaker, and the replacement brake is judgment.

The backlog is now a decision queue

When implementation drops from weeks to an afternoon, every idea starts to look cheap. Stakeholders notice that in about five minutes.

“Could we just have AI spin up a small service for that?”

“Could we wrap this system in a tool so the agent can call it?”

“Could we generate a migration for the old module and clean it up later?”

Of course we could. That is the easy part now.

The harder part is that every one of those “just” decisions creates a maintenance obligation. A tiny service still needs ownership, telemetry, security updates, deployment wiring, on-call understanding, and future changes by somebody who did not generate it. A generated integration is still an integration. A one-off MCP server is still one more thing your team has to remember exists when credentials rotate or a downstream contract changes.

This is where old ideas like YAGNI get interesting again. YAGNI used to be a warning against speculative abstraction inside a codebase. In an AI-heavy workflow, it also needs to become a warning against speculative systems. Martin Fowler makes the small-scale point nicely: lots of tiny YAGNI decisions reduce complexity. The units are bigger now. We are not only overbuilding methods and abstractions. We are overbuilding services, agents, wrappers, and modernization branches.

The enterprise Java world is especially exposed to this. Modernization already creates strong pressure to decompose, migrate, wrap, and replace. Add AI to that, and the volume goes up fast. Konveyor AI shows AI-assisted migration from Java EE to Quarkus. IBM Bob promises validated upgrades in days instead of months. I do not think any of that is fake. The tools are real, and some of them are genuinely useful. The risk is not that the migration output fails to compile. The risk is that teams can now manufacture more architectural surface area than they can sensibly own.

That changes the shape of the backlog. It is no longer just a queue of work. It is a queue of decisions about what not to build.

What “no” is protecting

For me, “no” protects three things.

First, it protects maintenance capacity. McKinsey’s tech debt research already had CIOs estimating debt at 20 to 40 percent of estate value before this generation of AI tooling showed up. AI does not erase that bill. It just makes it easier to put more on the card.

Second, it protects team cognition. More systems do not only mean more code. They mean more names, more data flows, more half-documented assumptions, and more places where a change can surprise you. Every extra service steals a little understanding from the rest of the system. Eventually nobody holds the whole shape in their head, which means every change gets slower even while generation gets faster.

Third, it protects architecture. AI-generated code usually fits locally, which is exactly why it is seductive. The class compiles. The endpoint works. The tests pass. Local fit is cheap. Global fit is the job.

We learned this already with microservices. Teams split monoliths into distributed monoliths because the boundary cost was hidden until production collected the bill. We are volunteering to relearn the same lesson at the agent and tool layer. Wrap every internal system in a tool. Generate an agent for each workflow. Add another broker. Add another memory store. Add another approval loop. Soon the topology diagram looks modern and the operating model looks tired.

Conway’s Law still wins here. If your organization is confused, the generated architecture will mirror that confusion. AI does not clean up the org chart. It renders it faster.

This is also where the current vibe coding discourse gets interesting. I do not even dislike the term. It is at least honest. For small experiments, internal tools, and personal prototypes, vibes are fine. Production systems still need adults in the room. Somebody eventually has to understand the failure modes, and “the model wrote it” is not an operational plan.

Four tests before you say yes

If senior developers are now filters, the obvious next question is what the filter looks like. I do not think this needs a giant framework, laminated card, or maturity model. It needs a few blunt questions asked early enough to matter.

1. The Carry Test

Would we still want this if the AI that generated it disappeared tomorrow and we had to own it by hand?

That question clears out a surprising amount of nonsense. If the answer is no, we are not approving a system. We are approving a temporary hallucination with hosting.

2. The Problem Clarity Test

Can someone state the problem this solves in one sentence without mentioning the technology?

If the explanation starts with the agent, the model, the framework, the microservice, or the protocol, we probably do not have a problem statement yet. We have a build impulse wearing technical clothes.

3. The Duplication Test

Does this already exist somewhere in the estate, and is our version meaningfully different?

AI makes duplicate effort feel cheap because the local cost is low. The estate-level cost is still real. A second service with 85% overlap is not faster delivery. It is a forked maintenance burden with a nicer origin story.

4. The Consequence Test

What is the blast radius if this is wrong?

Wrong does not only mean “throws an exception.” It also means bad routing, bad approvals, wrong data, false confidence, and a migration that preserves behavior nobody wanted to preserve. In enterprise systems, wrong software often works beautifully right up until it reaches the business rule that mattered.

Those four tests do not replace judgment. They force it into the room earlier, which is where it belongs.

Metrics still miss the real question

This is also why I am wary of using AI-era throughput as a proxy for value.

I still like the classic DORA four keys because they say something real about delivery performance: deployment frequency, lead time, change failure rate, and time to restore service. Keep them. They are still better than vanity metrics.

But notice what they do not measure. None of them asks whether the thing should have been built. They measure how quickly and safely software moves, which is useful. It is still not the same as product judgment.

Once raw output becomes the celebrated number, Goodhart’s Law walks in right on schedule. If teams get rewarded for how much AI-assisted work they can push through the pipe, they will produce more work for the pipe. Some of it will be useful. Some of it will be architecture confetti. The dashboard will not know the difference, and the repo definitely will.

That gap between “can ship” and “should exist” is where senior judgment earns its keep.

No is design

I do not think saying no is a failure of imagination. For me, it is one of the last places real design still shows its teeth.

The best systems are defined as much by what they exclude as by what they contain. Good architecture is not a pile of clever yeses. It is a sequence of selective refusals: no, this does not need its own service; no, this workflow does not need an agent; no, we are not wrapping a stable internal API in three new layers because the demo looked smooth; no, we are not modernizing this part yet because we still do not know whether it should survive the business process around it.

AI will always offer to help you say yes. That is part of its charm. Give it a prompt and it will produce momentum. The human job is to decide whether that momentum deserves a future or just a branch nobody should merge.

The developers who matter most over the next five years will not be the fastest builders. They will be the best deciders. They will know when speed helps, when reuse is fake, when modernization is actually expansion, and when a clean-looking diff is still a bad system.

No is a skill. Senior developers should practice it on purpose. Even more so now.