AI Doesn't Define Seniority. Engineering Judgment Does.

This one has been going around lately:

“You’re not a senior software engineer in 2026 unless you can rebuild Claude Code (the most basic of agents).”

— Geoffrey Huntley, if your team is too busy doing their ‘normal job’ to experiment with AI, you’re preparing them to be replaced, 2026/10/09

Let me be clear about where I stand: the team I lead is building agent infrastructure right now, and I use AI coding tools every day. This is not AI skepticism, and it is not an attempt to dismiss what AI is doing to software engineering. If anything, I think AI is changing how engineers work in a big way. What I disagree with is this: why should being able to rebuild Claude Code become the bar for whether someone is a senior software engineer?

Huntley says so himself in the post:

“It’s not that hard to build a coding agent. 300 lines of code running in a loop with LLM tokens.”

If a basic coding agent takes a few hundred lines to implement, is this measuring engineering seniority, or is it measuring how familiar someone is with AI tools?

Those are not the same thing. If everyone starts preparing for how to implement a 300-line coding agent, that bar turns into the next LeetCode soon enough. We would have swapped the interview question without solving the actual problem.

AI literacy, AI proficiency, and engineering seniority are three different things

A lot of the current discussion conflates three capabilities.

AI literacy: whether you understand context windows, tokenization, inference, tool calling, and the basic limits of an LLM.

AI proficiency: whether you can use tools like Claude Code or Codex effectively to get work done in a real codebase.

Engineering seniority: whether you can apply domain knowledge to make mature engineering judgments under complex, incomplete conditions, understand the trade-offs, and own the outcome.

These three are related, but they are not equivalent.

A junior engineer can be very good at Claude Code and produce a large volume of high-quality code quickly.

A senior engineer may not know the details of tokenization, yet be able to spot architectural risk, compatibility problems, and future maintenance cost early in a system design.

We cannot decide the former is more senior just because they know the AI tooling better. And equally, we cannot assume every judgment the latter makes is better just because they have a dozen years of experience. Seniority is not tenure, and it is not tool fluency. It is engineering judgment that has been tested against real problems.

AI made output cheap. It did not make verification cheap.

AI changed one important economic condition in software engineering:

The cost of code generation is falling fast.

A prototype that used to take days can now be produced in a few hours. AI can generate a lot of code, write pretty much perfect test cases, refactor modules, and even help with complex changes that span files or span features. But one thing has not gotten cheaper at the same rate:

Judging whether that output actually meets the system’s requirements.

The verification here is not just whether the code compiles or whether the unit tests pass. It is:

• Does this design fit the existing system’s architecture and design patterns?
• Does it introduce new security or reliability risks?
• Does it break a compatibility contract that was only ever implicit?
• Does it still hold under real production conditions?
• Three months from now, does this decision become new technical debt?

AI can help us speed up part of the verification work, but it does not automatically know every implicit constraint in every system. And as the volume of generated code grows, the scope and complexity of verification can grow with it. Which is why I think domain knowledge has not lost value in the AI era — it matters more.

Domain knowledge gives you more than knowledge. It gives you judgment.

I would split the value domain knowledge brings into three parts.

Taste — knowing what a good design looks like

When several options all look workable, an engineer can judge which one fits better, based on the system’s constraints, where it is heading, and what it will cost to maintain.

Test — knowing what to verify

The engineer knows where the system is likely to go wrong, and knows which normal-looking signals do not actually prove the thing works.

Priority — knowing what is worth doing

Personally I think this may be the most important one, and the most underrated: the ability to make trade-offs.

AI can get you to a finished feature faster. But if the feature was not worth building in the first place, finishing it faster does not mean more value was created.

Test is the one worth going into. I will use an AOSP example.

A SELinux rule that compiles and runs, and still does not do what you wanted

Say the requirement is simple: run an Android app in its own SELinux domain instead of an existing shared one. AI tools can probably add a rule to seapp_contexts for this very quickly:

user=_app isPrivApp=true name=com.example.myapp domain=myapp_app type=privapp_data_file levelFrom=user

The policy looks reasonable: it names the app, and it names the SELinux domain you want. The verification results that follow might be:

Every signal looks fine. But the question is: is the app actually running in the myapp_app domain? Not necessarily.

In Android’s seapp_contexts selection logic, rules are not prioritized purely by their order in the file or by how precise the package name is. For the selectors involved in this case, seinfo can outrank name. If the app is platform-signed and picks up seinfo=platform through mac_permissions.xml, and a rule like this exists in the system:

