This month an engineer published an essay titled LLMs are eroding my software engineering career and I don't know what to do.

The post resonated because it captures a fear many engineers have but rarely say out loud:

What if everything I spent fifteen years learning becomes a prompt?

I think the fear is real.

I also think it's aimed at the wrong target.

The author describes watching skills he spent years developing become accessible to anyone with an LLM. Domain expertise. Debugging. Architecture.

The conclusion is understandable:

If another engineer can get similar answers by prompting a model, what exactly was all that experience worth?

I think he's measuring the wrong thing.

For most of software's history, implementation was expensive.

Because it was expensive, we confused implementation with engineering.

AI is exposing the difference.

When I ask an LLM to write an API, generate tests, create infrastructure, or refactor code, it often does a surprisingly good job.

What it has proven is that much of what we considered engineering work was really translation work.

Taking an already-decided solution and converting it into code.

The uncomfortable question is:

If a model can do that part, what remains?

The answer is the part that was always hard.

The hardest problems I've worked on were never implementation problems.

They were definition problems.

I've never seen a major production incident caused by someone being unable to write a for-loop.

I've seen plenty caused by teams disagreeing about what "active customer" meant.

• What exactly does "active customer" mean?
• Why do two systems disagree?
• What business rule are we actually trying to enforce?
• What happens when requirements conflict?
• Which tradeoff are we willing to make?

The difficulty was never writing the code once those answers existed.

The difficulty was discovering the answers in the first place.

That's where I think a lot of the discussion around AI goes off track.

People talk about domain expertise as if it were a collection of facts.

Facts have always been the easiest thing to transfer.

You can learn settlement systems, advertising auctions, logistics workflows, or healthcare regulations.

Given enough documents, an LLM can learn them too.

The mistake is assuming domain expertise is knowing facts.

The real value is identifying where the domain is contradictory, incomplete, or undefined.

That is where engineering begins.

Engineering isn't memorizing a domain.

Engineering is creating a model of that domain that is precise enough for a computer to execute.

Those are very different skills.

One engineer reads a hundred requirements and starts writing code.

Another engineer reads the same hundred requirements and realizes twenty of them cannot all be true at the same time.

They notice:

• Three contradictions
• Two missing assumptions
• One business decision nobody realized still needed to be made

The second engineer is still doing something the model cannot reliably do because the answer doesn't exist yet.

Someone has to discover it.

That's why I don't think AI is making senior engineers less valuable.

I think it's making it harder to hide behind implementation.

For years, engineers could create value through sheer output.

If you were faster than everyone else at building things, that mattered.

Today the cost of implementation is collapsing.

The leverage is moving somewhere else.

The differentiator is becoming judgment.

• Can you identify the real problem?
• Can you model a messy business domain?
• Can you create the right abstractions?
• Can you define constraints that prevent entire classes of failures?
• Can you design systems that remain understandable years later?

Those are the skills that survive every tooling revolution because they determine what should be built, not merely how it gets built.

The engineers who built their identity around implementation throughput should probably be worried.

The engineers who built their identity around understanding systems should be excited.

AI is not eliminating engineering.

It is removing more and more of the construction work and forcing us to confront what engineering actually is.

AI can generate code.

AI can explain patterns.

AI can summarize domains.

But when requirements conflict, stakeholders disagree, and the answer does not yet exist, someone still has to decide what is true.

Someone still has to define the model.

Someone still has to make the tradeoff.

Someone still has to turn ambiguity into a system.

That is where engineering begins.

If this resonated with you, connect with me on LinkedIn or subscribe for future posts on software architecture, engineering leadership, AI, and system design.