There is a narrative running through the industry right now: AI is getting good at writing code, therefore software engineers are about to be replaced.
The argument sounds plausible and makes for good headlines. It also misreads what software engineering has always been.
The profession that automates itself
Software engineering is the only major profession whose core activity is building tools that eliminate the need for its own previous work. That instinct is not new. It is the founding impulse of the entire field.
Compilers automated the translation of human-readable instructions into machine code. Frameworks automated the infrastructure every application used to build from scratch. CI/CD automated deployment. Cloud automated provisioning. Infrastructure-as-code automated operations. Each of these advances removed engineers from lower-level work. None of them reduced the demand for engineers.
Every time a layer of abstraction was added, the scope of what software could do expanded, and the number of engineers needed to build it grew. The best engineers have always described their job the same way: find the repetitive thing, automate it, move on to the harder problem. AI-assisted code generation is the latest instance of this pattern, not a departure from it.
Why the “replacement” narrative misreads the pattern
The argument that AI will replace software engineers rests on a specific assumption: that the primary value of an engineer is writing code, and that once code becomes cheap to produce, the engineer becomes redundant. This is wrong on both counts.
Writing code has never been the bottleneck. AWS survey data shows the average developer spends roughly 20% of their time actually writing code. The rest goes on design, debugging, review, meetings, coordination, and context-switching. AI coding assistants have optimised the 20%. The other 80% is untouched.
More importantly, every previous round of automation in software followed the same pattern. Higher-level languages did not eliminate programmers. Cloud infrastructure did not eliminate operations engineers. Web frameworks did not eliminate backend developers. In each case, the cost of building software dropped, the scope of what software could address expanded, and demand for engineers increased.
There is no historical precedent for a layer of software automation reducing engineering headcount in aggregate. There is extensive precedent for it expanding the reach of the profession.
The domains that never automated themselves
Software engineering is unusual among knowledge professions in its relationship to automation. Most other organisational functions, HR, legal, finance, compliance, customer support, operations, have no equivalent instinct. These domains were built to manage process, ensure accuracy, and maintain compliance through human oversight. Not to automate.
The result is that many of these functions still run on manual workflows, spreadsheets, and email chains that have not fundamentally changed in decades. A compliance team might use a modern platform to track regulations, but the actual work of reviewing policies, flagging exceptions, and producing reports is still largely done by people reading documents and filling in forms. A finance team might use cloud accounting software, but the month-end close still involves reconciling spreadsheets by hand.
This is not a criticism of these professions. Automation was never their mandate. But it creates an asymmetry: the one profession wired to automate everything is about to have significantly more capacity to do so.
Engineers with spare capacity will expand
If AI reduces the time engineers spend on routine code production, the question is not whether engineers will have enough to do. The question is what they will do with the freed capacity.
History gives a clear answer. When an engineer encounters a manual process, the instinct is to systematise it. When they see a workflow that relies on copy-pasting between spreadsheets, they build an integration. When they watch a colleague spend hours on something scriptable, they write the script.
This has already been visible for years in the growth of internal tooling, workflow automation platforms, and the platform engineering movement. What changes with AI is the economics. Building an internal tool to automate an HR onboarding workflow used to require weeks of dedicated engineering time. With AI-assisted development, it might require days. The cost of automating a process in another department drops significantly.
The likely result is not fewer engineers. It is engineers expanding into domains they previously couldn’t justify the time to address.
What this looks like in practice
This pattern is already emerging. Companies are building AI agents that handle first-line customer support triage. Engineering teams are creating automated compliance checking systems. Internal tools are replacing manual finance reconciliation workflows. Operations processes that used to require dedicated headcount are being converted to software systems maintained by small engineering teams.
Engineering capacity, augmented by AI, is being directed outward from the traditional software product and toward the operational infrastructure of the business itself. The engineer is no longer just building the product customers use. They are building the systems the organisation runs on.
If the cost of building software drops by half, and the number of organisational processes that can be profitably automated doubles, the demand for engineers doesn’t decrease. The boundary of what counts as engineering work moves outward to include problems that were previously someone else’s spreadsheet.
What organisations should expect
If AI makes engineers more productive at writing code, but organisations still have dozens of manual knowledge-work processes waiting to be automated, the return on engineering time shifts. The marginal value of one more product feature goes down. The marginal value of automating an internal workflow goes up.
For engineering leaders, the question is not how to protect headcount from AI. It is how to direct engineering capacity toward the highest-value automation opportunities across the business. That means rethinking the boundary between product engineering and internal engineering, identifying which manual processes in HR, finance, legal, and operations are candidates for automation, and recognising that the engineer who builds an AI-powered contract review system may deliver more value than the engineer who ships another product feature.
For non-engineering functions, the implication is different but equally important. The departments that engage with engineering teams to identify automation opportunities will gain leverage. The ones that resist will find themselves increasingly bottlenecked by manual processes the rest of the organisation has moved beyond.
The real shift
Every time the cost of creating software has dropped, the scope of software has expanded. Engineers have never been automated away. They have moved up the abstraction ladder and started automating the next layer.
If AI really does reduce the time engineers spend writing code, history says they won’t disappear. They’ll start automating everything else.
Analysis draws on historical patterns in software engineering automation, AWS developer survey data on time allocation, and DX Research productivity studies (2025-2026).
The argument that AI won’t replace engineers because engineers will just automate everything else is an optimistic read of history. It is also selective in what it chooses to learn from that history.
Yes, previous automation waves expanded engineering demand rather than contracting it. But those waves automated narrow technical processes within the domain engineers already understood. What’s being described here is something different: engineers moving into HR, legal, finance, compliance, and automating processes they have no domain expertise in. That’s a much harder problem than abstracting away a deployment step.
The limits of the historical analogy
The automation-ladder argument is valid within software engineering. Compilers, frameworks, CI/CD: each layer of abstraction moved engineers up the stack while demand grew. The argument holds because each new layer was still within the engineers’ domain. They understood what they were automating.
Automating a legal review process is not the same as automating a deployment pipeline. The engineer building a compliance checking system needs to understand the compliance rules, the edge cases, the regulatory context, and the consequences of errors in ways that can’t be absorbed in a sprint. Getting this wrong does not mean a failed deployment. It can mean regulatory violations, legal exposure, or systematically incorrect decisions affecting real people at scale.
Domain expertise matters in automation. The history of internal tooling is full of systems built by engineers who didn’t understand the domain they were automating, producing tools that technically work but practically fail because they baked in wrong assumptions.
The 80% that AI hasn’t touched
The claim that AI has optimised the 20% of engineering time spent writing code while the other 80% is “untouched” deserves scrutiny. AI tools are increasingly being applied to code review, debugging assistance, documentation, and architecture decision support. The 80% is not static.
More importantly, if AI does eventually automate a larger proportion of what engineers spend their time on, the argument shifts. Freed capacity is only redirected to new work if organisations choose to redeploy it rather than reduce headcount. History shows both outcomes happen. The companies that grew engineering demand through previous automation waves were generally expanding. The ones that contracted were using automation to reduce costs.
The current economic environment is not uniformly one of expansion. Many companies are under significant pressure to reduce headcount. Freed engineering capacity is not automatically redirected to automating HR workflows. Some of it becomes redundancy.
The bottleneck is not always technical
The deeper issue with the “engineers will automate everything else” thesis is the assumption that the bottleneck in HR, legal, finance, and compliance is the lack of automation capability. Often it isn’t.
These functions are manually intensive partly because the work requires judgment that is genuinely hard to encode. Legal review isn’t slow because no one has thought to automate it. It’s slow because each contract is different, context matters, and errors have serious consequences. Finance reconciliation involves exceptions and edge cases that resist systematisation. HR processes are politically complex in ways that make full automation risky.
The engineers who have tried to automate these domains and succeeded tend to report that the hardest part wasn’t the technical build. It was understanding the domain well enough to know what to automate and what to leave alone.
What this means in practice
None of this means the “engineers expand outward” thesis is wrong. It means it is harder than it sounds, and the track record of cross-domain automation projects is more mixed than the optimistic version acknowledges.
Engineering teams that partner closely with domain experts, move carefully, and build systems that augment human judgment rather than replace it tend to succeed. Engineering teams that treat domain expertise as an obstacle and build fast tend to produce systems that create new problems while solving the original ones.
The engineers who will thrive are not just the ones who see automation opportunities everywhere. They are the ones who can tell the difference between a process that should be automated and one that only looks like it should.
The “AI will replace engineers” narrative is not just wrong. It is the opposite of what is about to happen.
AI is going to make software engineers dramatically more productive. And the most important consequence of that is not that fewer engineers get hired. It is that engineering capacity gets redirected outward, into every corner of the organisation that has been running on manual processes for decades.
The profession that automates itself
Software engineering is unique because its core activity is eliminating the need for its own previous work. Every generation of engineers automates the layer beneath them and moves on to harder problems. Compilers, frameworks, cloud infrastructure, CI/CD: the history of the field is a history of engineers automating themselves out of yesterday’s work and into tomorrow’s.
AI-assisted code generation is not a threat to this pattern. It is the latest iteration of it. The engineers who understand this are already thinking about what comes next. The ones focused on defending their role in code writing are thinking about the wrong thing.
The scope of what’s about to be automated
Most organisational functions have spent decades running on processes that engineers would have automated years ago if they’d had the time and the mandate. HR onboarding still involves people moving data between systems. Finance close still involves reconciling spreadsheets by hand. Legal review still involves humans reading documents. Compliance still involves filling in forms.
These aren’t gaps that haven’t been noticed. They are gaps that engineering teams couldn’t justify the cost to close. A month of engineering time to automate an HR workflow that affects 50 people once a quarter didn’t make economic sense against the backlog of product work. That calculus is changing fast.
AI drops the cost of building internal tools dramatically. Workflows that used to require weeks of engineering time now require days. The processes that couldn’t justify automation before can now. The scope of what engineering teams will be expected to automate is about to expand significantly.
Engineering as the new organisational OS
The implication is bigger than internal tooling. The organisations that move fastest are going to be the ones that treat their engineering teams as infrastructure builders for the whole business, not just the product.
In this model, engineers are not optimising features. They are automating the operational layers of the business itself: compliance, finance, HR, operations. Every department that currently relies on manual knowledge work becomes a candidate for systematic engineering attention.
This is already visible in the companies running furthest ahead. Engineering capacity is being deployed against internal operations, not just external products. The result is that AI-era companies run with significantly less administrative overhead than their competitors, because most of what was previously human-managed process has been systematised.
What happens to the engineers
The engineers who will thrive are not the ones who write the most code. They are the ones who can look at any organisational function and see the automation opportunity inside it. The constraint shifts from coding speed to problem scope.
The best engineers have always been like this. What changes is that AI gives them the capacity to act on that instinct at scale, across the whole organisation, not just within the product. Engineering as a function stops being a department that builds software and becomes something closer to the operational brain of the business.
The engineers who see this coming are positioning themselves accordingly. The ones waiting to be replaced by AI are not paying attention to what history keeps showing.
Comments
Loading comments…
Leave a comment