How AI changes engineering — and how it doesn't

Every few years the industry decides that the thing we do is about to fundamentally change.

I have been writing software for about as long as the modern web has existed. I started in an era when ColdFusion was a serious choice and the production cloud was a few people's experiment. The shifts since then have been real. The JavaScript revolution actually happened. The cloud actually happened. The microservices fashion came and went. CI became CD became platform engineering.

None of those shifts changed what software engineering is. They changed the shape of the tools and the price of certain operations. The work underneath stayed roughly the same.

AI is the same. Mostly.

What is actually different

A handful of things in the day-to-day are genuinely faster now.

• The cost of trying an idea. What used to be a half-day spike is now a few prompts and a real running prototype. You can be wrong much faster, which means you can be right sooner.
• The boilerplate tax. Setting up a new endpoint, scaffolding a config file, writing the first draft of a CRUD form — all of those used to take real time. They take none now.
• Mechanical refactors. Renaming a concept across forty files, or lifting a pattern into a helper, has gone from a small project to a small task.
• Documentation lookup. Nobody grep-greps the React docs anymore. You ask. It answers. You move on.
• Code review velocity. Asking for a second pair of eyes used to cost a colleague's afternoon. Now you can get a competent review in thirty seconds, with no shame about asking.

If I had told myself ten years ago that I would never again write yet another CRUD endpoint by hand, I would have been delighted. That part of the job has materially improved.

What is not different

Most of the work of building software, though, is exactly what it was.

Designing an interface that does not corrode the moment it meets reality. Knowing which abstraction to take and which to refuse. Deciding what not to build. Debugging a system that fails only at three in the morning under load that you cannot reproduce locally. Sitting in a room with three opinionated engineers and finding the design that none of them quite wanted but all of them can defend.

None of that has been touched by AI in any meaningful way.

When something breaks in production, the cause is almost never that nobody could write the code. It is that the team had the wrong model of how the pieces fit together, or that one person knew something would fail and could not get heard, or that the system was designed for a load profile that stopped being accurate two years ago. Those failures live in human heads and human conversations. An LLM is not going to attend your standup.

Most production incidents are not technical surprises. They never were. AI does not change that.

The trap

The trap I see, and that I think will play out over the next few years, is that engineers will optimise the parts AI is good at and let the parts AI is not good at atrophy.

The things AI is good at — writing more code per hour, scaffolding more services, generating more tests — are also the things organisations measure. Lines shipped. Tickets closed. Speed of first PR. So the incentive to ride the AI wave on those metrics is strong.

The things AI is not good at — taste, design judgement, knowing what to remove, communicating ambiguity to a stakeholder, owning a decision past the day it was made — are also the things organisations have always struggled to measure. They show up two years later, when you wonder why the codebase feels unowned and the same bugs keep coming back.

The engineers I admire most are using AI as an accelerator on the mechanical parts of the job, and reinvesting the saved time in the parts that compound: design, communication, ownership. The engineers I worry about are using it as a substitute for the muscles those parts require. You can get away with that for a while. You cannot get away with it forever.

A working heuristic

The simplest test I have found is this:

AI is most useful when the target is clear and the steps to get there are mechanical. It is least useful when the target itself is the thing you do not yet understand.

Lean in:

• Refactors with a defined outcome
• Boilerplate where the pattern is known
• Generating tests against a clear contract
• Looking up syntax, APIs, idioms
• First-draft code where the function signature is obvious

Hold the line:

• System design where the requirements are still moving
• Interface decisions that will outlast the people making them
• Debugging unusual production behaviour
• Anything that needs you to know what users actually need rather than what they asked for
• Anything where the next person to read the code will hate the cleverness

What still matters

Two decades into this, I am increasingly convinced that the value an engineer creates lives almost entirely in the part of the work that comes before the code. Choosing the right problem. Designing the right interface. Finding the smaller version of the thing that gets us moving without locking us in.

That work has not been automated and is not about to be.

The code that drops out at the end is almost an artefact of doing those things well. AI has lowered the cost of that artefact. It has not changed what produces it.

If you have built software before AI, the changes are real but smaller than the noise around them. The job is mostly what it was. The interesting question is whether you can use the time AI gives you back to get better at the parts of the job that still require you.