AI Can Write the Code. Engineering Is Becoming the Bigger Question.

The hiring headlines need a closer reading

You can find a headline to support almost any position on software careers right now.

Engineers are finished. Engineers are more valuable than ever. Junior hiring is collapsing. AI is creating new demand.

Some of these statements can describe different parts of the same market.

SignalFire’s 2026 talent report says software engineers account for 55% of hiring in its tracked market, up from 46% in 2019. The same report describes a smaller overall hiring market and sharply reduced entry-level hiring.

A bigger share of a smaller hiring market does not automatically mean more engineering jobs. And demand for experienced engineers can coexist with fewer opportunities for people trying to become experienced.

That distinction matters.

I don’t read those numbers as proof that AI has either destroyed or saved the profession. They describe a market that needs more careful analysis than either conclusion allows.

The question I take from them is this: what work are companies willing to hire engineers to own, and how are engineers supposed to develop the ability to own it?

SignalFire’s 2026 report

Code output is an incomplete measure of engineering

Suppose an agent produces a feature in twenty minutes.

That is useful. It may save meaningful time.

Now someone needs to decide whether the feature belongs in the system, whether it follows the right assumptions, and whether the added complexity is justified.

Someone needs to inspect the failure paths. Someone needs to think about permissions, data migrations, compatibility, and deployment.

You can involve AI in all of that. But generating an answer and establishing that the answer is appropriate remain separate steps.

Microsoft’s published account of using a coding agent in dotnet/runtime is useful here. The work involved explicit requests from maintainers, review, and human intervention. It describes a working engineering process around an agent, with results specific to that repository and its tasks.

That is a more useful picture than a percentage of code written.

It gives us something to examine: where the agent helped, where people intervened, and what the team needed to make the contribution usable.

Microsoft’s engineering account

Faster generation can move the bottleneck

Here’s a possibility engineering organizations need to take seriously.

If a team can produce changes faster than it can evaluate them, the queue moves into review.

The immediate result may look productive. More pull requests. More completed tickets. More features awaiting approval.

But the people reviewing those changes still need to reconstruct intent, check assumptions, and understand how the pieces interact.

Review can benefit from AI too. The question is whether the whole process improves.

Are changes reaching production sooner? Are they causing more rework? Are incidents increasing? Can the team still explain what it operates?

I would rather see those answers than a chart showing how many lines an agent generated.

Otherwise, we risk rewarding the easiest part to count and leaving the expensive work invisible.

The learning problem deserves its own conversation

There is another issue underneath this: many tasks we can automate are also tasks people learn from.

A small bug fix teaches someone to follow an execution path. A modest feature introduces them to the data model. A difficult review exposes an assumption they didn’t know they were making.

The value includes what the engineer understands afterward.

That doesn’t mean every repetitive task should be preserved as a training exercise. It means we should notice when we remove the exercise and assume the learning will happen anyway.

Anthropic published a randomized study involving 52 developers learning an unfamiliar Python library. Participants using AI assistance averaged 50% on a subsequent assessment, compared with 67% for the group coding without it. The task-speed difference was not statistically significant.

That is a narrow experiment. It does not establish what years of AI-assisted engineering do to someone’s ability.

But it gives us a reason to examine the tradeoff. The researchers also observed differences in how participants used the assistant: asking conceptual questions and working to understand the output were associated with better retention than simply delegating the work.

My takeaway is that learning needs to be an explicit part of the workflow.

Finishing the ticket doesn’t tell us whether the person became better equipped to handle the next one.

Anthropic’s skills study

Seniority needs to mean something concrete

It would be convenient to end this argument with “senior engineers are safe.”

I don’t think that is a responsible conclusion.

Years of experience don’t automatically translate into good judgment. A title doesn’t establish that someone understands the system. And market conditions can affect capable people.

What I do think matters is the ability to make and explain decisions under real constraints.

Should this feature exist? Is a migration worth the disruption? Where should the system tolerate inconsistency? Which failure requires a person? What evidence would change our approach?

Those questions involve technical knowledge, business context, and consequences.

AI can help explore them. It can propose alternatives and expose gaps. I see no reason to declare any particular reasoning task permanently beyond automation.

But a company still needs a way to decide which recommendations to act on, verify the result, and assign responsibility.

For engineers, developing that ability seems a better investment than defining our value around how quickly we can produce an implementation.

Companies have a responsibility here too

We can’t put the entire adjustment on individual developers.

If companies want engineers who understand systems, they need to create opportunities to build that understanding.

That means reviewing reasoning alongside code. Giving less experienced engineers bounded responsibilities with support. Letting them investigate incidents and explain tradeoffs. Protecting some time for diagnosis instead of measuring every task by immediate completion.

It also means checking what productivity metrics encourage.

A team asked to maximize output will optimize for output. If understanding, maintainability, and recovery matter, they need to appear in expectations and reviews.

Otherwise, companies may become faster at creating software while becoming less capable of operating it.

That is a risk worth discussing before it becomes an incident.

What I’m watching next

I’m less interested in the next announcement about the percentage of code generated than in what happens around that code.

Do teams deliver useful changes more reliably? Does review keep up? Are junior engineers developing judgment? Can companies distinguish a convincing demonstration from a maintainable system?

Those are the questions I want to explore through this series at Hyperlane Labs.

AI is changing the work available to engineers and the tools we use to do it. The implications deserve more than reassurance or panic.

Writing code has always been part of the job.

Now we need to get more precise about the rest.