There is a story going around at the moment that makes me wince a little.

It goes something like this:

AI writes code now, so companies will need fewer engineers.

Sometimes it is said carefully. Sometimes it is said as a financial forecast. Sometimes it is said as a boast. Sometimes it is dressed up as efficiency, productivity, or organisational redesign.

And yes, AI is changing the economics of software. Of course it is. I use agentic coding tools every day. They are extraordinary. They help me build, test, document, refactor, research, deploy, and think through systems faster than I could before.

But there is a lazy version of the argument that needs to be stopped before it does real damage.

An engineer is not just someone who writes code.

They are certainly not just someone who writes a bit of Python.

The fashion right now

Amazon's Andy Jassy has written openly about generative AI changing work and reducing the number of people needed for some corporate roles over time. Salesforce's Marc Benioff has talked about not adding more software engineers in 2025 because AI had increased engineering productivity. Microsoft has been cutting roles while also saying, in at least one recent memo reported by The Verge, that eliminated roles were not directly being replaced by AI, even though AI is changing how work gets done.

So the story is real, but it is not simple.

There are layoffs. There are hiring pauses. There are productivity claims. There is over-hiring correction from the pandemic period. There is pressure to fund AI infrastructure. There is also a lot of executive signalling.

And there is a temptation to collapse all of that into one sentence:

"AI replaces engineers."

I do not think that is right.

At least, not if we mean engineers in the real sense of the word.

What do we actually mean by engineer?

We use a lot of words loosely in technology.

Coder.

Programmer.

Developer.

Software engineer.

Platform engineer.

DevOps engineer.

Architect.

Sometimes they overlap. Sometimes they are very different. Sometimes the title is just whatever the company happened to use when the person was hired.

But the thing I want to protect is the engineering part.

Because engineering is not only writing instructions for a computer.

Engineering is understanding constraints.

It is understanding trade-offs.

It is understanding where the business rule meets the system rule.

It is understanding what happens when a thing that worked perfectly in a demo meets users, permissions, data, outages, bad input, latency, cost, regulation, security, and time.

Michigan Technological University's plain definition is useful here: software engineering involves the design, development, testing, and maintenance of software applications. Their list of everyday engineering tasks includes designing and maintaining systems, testing, optimising for speed and scalability, platform compatibility, documentation, releases, standards, collaboration, and upgrades.

That is the point.

Writing code is in the list.

It is not the whole list.

The hidden work

When someone says, "AI can write the code," I always want to ask: which part?

Can it produce a function? Yes.

Can it scaffold an app? Yes.

Can it write tests? Often.

Can it build a first version of a page, a script, an API route, or a database query? Absolutely.

But now ask the questions that come next.

How do we authenticate the user?

How do we know who they are?

Where do we store that identity?

What permissions does that identity create?

What can this person see?

What can this person change?

What must this person never be allowed to do?

Where does the data live?

Is it in the right country?

How much of it do we keep?

How fast will it grow?

How do we encrypt it at rest?

How do we encrypt it in transit?

What happens if the key is rotated?

What happens if the supplier changes terms?

What happens if the API rate limit is hit?

What happens if a dependency becomes unsafe?

What happens if a library updates and breaks the build?

Who owns the incident?

How do we roll back?

What do we log?

What must we not log?

How do we know it is working?

How do we know it is failing?

How do we know it is failing quietly?

That is engineering.

The code is visible.

The engineering is the system around it.

Infographic showing the layers engineers hold together: identity, permissions, data, encryption, APIs, dependencies, deployment, observability, resilience, and business rules.
Code is visible. Engineering is the system around it.

Where data meets the road

A good engineering team is often the glue in a business.

They sit where the policy meets the database.

Where the customer promise meets the API.

Where the board's risk appetite meets the deployment pipeline.

Where the compliance requirement meets the logging system.

Where the product idea meets the messy reality of production.

This is why I keep coming back to architecture and layers. I wrote about this in Agentic Architecture Is Layers All The Way Down. The visible application is only one layer. Under it sit hosting, access, identity, data, communication, authentication, firewalls, runtime behaviour, observability, deployment, recovery, and governance.

If you remove the people who understand those layers, you may still get code.

But you may no longer understand the system.

The AI backfire story is more complicated than the headline

There are already examples of companies finding the limits of replacing people with AI.

Klarna is the most obvious public cautionary tale, though it is mostly a customer-service story, not an engineering one. It pushed very hard on AI-driven support automation and later had to rebalance toward more human involvement as quality and customer experience became a problem.

Gartner has also forecast that by 2027, half of companies that attributed customer-service headcount reductions to AI will rehire staff for similar functions, though perhaps under different job titles. Gartner's point is not that AI is useless. It is that AI is not mature enough to replace the expertise, empathy, and judgement humans provide in complex service contexts.

That matters for engineering because the shape is familiar.

Routine work can be automated.

First drafts can be automated.

