Engineers Aren't Going Anywhere

Open Twitter right now and scroll for thirty seconds. You'll find someone explaining why software engineers are finished - Claude Code ships features, Cursor writes functions, the AI agent future is here, so you'd better learn prompt engineering or learn to flip burgers.

I've been building software for a decade and I use Claude Code every day, so I'm not here to tell you the tools aren't impressive. They are. But the "engineers are dead" takes floating around right now? They fundamentally misunderstand what engineering actually is.

Let's acknowledge what's actually happening here, because dismissing the tools would be dishonest. Claude Code is remarkable - I watched it refactor a 200-line function into clean, tested modules in minutes last week. It catches bugs I miss, remembers documentation I forgot, and writes boilerplate so I don't have to. As a force multiplier for the mechanical parts of coding, it's the most significant tool I've used since I switched from Sublime to VS Code.

And the demos are genuinely impressive. Someone types "build me an app that does X" and twenty minutes later there's a working prototype with auth, a database, and a UI that doesn't look terrible. VCs are posting about 10x productivity gains while founders tweet about "right-sizing" their engineering teams. The discourse has reached the fever pitch that makes everyone either terrified or smugly dismissive.

I get why people are freaking out. If you've never built software professionally, watching Claude Code work looks like the whole job - like the only thing engineers do is type code into a computer, and now the computer can type code into itself.

Here's what Claude Code is genuinely exceptional at:

• Writing code from clear specifications. Give it a well-defined function with inputs, outputs, and edge cases, and it'll write solid code - often better than what I'd write quickly.
• Translating between formats. Convert this JSON to TypeScript types, turn this SQL into an ORM query, refactor this class component to use hooks. Mechanical transformations where the logic is clear.
• Implementing known patterns. Add authentication, set up a REST endpoint, create a form with validation. Stuff that's been done a million times and documented extensively.
• Explaining and documenting. What does this code do? Write tests for this function. Add JSDoc comments. Anything where it can read existing code and describe or extend it.

These are real tasks that take real time - engineers spend hours on them every week, and automating that work is genuinely valuable. I'm not being dismissive.

But notice what all of these have in common: the problem is already defined. Someone figured out what needed to be built, decided on the approach, and broke it down into pieces that could be implemented. The hard thinking already happened. Claude Code is executing a plan, not making one.

We use Payload as our headless CMS. A few weeks ago, production crashed. The error logs pointed to a GraphQL query failing. Someone had renamed a field in the Payload schema - changed heroTitle to headline - and the Payload deployment went through fine. Tests passed. CI green. But the frontend was still querying the old field name. Blank page.

Claude Code didn't catch this. Couldn't have. The CMS and the frontend are separate repos, separate deployments. The schema change was valid code. Payload's types updated correctly. But nobody updated the frontend queries to match. No linter connects those two codebases. No AI sees across that boundary. A human has to remember that renaming a field in one repo means updating queries in another. And we forgot.

Or take regulatory work. We had to restrict a feature to EEA countries last month. Sounds simple until you realize the UK isn't in the EEA anymore. Someone has to know that. Someone has to ask "wait, does EEA include the UK?" and then know the answer is no, not since Brexit, and then update the country list accordingly. That's not a coding problem. That's a "paying attention to the world" problem.

Actual coding? Maybe a quarter of the week. The rest is catching the things that fall between systems, remembering context that isn't written down anywhere, and knowing which questions to ask before something breaks.

Here's what Claude Code can't do: it can't tell you whether the function it just wrote should exist in the first place. It can implement a feature flawlessly while having no idea that the feature will confuse users, create security holes, slow down the app, or conflict with something you're planning to build next quarter. It can refactor your code into beautiful abstractions without knowing that the refactor isn't worth the risk right now - not with your deadline, your test coverage gaps, and the three new engineers starting Monday who'll need to understand the codebase.

Software engineering is thousands of judgment calls, made every day, often without enough information:

• Should we build this now or later?
• Is this abstraction worth the complexity it adds?
• Will this scale? Does it even need to?
• What's the real problem here, underneath what the stakeholder asked for?
• Is this bug worth fixing or should we live with it?
• What's going to break if we change this?
• Why did the previous team build it this weird way - did they know something we don't?

These questions require context that doesn't fit in a prompt: the history of the codebase, the relationships between teams, the business constraints nobody wrote down, the technical intuition built over years of watching things fail. The stuff that makes an engineer senior isn't how fast they type.

Engineers won't disappear. But the job is shifting.

The time spent on mechanical tasks-writing boilerplate, implementing standard patterns, translating designs into code-is shrinking. Claude Code handles that. It handles it well.

That means the remaining work is higher-leverage. More architecture. More system design. More debugging complex interactions. More communication with stakeholders. More judgment calls.

Junior engineers face a harder path. The entry-level tasks that used to train them are increasingly automated. They'll need to develop judgment faster, with less scaffolding. That's a real challenge and the industry needs to figure it out.

Senior engineers are more valuable, not less. Their judgment is exactly what AI can't provide. The engineer who can look at a codebase and see problems that won't manifest for six months? The one who can translate vague business requirements into technical plans? The one who knows which corners to cut and which to perfect? That person matters more when the mechanical work is automated away.

The best engineers are already using AI as a multiplier. They're shipping faster, with higher quality, because they're spending less time on the mechanical and more time on what matters. They're not being replaced. They're being amplified.

So no, engineers aren't going anywhere. The ones who think their job is typing code might struggle. The ones who understand their job is solving problems? They're just getting started.

The "engineers are dead" crowd will be wrong about this like they were wrong about every previous wave of automation. And in five years, they'll be breathlessly predicting the next thing that definitely, for real this time, replaces us.

We'll still be here. Building things. Making judgment calls. Using whatever tools are available.

That's the job. It always was.