AI Won't Replace Engineers (But It Will Change Us)

Neither doomer nor hype-a realistic assessment of how AI is changing software engineering based on daily experience building AI systems and using AI tools.

I spend most of my week either using language models to write code, or building systems on top of language models for clients. So when people ask me whether AI will replace engineers, I have a strong opinion, and a slightly boring one: no, but the job in five years is not the job today.

This essay is the version I keep giving in conversations, written down so I can stop repeating it.

The two bad answers

There are two takes that dominate the discourse and I think both are wrong.

The first is the doomer take: language models will fully automate engineering, juniors are cooked, and we should all retrain. This take consistently underestimates how much of the job is deciding what to build, who to build it for, and how it should fail. None of that is being automated, because none of that is text prediction.

The second is the cope take: AI just generates plausible-looking nonsense, real engineers will never use it, this is all hype. This take is held mostly by people who have not seriously tried recent tooling. The productivity delta from a well used assistant is not zero. It is large enough that ignoring it is itself a career risk.

The truth, in my experience, is in between, and it is more interesting than either pole.

What is actually changing

A few shifts I see clearly, both in my own work and in the teams I advise through /services.

The cost of code is dropping

Writing a function used to be a meaningful unit of work. It is becoming closer to a punctuation mark. This sounds like good news, and partially it is. But it has a second order effect: when code is cheap, the bottleneck moves to everything around the code. Specs. Tests. Reviews. Operations. The places that were already underinvested.

Teams that respond to AI by writing more code, faster, are usually getting worse, not better. Teams that respond by tightening their definition of done are getting much better.

The shape of seniority is shifting

Junior engineers are not going away, but the things they used to learn by doing are partly being done by tools. This is a real problem, not because juniors cannot learn, but because the old apprenticeship loop assumed they would type a lot of mediocre code and slowly internalize patterns.

We need new ways to build judgment. From teams I have worked with, the ones that thrive are pairing aggressively, doing more code reading, and treating prompts as a first class artifact in code review.

Review is the new bottleneck

If a model can produce a hundred lines of plausible code in twenty seconds, your review process becomes the rate limiter for quality. Most review processes were not designed for this throughput. They are starting to crack.

The teams I see handling it well are doing two things: writing much sharper acceptance criteria up front, and treating any AI generated change with the same skepticism they would treat a contractor's first PR. Trust is earned per change, not granted per tool.

What is not changing

A surprising number of things are stable.

• Understanding the actual problem. Models are spectacularly bad at noticing when the user asked the wrong question.
• Living with consequences. A model does not get paged at 3am. The person who shipped does. That asymmetry shapes every architectural decision worth making.
• Saying no. The most valuable engineers I know are the ones who push back on bad ideas. Models are sycophants by training.
• Cross system reasoning. Anything that requires holding three subsystems and a deadline in your head at once is still very much a human job.

What I think the next few years look like

My best guess, and it is a guess.

1. Solo and small team output goes up sharply. A two person team in 2027 will reasonably ship what a six person team shipped in 2022. This is great for indie work and brutal for middle management.
2. The "AI engineer" role consolidates. Building reliable systems with LLMs is its own discipline now, with its own evaluation, observability, and failure modes. I write about this in the Production AI series.
3. The floor rises, the ceiling rises faster. Average code quality probably improves. The gap between average and excellent gets larger, not smaller, because taste compounds against cheaper code.
4. Some jobs do shrink. Not "engineers" as a category, but specific roles whose entire value was producing boilerplate. That was already a fragile place to stand.

What to actually do

If you are an engineer reading this and wondering how to position yourself, my honest advice is unspectacular:

• Get extremely fluent with the current tools. Not as a believer, as a user.
• Invest in the parts of the job that are not text generation: design, debugging, communication, system thinking.
• Build at least one thing end to end with an LLM in the loop, so you have first hand intuition for where they break.
• Keep writing. The people who can think clearly in prose are going to do disproportionately well in a world where the cheap thing is producing more text.

If you want to talk about this in the context of a real product, /start-project is open. Most of the AI work I do now is helping teams figure out which of these shifts apply to them and which are noise.

References

• Anthropic: Building effective agents
• Simon Willison: AI assisted programming
• GitHub: Research on Copilot productivity