Simple flows can be automated.

But when the work becomes complex, ambiguous, risky, contextual, political, operational, regulated, or customer-sensitive, the human expertise comes back into view.

With engineering, that expertise may be even harder to see from the outside because so much of the work is prevention.

Good engineers stop things breaking before anyone notices they might break.

AI changes engineering

None of this is an argument against AI.

Quite the opposite.

AI is changing engineering profoundly. A good agentic harness can help build faster. It can inspect code. It can write tests. It can trace behaviour. It can generate alternatives. It can document. It can spot patterns. It can help with deployment receipts, security checks, browser tests, source analysis, and migration plans.

I would not want to work without it now.

But the DORA 2025 research makes a useful point: AI-assisted software development acts as an amplifier. It magnifies an organisation's existing strengths and weaknesses. The best returns come not from the tool alone, but from the underlying organisational system.

That feels exactly right.

If your team has good architecture, clear ownership, strong testing, good review habits, safe deployment, sensible observability, and people who understand the business, AI can make that team more powerful.

If your team has unclear requirements, weak boundaries, poor test discipline, fragile infrastructure, no one owning security, and a habit of shipping things nobody understands, AI can make that faster too.

That is not always good news.

It is the same distinction I was trying to make in Not Every Workflow Is An Agent: naming the thing properly matters because it changes the supervision, failure handling, audit, and expectation around it.

Speed without engineering is not progress

NIST's Secure Software Development Framework is useful because it reminds us that secure software is not something you sprinkle on at the end. It includes preparing the organisation, protecting software components, producing well-secured software, and responding to vulnerabilities.

That is engineering work.

It is not glamorous.

It is not always visible in the demo.

It may not fit neatly into a productivity dashboard that counts generated lines of code.

But it is the work that stops a clever prototype turning into a dangerous production system.

This is also why I do not like the sneering version of the vibe-coding debate. I wrote about that in Vibe Coding Is Not The Problem. Experimentation is good. Lowering the cost of trying ideas is good. But at some point a system has to grow up. It needs the right level of engineering for the risk it carries.

A toy can be a toy.

A prototype can be a prototype.

A production system needs production thinking.

The cost is moving

I think part of the confusion comes from the fact that code writing has historically been expensive.

So leaders looked at the expensive part and assumed it was the whole part.

Now AI is shrinking the cost of producing code, and some people are making the same mistake in reverse. They think that if the code is cheaper, the engineer is less necessary.

But what may actually happen is that the constraint moves.

From writing code to knowing what should be built.

From producing syntax to understanding architecture.

From implementation speed to system safety.

From typing to judgement.

From individual output to operational reliability.

From "can we make it?" to "can we run it, secure it, explain it, maintain it, scale it, and recover it when it goes wrong?"

That is why I also think the product role will shift toward engineering judgement. In The New Product Manager May Be An Engineer Who Reskilled, I argued that senior engineers may be closer to the new product role than many people expect, because they understand the hidden system constraints.

That argument feels even stronger now.

What I would ask before cutting engineers

If a company believes AI means it needs fewer engineers, I would ask a few questions before accepting the claim.

Who understands the authentication model?

Who understands the permission model?

Who understands the data model?

Who understands the deployment path?

Who understands the incident history?

Who understands which libraries are safe?

Who understands what the system is allowed to do?

Who understands what the system must never do?

Who knows where the bodies are buried?

Who will review the AI-generated code?

Who will explain the trade-off to the business?

Who will say no when the demo is impressive but the architecture is wrong?

Who carries the operational memory?

If the answer is "the AI", then I would be very nervous.

Because the AI only knows what it can see, what it has been told, what it can infer, and what the harness allows it to inspect. It does not know the thing you forgot to mention. It does not know the undocumented business rule unless someone gives it the route to find it. It does not know the political history of why that integration exists. It does not know why the old workaround is still there unless the organisation preserved the memory.

It will do its best.

But systems do not survive on best guesses.

What I think happens next

Some engineering work will absolutely change.

Some roles will shrink.

Some tasks will disappear.

Some teams will become much smaller.

Some organisations will need fewer people doing the same old work.

But the good engineers will become more important, not less.

They will work at a higher level.

They will direct agentic systems.

They will design the constraints.

They will review the output.

They will understand the architecture.

They will know when to let the agent run and when to stop it.

They will be the people who can move between business intent and technical reality without pretending either side is simple.

And that, to me, is the real story.

AI may make code cheaper.

It does not make engineering optional.

In fact, once code becomes abundant, engineering judgement becomes the scarce thing.

Sources and notes

This is a researched opinion piece. I have deliberately separated AI-linked workforce claims from harder evidence of specific engineers being fired and rehired. The public evidence is stronger for hiring pauses, restructuring, customer-service automation reversals, and broader productivity claims than for a clean Big Tech story of "engineers fired, AI failed, same engineers rehired".