user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user

then, with the relevant conditions met, the app may match that rule in preference to the one you added with the package name in it. The actual result still has to be confirmed against the Android version, the complete policy, and the selector conditions. If the app ends up in platform_app, and that domain already permits the operations it needs, then:

• The app runs fine.
• SELinux does not necessarily produce a denial.
• The myapp_app rule you added may never be used at all.

At that point a successful compile, a working app, and no AVC denial prove nothing about whether your requirement was met. You need to check the process’s actual security context directly:

adb shell ps -AZ

and confirm whether the relevant process is really running in the expected domain. There is one more easy thing to miss: an Android app can declare additional processes, for example:

android:process=":daemon"

which makes the actual process name differ from the main app process. For a rule that relies on the name= selector, you have to confirm those processes match correctly too. The point of this example is not that AI will necessarily produce a wrong SELinux rule. The real point is that the verification you chose (what to verify) may be incapable of verifying that the policy was actually brought into effect.

An engineer who knows AOSP and SELinux knows to confirm the actual process domain, not just watch the compile, the boot, and the AVC logs. That judgment comes from domain knowledge, not from understanding tokenization.

The same problem shows up in agent infrastructure

Switching to a field I spend more time in now.

An agent runtime I worked on had an authorization layer, responsible for confirming whether an agent had permission to call a given tool. The system had a complete authorization implementation and unit tests to go with it. Then one code change accidentally left the main execution path no longer calling authorization at all. What that looked like:

• The authorization code was still there.
• The authorization unit tests all passed.
• The agent could still call tools normally.
• But the real enforcement was gone from the execution path.

That is the same failure pattern as the SELinux case above.

The signal you are checking does not cover the property you think it covers.

All tests passing does not mean the security enforcement is actually wired into the real execution path — quite possibly it was simply never covered. No AVC denial does not mean the SELinux rule took effect.

This is not a class of problem you solve by generating more code. You have to understand the system’s trust boundary, its control flow, and the security invariant that actually needs verifying. For agent infrastructure, that can mean writing negative tests to confirm a request really is refused when there is no authorization — even deliberately removing the enforcement to check whether the tests notice.

That is what I mean by engineering judgment.

AI is the multiplier, domain knowledge is the multiplicand

AI is the multiplier. Domain knowledge is what it multiplies.

As I said on a podcast: AI can amplify an engineer’s output, but the quality of what comes out the other side still depends on whether the engineer can understand the problem, judge the direction, and verify the result. A senior engineer with deep domain knowledge, given AI, may not just write faster — they can:

• explore different architectural options faster
• identify wrong assumptions earlier
• verify technical risk more efficiently
• shift time from code generation to engineering decisions

That said, I do not think this means a senior engineer is more valuable than a junior engineer in every situation. There is a factor here that gets overlooked a lot:

What does your team actually need right now?

What a team needs depends on the stage it is in

Say you have two engineers.

The first is a junior engineer who is very good with Claude Code and can finish in a day what might take someone else a week.

The second is a senior engineer with deep domain knowledge and mature architecture judgment, but only ordinary fluency with AI tools.

Who is more valuable to the team?

The answer is: it depends.

When what the team needs is execution

If the business direction is already clear, the architecture is decided, the requirements are well understood, and the work is already broken down into clearly executable tasks.

Then what the team needs most right now is probably execution speed.

At that stage, a junior engineer who uses AI tools effectively and delivers high-quality work quickly may bring more marginal value than the senior engineer described above. Because the bottleneck right now is not judging the direction, it is the speed of execution. With the caveat, of course, that delivery quality can actually be verified, and the system has appropriate review and safety nets.

When the team is at 0-to-1

But if it is a startup company or a startup project, the product direction is still vague, the architecture has not taken shape, and it is not even certain whether the idea is worth putting resources into — then execution speed may not be the most important problem. What matters is:

• Is the problem in front of us the right problem?
• Is this idea worth investing in?
• Which technical decisions will constrain future options?
• Should we build, buy, or not do this at all?
• Which assumptions have to be verified first, to avoid wasting the whole team’s time?

In that environment, a senior engineer with mature engineering judgment tends to bring more value. Because a wrong direction executed faster is just a faster way to waste resources.

The real world is usually not a binary choice

Most engineering organizations do not stay in the same stage forever.

