“It’s such a weird time to be a junior software engineer. I’m basically a proxy to Claude Code. My manager tells me what to do, and I tell Claude to do it.”
— Anonymous software engineer, San Francisco
That was an anonymous software engineer at a large San Francisco tech company, speaking to a reporter recently. He described feeling grief, seeing as the skill he had spent years developing had been commoditized to the general public.
The same piece highlights Boris Cherny, the creator of Claude Code, telling Y Combinator that “coding is practically solved” and predicting that the title of software engineer would disappear soon, replaced by something like “builder” or “product manager.”
At this point, engineers are basically being told the house is on fire from every direction, which is a lot to sit with.
The aim of this piece is not to contribute to the doom and gloom, but to argue that the grief, as understandable as it is, is a slight misreading of the fuller picture.
In contrast to what hordes of articles tend to suggest these days, the role of the software engineer is not disappearing into thin air.
Instead, we’re increasingly noticing a move toward something that requires more judgment, architectural thinking, and deliberate oversight.
Let’s break it down.
The Data Behind the Doom, and What It Leaves Out
Before we dig in, it’s worth being honest about what is changing.
One Stanford study found that by July 2025, employment among software developers aged 22–25 had fallen by nearly 20% from its late-2022 peak, with entry-level roles facing clear pressure.
The study’s title frames early-career workers as “canaries in the coal mine,” a phrase rooted in the old mining practice of bringing caged canaries (birds) into underground tunnels to detect toxic gases.
Source: Shareamerica
Because canaries are more sensitive to carbon monoxide than humans, miners would watch them closely. If the bird fell silent or died, it was a warning to get out.
In this case, the signal is that entry-level workers in the most AI-exposed occupations are feeling the pressure first, and the broader workforce may not be far behind.
In a separate report, venture capital firm SignalFire found that since 2019, hiring of new graduates at 15 US tech companies has fallen 50%, as companies lean more heavily on a smaller pool of experienced engineers.
Source: SignalFire
In other words, companies are hiring fewer people to do the work that AI now handles well, like writing repetitive code, generating boilerplate, and scaffolding standard features.
The overall picture for early-career software engineers, at least on the surface, looks pretty grim.
Yet zoom out, and the US Bureau of Labor Statistics projects software developer employment to grow 17.9% between 2023 and 2033, well above the average across all occupations.
In other words, companies are hiring fewer juniors, but in the same vein, they are using AI to extend what experienced engineers can do. There’s a demand for those who can architect systems, evaluate AI output, and make judgment calls that agents cannot.
Even the Stanford study explains how employment declines are not spread evenly across all AI-related work. They are concentrated in roles where AI automates tasks and replaces bounded execution work, not in roles where engineers use it to extend their own capabilities and output.
Execution work, like writing code, is just one part. It’s roughly the same way typing is a part of journalism, but we don’t conclude that the journalist’s value ends at typing.
The other part of software engineering revolves around judgment, context, accountability, and the decisions about what to build and what to push back on.
From Writing Code to Directing It
The vibe coding vs agentic engineering discourse lends more credence to what we are arguing here.
In early 2025, Andrej Karpathy, co-founder of OpenAI, coined the term “vibe coding” to describe a style of AI-assisted development where developers handed everything to a language model and accepted the output without much scrutiny.
Fast forward one year later, Karpathy declared vibe coding passé and introduced a different term to describe what professional development with AI actually looks like: agentic engineering.
In his words:
- ‘Agentic’ because the new default is that you are not writing the code directly 99% of the time, but orchestrating agents who do and acting as oversight.
- ‘Engineering’ to emphasize that there is an art and science and expertise to it.
— Andrej Karpathy
The point of this is, vibe coding produces fast output of uncertain quality. Whereas agentic engineering produces reliable output because a skilled engineer is directing it, setting the constraints, reviewing the results, and taking responsibility for what ships.
This is the context in which the question of whether engineers still matter has to be answered. The answer is yes, emphatically, but the role is changing in ways that require deliberate adaptation.
What Research Says About Human Judgment in AI-Assisted Development
If the Karpathy framing makes the argument conceptually, the HULA research makes it empirically.
HULA, which stands for Human-in-the-Loop LLM-based Agents, is a framework that describes how software engineers guide AI agents through the development process, from planning to code generation.
The framework was deployed into Atlassian’s Jira workflow, where engineers used it to resolve real work items, staying involved at every stage from reviewing coding plans to signing off on generated code before it moved to a pull request.
Across 663 real work items, HULA generated coding plans for 79% of them, with 82% of those plans approved by engineers. It generated code for 87% of approved plans, with 25% going all the way to a pull request.
Source: Human-In-the-Loop Software Development Agents
The key findings were:
- On structured benchmark data (with detailed descriptions), performance was significantly higher
- On real Jira issues (shorter, less detailed), performance dropped
- When engineers reviewed and enriched the plan or context, outcomes improved
What this shows is that the agent’s effectiveness depends heavily on the quality of the input it receives. Not in a simple garbage-in, garbage-out sense, but in a more fundamental way.
The engineer’s ability to understand the problem well enough to describe it precisely, anticipate constraints, and provide the right context at the right stage plays a major role in determining whether the output is useful.
“Good AI output comes from good context, not clever wording. You can’t ‘chat your way’ to production-grade software.”
— McKinsey, The AI Revolution in Software Development
That makes problem framing and evaluation increasingly important skills in AI-assisted workflows, especially as more of the execution work is handled by the system.
The Skills Worth Building Now
As execution becomes more automated, the skills rising in value are the ones around judgment, context, and oversight.
Specification and Problem Decomposition
Before an agent can do anything useful, someone has to define precisely what success looks like. Engineers who can break a complex feature into well-scoped, verifiable subtasks, anticipate the constraints upfront, and structure work so an agent can execute it reliably are getting substantially better results.
Systems-Level Review
AI-generated code is usually syntactically correct and locally sensible, which is why it passes an initial read so easily. However, problems emerge when you see how it introduces inconsistencies with the rest of the architecture even though the code works. Catching these issues requires understanding the entire system, not just reviewing the individual function. That kind of understanding comes from working with a system over time.
Knowing When to Trust the Output and When Not to
AI models are confident even when they are wrong, and those errors are not always obvious on the surface. An engineer needs to develop an intuition for where these tools fail, which types of problems they handle well, and which ones they tend to get wrong.
Cross-Functional Judgment
As more of the execution work gets automated, those who can move between technical and business decisions become more valuable. These are the engineers who can explain architectural trade-offs to non-technical people, translate what the business actually needs into technical constraints, and make decisions that serve both sides.
The Bottom Line
While agentic development is introducing substantial efficiency gains to workflows, it has not changed the fact that software engineering requires genuine expertise.
Because when engineers stop thinking critically about what they are building and begin to accept whatever an agent produces, the result is what many now call “AI slop.” This is code that compiles and may even pass basic tests, but gradually degrades system quality over time.
The value now sits in shaping the problem, providing the right context, evaluating outputs at a systems level, and catching what the agent missed before it reaches production.
This is why the question of whether engineers still matter misses the point. The better question is what kind of engineering matters now.
And the answer is increasingly clear: engineers who can think in systems, communicate intent precisely, and apply judgment at every stage of the process.
