DEV Community

Cover image for Is Software Dead? Part Three: Engineers
kate astrid
kate astrid

Posted on

Is Software Dead? Part Three: Engineers

#programming #ai #productivity #discuss

Every few weeks, someone posts that software engineering is over.

Meanwhile, according to Indeed data reported by CNBC, U.S. software development job postings rose nearly 15% between late February 2025 and early 2026, while overall postings fell about 7%.

So which is it?

This is part three of the "Is Software Dead?" series. Part one covered the business side, and part two covered users. This one is about us, engineers at every level, from the first job to the staff title.

What changed

The amount of code we produce exploded.

  • GitHub reports that about one in three pull requests now involves an AI agent, up from fewer than one in ten a year earlier.
  • JetBrains found that around 39% of professional developers used Claude Code at work in mid-2026, up from 18% in January.
  • I can describe a component and get two hundred lines of reasonable code in under a minute. So can everyone reading this.

When something gets cheap, the thing next to it gets expensive. For us, that thing is understanding.

The new bottleneck: comprehension

Anthropic ran a randomized trial with 52 engineers who were learning a new Python library. The engineers with an AI assistant finished in about the same time as the others. On a quiz afterwards, they averaged 50% while the others averaged 67%.

The most interesting detail sits inside that result. The engineers who asked the AI to explain its code scored much closer to the others. The ones who handed over the whole task scored lowest.

Addy Osmani has a name for what builds up when we skip that thinking: comprehension debt. It's the growing gap between how much code a system has and how much of it any human understands.

I see the same thing in my own work. A 12-line class from an AI tool can hold five design decisions: a class name, a method name, a folder, a pattern and a dependency. Each one looks reasonable. If we accept them on autopilot, we end up with the tool's architecture by default, one small yes at a time.

The job, rewritten

Here's how I see our work shifting.

We used to optimize for Now we optimize for
Writing code fast Reading code fast
Knowing the syntax Knowing the system
Closing the ticket Choosing the right ticket
Debugging our own code Debugging code a tool wrote
Code review as a formality Code review as the main event

Typing was always the easy part of the job. AI made that obvious.

Juniors are engineers too, and they feel it first

I want to be honest about this part. The people at the start of their careers feel the pressure first.

  • Stanford's 2026 AI Index found that employment for software developers aged 22 to 25 fell about 20%, mostly through fewer hires.
  • According to Indeed, 71% of the growth in software development postings between May 2025 and May 2026 came from senior roles.

Most senior engineers learned the job through small, boring work: tiny bugs, tests, docs and a lot of reading other people's code. Teams hand much of that work to AI now. That leaves a hard question for all of us: if every senior engineer was once a junior, where do the next seniors come from?

The industry needs them. In the 2025 Stack Overflow Developer Survey, 66% of developers named code that's "almost right" as their biggest frustration with AI tools. Spotting "almost right" takes judgment, and people build judgment through practice.

This one is personal for me. I came into programming later than many of my colleagues, and I learned by asking a lot of questions. At one job, I spent several months nodding along whenever someone said "entity" before I admitted I was lost. Today I mentor developers on ADPList, and I'd give anyone starting out the same advice the Anthropic study points to: use AI as a tutor. Ask it why, ask it for the alternative, and ask it what would break. The engineers who did that kept their understanding.

For teams, the move is equally clear. Keep hiring juniors, turn code review into teaching, and make it safe to say "I'm lost." The teams that grow juniors today will have the seniors everyone else is trying to hire in five years.

Five habits I'm building

1. I read generated code like a teammate's pull request. I ask why it has this name, why it lives in this folder and why it uses this pattern.

2. I ask for the explanation before I accept. "Walk me through this" takes thirty seconds and saves me hours later.

3. I write the plan first. I sketch the input, what happens in the middle and the output. If I get stuck there, the problem is my mental model, and that's worth knowing before any code exists.

4. I look for the clue that disagrees. When every clue agrees with my first idea, I go looking for one that could prove me wrong, and I check that one first.

5. I spend the saved time on the problem. I talk to users, read about the domain and sit in on support calls. That's where the hard parts of software live.

So, is software engineering dead?

Typing code is becoming a smaller part of the job. Understanding systems, users and trade-offs is becoming the whole job.

The engineers who thrive in this era will be the ones who stay curious about why the code works, even when a tool wrote it.

In part four, I look at my own field, developer relations, and how it changes now that our docs have a second reader: the agent.

What part of your job got harder since AI started writing code? I'm genuinely curious, so tell me in the comments.

Sources

Top comments (0)