Some teams are exploring direction, some are establishing architecture, some are delivering at scale, and some are maintaining a mature system. So the real engineering leadership question is not “who is stronger, junior + AI or senior + AI.” It is:

What is the right mix of execution capacity and engineering judgment for the problems we’re solving?

A good engineering organization needs both.

AI changed the economics of execution, and it may change the mix of people a team hires. But that does not mean engineering judgment stopped mattering, and it certainly does not mean we should redefine seniority as “can you rebuild Claude Code.”

Why “understanding AI internals” is not a universal bar either

Take Git as the analogy —

A senior engineer should know how to use Git, and should understand rebase, merge, conflict resolution, and the risks of getting those wrong. But we do not require every senior engineer to be able to reimplement Git.

AI tools are the same. If you are just using Claude Code to build a product, you should know that:

• when there is too much context, or the context is poor quality, the model can miss important information
• AI-generated code can pass the tests and still not meet the actual requirement
• automatic context compaction can lose a critical design constraint
• an agent running tools can produce side effects you did not expect

You need to know these failure modes and be able to deal with them effectively. But you do not necessarily need to go deep on tokenizer implementation, KV cache management, or prefill/decode optimization.

If your job is designing an agent runtime, LLM serving infrastructure, or optimizing inference cost, then of course it is different — that knowledge directly affects your architecture decisions. And if you are simply interested in this and want to understand more, even when it has nothing to do with the work in front of you, I would encourage you to go deep on it.

The depth of knowledge required should be determined by the problems you are responsible for solving.

A technology being hot right now is not a reason to make it a shared bar for all senior software engineers.

What Huntley gets right

I do not disagree with Huntley entirely.

First, AI fluency is becoming an increasingly important capability for software engineers. An engineer who refuses to understand or use AI tools at all is, over the long run, quite likely making themselves less competitive. Second, he stresses that senior engineers should have taste and should be able to pass engineering experience on to the next generation, and I agree with that too. And if you are building AI infrastructure, then understanding the agent loop, tool calling, context management, and the underlying mechanisms really is a capability the job requires. I think where we actually part ways is this:

These are necessary conditions for certain engineering jobs, but they should not automatically become the definition of every senior engineer.

AI proficiency matters.

AI internals matter too, in the right domain.

But engineering seniority should still be measured by an engineer’s judgment, their technical impact, and their ability to solve complex problems.

So back to interviews — how do we verify a senior engineer’s ability?

Rather than asking a candidate to implement a coding agent from scratch, I would personally much rather see how they handle a system that looks like it already succeeded but may have a hidden problem. For example:

This AI-generated code passes all the unit tests, lint, and type checking. What else would you verify? Why?

Or back to the SELinux case above:

The policy compiles, the device boots fine, the app works, and there is no AVC denial. How do you confirm the app is really running in the expected SELinux domain?

I am not only interested in whether the candidate can find the answer. I want to understand how they think:

Can they identify the blind spot in the verification? Can they form a reasonable hypothesis? Do they know what evidence to collect? When new evidence shows up, are they willing to revise their own judgment?

That is closer to what I expect from senior engineering ability than reciting some framework’s API or rebuilding a simple coding agent. Although any fixed question can be prepared for. So an interview that actually works should put the candidate in front of new constraints and new evidence, and watch how they adjust their judgment — rather than only checking for the standard answer.

Tools change. Engineering judgment is the long-term asset.

Someone might say domain knowledge expires too, and that pushback is fair; a technical approach that worked ten years ago may no longer apply today. AI is changing software engineering’s methods and best practices as well. But I think two things need separating:

Implementation knowledge expires. The ability to understand constraints, trade-offs, and failure modes tends to carry further.

You learn how to write a seapp_contexts rule today, and in the future you may run into an entirely different policy mechanism. But what you learned — that a setting existing does not mean it is actually in effect at runtime — still applies to other systems.

You know some agent framework today, and next year it may be replaced by a new one. But your understanding of authorization boundaries, failure recovery, state consistency, and observability still shapes how you design the next system. Those also need continuous updating; past experience alone is not enough.

AI will let engineers produce faster.

AI will also give good engineers more leverage.

But when everyone can quickly produce code that looks reasonable, the difference is no longer only who writes faster. It is who can judge what is worth doing, which design is better, which risks have not been verified yet, and when to stop investing.

AI Doesn’t Define Seniority. Engineering Judgment Does.

And AI makes that judgment more valuable, not less.