■ HIGH RISK ■ Technology
Partly. Expect the profession to survive and the headcount curve to bend hard, because one engineer directing a fleet of coding agents now covers ground that used to need a squad.
“Architecture, system design, and trade-offs still need a human brain. The coding part? AI's got that.”
Our AI replacement risk score — how we score jobs
Engineering has always been broader than coding. A typical week includes design documents and their arguments, breaking a feature into deliverable slices, negotiating an interface with another team, reviewing pull requests, an incident and its postmortem, capacity and cost decisions, migration planning, and a surprising quantity of conversation with product managers about what the requirement really means. Writing code is a minority of the calendar for most engineers past their second or third year, which is precisely why the score sits below the pure programmer's.
Automation is nonetheless biting hard. Agents handle implementation, test generation, dependency upgrades, log triage and first-draft documentation. Code review assistants catch a meaningful fraction of defects. Infrastructure-as-code and deployment pipelines generate cleanly, and observability tooling summarises incidents automatically. The compounding effect is leverage: the same feature ships with fewer people, which shows up as slower hiring rather than mass layoffs, and it hits the middle of the seniority distribution hardest because that tier's value was largely reliable execution.
What holds is the part that requires living with consequences. System design is a series of trade-offs made under uncertainty about future load, team size, regulatory change and organisational politics, and being wrong costs years. Incident command demands forming a hypothesis about an unfamiliar failure with production burning and incomplete telemetry. Security architecture, data modelling that outlives three product pivots, and the ability to say no to a plausible-but-wrong design are all judgement under accountability. Engineers also increasingly own the AI systems themselves: evaluation harnesses, guardrails, cost control and the unglamorous work of making a probabilistic component behave inside a deterministic product. That is a growth area, and it is why our score is 65 rather than higher.
Automatability: our editorial assessment of current and near-term AI capability
Serious pressure is already here and intensifies through 2030. The pattern so far is compression rather than elimination: teams do more with fewer engineers, hiring slows disproportionately at junior and mid levels, and expectations of individual output rise. By the early 2030s a typical product team looks materially smaller, with engineers spending most of their time specifying, reviewing and operating rather than authoring. Demand for engineers who can build and run AI-dependent systems partially offsets the contraction.
Yes, but a more demanding and more senior-weighted one. Software demand keeps growing, and someone has to design, integrate, secure and operate systems that now include unreliable probabilistic components. The uncomfortable part is that the entry ladder is thinner and expectations for individual output are far higher than they were even a few years ago.
Those whose contribution is mainly executing well-defined work on well-documented stacks: standard web CRUD, straightforward integrations, routine feature delivery. Least exposed are engineers with deep domain knowledge, production ownership, security or distributed systems expertise, and those working close to hardware, regulation or messy real-world constraints that never made it into documentation.
Specialising in building products with AI is a strong bet; specialising in training frontier models is a much narrower field with brutal competition. The practical, well-paid version is engineering around models: retrieval, evaluation, guardrails, latency and cost, plus the plumbing that makes an unreliable component acceptable in a real product.
Both, depending on the discipline around it. Generation is genuinely fast for well-scoped work, and genuinely dangerous when nobody reviews architecture, security or long-term maintainability. Teams that pair generation with strong testing, review and observability get real leverage. Teams that ship unread output accumulate expensive debt at unprecedented speed.