Senior Engineer Value in the AI Era: Why They Cost More Now

When people tell me "AI is going to replace developers," I think about one specific bug.

Claude wrote a pagination function. Confidently, quickly, with zero warnings. It passed review — it looked reasonable. Seven days in production. Then we found the edge case: at exact multiples, the cursor shifted by one position, and the catalog silently started skipping products. No errors in the logs. No alerts. Just missing items.

Claude didn't mess up. Nobody explained what kind of system this was. That's the actual problem.

What's happening: companies cut teams and don't get the ROI they expected

Early 2026. Companies are buying AI tools and shrinking engineering teams. The logic seems obvious: if Claude writes code, why pay a developer $3,000/month?

On Hacker News and LinkedIn, it's treated as a settled question. But counter-stories are showing up. Studios that cut to the bone, then six months later come back with "there are bugs in production that nobody understands" and "the new contractor can't figure out the codebase."

The ROI didn't work out — not because AI's a bad tool. Because AI multiplies what's already in the team. Remove the people with systems thinking and you multiply the chaos.

What changed in my work

I run several active projects. Since mid-2025, roughly 65% of the code I produce goes through Claude Code. That sounds like a lot. In practice it means: I write the spec, Claude writes the implementation, I verify the contract.

What I hand off without hesitation:

test coverage for existing logic
refactoring with explicit input/output contracts
boilerplate: CRUD controllers, schema migrations, config files

What I don't hand off:

architecture of new subsystems
caching strategy decisions in Bitrix under load
anything involving the 1C sync (too many implicit invariants)

I wrote about this principle separately: Claude writes tests. I don't let it choose architecture.

Claude doesn't know what it doesn't know. It won't ask "wait, are you running one instance or multiple?" It'll just assume.

The production bug: seven days

That pagination case wasn't the only one. Over six months of active Claude Code use, I counted three production incidents tied to AI-generated code.

All three had the same shape: the code looked correct. It passed review. It matched the task as written. But in each case there was a system detail I hadn't put in the spec — because I assumed it was obvious.

AI doesn't know your obvious details. The senior engineer's job is to know which details need to be made explicit.

That's a skill. And it's getting scarce. I wrote a full breakdown of the bug that lived in production for a week if you want the specifics.

AI multiplies judgment — so judgment becomes the bottleneck

The pattern I keep seeing: better tools make a vague spec more expensive, not less.

A junior could implement a fuzzy spec over a week of back-and-forth. Now Claude implements the same fuzzy spec in an hour — wrong. Then someone spends three days figuring out why.

What changed is the requirement to formalize context. Not "add search," but "add fuzzy search on the NAME field with fuzziness AUTO and prefix_length 2, Cyrillic through the Russian analyzer." That used to be a nice-to-have. Now, without it, Claude produces plausible-sounding garbage.

Even more important: knowing the system's invariants. What can't change, even if it's not written down anywhere. Claude won't ask. It'll assume.

This isn't a "10x developer" story about typing speed. It's about knowing the system well enough to ask the right question. And recognizing that AI multiplies your habits, not just your velocity.

The market paradox: junior cheaper, senior scarce

Here's what's strange about 2026: a junior developer has genuinely gotten cheaper per task. Claude handles a large chunk of the mechanical work.

A senior engineer with architectural judgment hasn't. They've gotten rare.

People with that kind of systems thinking were never common to begin with. Companies are noticing now — because without them, AI tools produce expensive technical debt at speed.

I've seen this on projects that came to me after "team optimization." The codebase is growing. Tests exist. Documentation was generated. But nobody can explain why the cache drops under specific load conditions. And nobody can track down why the 1C sync breaks once a week on the same day.

AI wrote all of this. It didn't anticipate any of these problems.

What I'm looking for when hiring now

I used to filter on speed. Can someone write a working function in a reasonable amount of time?

Now the first question is different. Can someone explain why they made a specific architectural decision? Not "because that's what the docs say," but "because our system has this invariant, and it forces this choice."

If someone can't answer that about code they didn't write — they won't be able to brief AI effectively. They'll keep getting plausible-but-wrong code.

I don't start with a technical assignment anymore. Three questions that've become permanent:

First. "Tell me about a time when code was technically correct for the spec but wrong for the system." If someone can't give a real example from their own work — they either haven't worked with production systems or they don't reflect on what goes wrong.

Second. "How do you transfer implicit system constraints to a new team member?" "We have documentation" doesn't count.

Third. "What do you never delegate to AI, and why?" Both "I delegate everything" and "I delegate nothing" are red flags.

What this means if you're hiring

If you're building an engineering team and thinking "we have Claude, why do we need a senior" — that's an honest question.

Claude writes code well when you know how to describe what you want. It works poorly with what you consider obvious and don't bother writing down. The more complex the system, the more of those unspoken "obvious" details there are.

A senior engineer isn't there to write code instead of Claude. They're there to know what to tell Claude — and to catch the moment when Claude silently made an assumption.

I already see projects where this was answered wrong. Give it six months.