AI Is Not Replacing Engineering. It Is Repricing It
Part One: Burning the Steamship
This is the first of three issues on what AI is actually doing to engineering value.
I talk to a lot of engineers.
That sounds like a throwaway line, but it matters here. In my role as Developer Advocate at HeroDevs and as Community Director for the London Java Community, I spend a lot of time with developers, QA engineers, AppSec people, platform teams, architects, engineering managers, and the occasional greybeard who knows exactly where the bodies are buried.
A lot of them are worried about AI.
Not in the vague, LinkedIn-flavoured, “the robots are coming” sense. Actually worried. They see vibe coding and the ilk being used to replace or subsume the work they spent years getting good at. Seeing what they do being casually reclassified as something an LLM can handle. Something a smaller team can absorb. Something that no longer needs the same level of human judgement.
They see job backfills cancelled, teams reduced or consolidated. They see QA treated as a luxury or a barrier. They see AppSec asked to cover more repositories, more agents, more integrations, more generated code, and more exceptions. All with roughly the same number of humans. They see senior engineers move into AI initiatives, and nobody quite admits what that impacts.
The headlines do not help.
Oracle, Java, and Why Developers Notice
When Oracle reportedly cuts thousands of jobs while stepping up AI infrastructure investment, developers do not need a spreadsheet to join the dots (Reuters, The Guardian).
For the Java community, Oracle is not just another logo in the AI capital-expenditure story. Oracle stewards Java. Its decisions ripple through the long-lived, compliance-heavy, integration-heavy platforms that run enormous chunks of the global economy.
So yes, Java people notice.
But “AI is replacing developers” is still the wrong story.
Emotionally plausible? Absolutely. Jobs are being cut. Roles are being reorganised. Teams are being flattened. Executives talk openly about AI and Agents changing how much human labour they need. The fear is grounded in something real.
It’s just that the simple version is too simple. Worse, I think, it lets leadership off the hook. If AI simply replaces developers, the conversation becomes fatalistic — the machines are coming, the humans are doomed, we’ve all seen the movies, nothing to see here except a career change and a resignation letter.
AI Is Repricing Engineering
Organisations are not doing a clean one-for-one substitution of human intelligence. They are changing the value of different kinds of engineering labour. Capital is moving. Hiring attention is moving. Executive focus is moving. The premium dollars are flowing toward AI infrastructure, AI product work, model engineering, data-centre capacity, and the smaller pool of people who can credibly operate in that world.
For Java developers who have spent years being at the centre of commercial technical change, it can feel strange to realise that the new premium technology is not Java.
To be fair, movement from one tech innovation to another is how the world works. When Java arrived, many developers found some of their skills sidelined. But AI is different. We are moving from a deterministic world to a non-deterministic one. Replacing tech with better versions (faster, cheaper, easier) is normal. Replacing deterministic behaviour with non-deterministic variants is new and comes with many sharp edges.
Some of those edges we will deal with. Others we will have to live with. That is how innovation works: humans and technologies find a meeting point, and both adapt. The problem is that the hype promotes the promise rather than the reality and fails to reveal the opportunity's cost.
Which is why we are seeing a shift in what engineers are worth and what they are for. And that thought process often leads to misguided conclusions.
Burning the Ship
There is a moment in Around the World in Eighty Days where Phileas Fogg buys the steamship taking him home and literally burns most of it for fuel to make the deadline.
That image has been stuck in my head as I watch the current AI investment cycle.
You can see it when you follow the money:
Alphabet’s capital expenditure rose from $32bn in 2023 to $52bn in 2024 and $91bn in 2025 (Alphabet 2025 Annual Report)
Meta guided to $115bn–$135bn for 2026 after $72bn in 2025 (Meta Q4 and Full Year 2025 Results)
Amazon moved from $78bn in 2024 to $128bn in 2025, then guided toward roughly $200bn in 2026 (Amazon 2025 Annual Report)
Microsoft increased AI infrastructure spend while also conducting major layoffs and keeping total headcount roughly flat (Microsoft 2025 Annual Report, CRN)
The deadline has become so important that the ship itself becomes fuel.
What Gets Burned
In enterprise technology, the things being burned are rarely glamorous.
Maintenance. QA. AppSec. Platform stewardship. Dependency hygiene. Migration capacity. Documentation. Review discipline. The senior engineer who knows why the authentication flow looks insane but still works. The tester who knows which “impossible” customer configuration will break the release. The AppSec person who remembers why that exception exists and what the plan is.
These things do not appear in financial discussions with VCs, but they do stop your business from becoming an incident report.
We do not have to guess whether the smoke is real. GitClear’s 2025 research, based on 211 million lines of production code, found a sharp fall in code updates dedicated to refactoring and reuse since the mass adoption of AI assistants, alongside a major increase in copy-pasted code blocks. Sonar’s data points the same way: developers are using AI heavily, but verification is becoming the bottleneck.
You get more code. You may even get more features. But beneath that apparent speed, you can be trading clean, maintainable architecture for synthetic debt, widening security gaps and increasing operational costs that arrive faster than your review process can absorb.
The Question Nobody Is Asking
The market is repricing the people and work around AI. AI work becomes strategic, well-funded, and career-enhancing. Maintenance becomes less attractive. AppSec becomes significantly more necessary but almost always less resourced. QA becomes theoretically more important but operationally easier to compress.
The question is no longer “Are we funding AI?” Everyone is funding AI.
The question is: what are we underfunding in order to fund it?
Are maintenance teams losing senior people? Are QA teams validating more AI-generated changes with fewer people? Are AppSec teams stretched across more repositories, agents, APIs, and exception paths? Are patching SLAs slipping? Are AI productivity assumptions banked as savings before anyone has proved the quality holds, and the security model still works?
The right answer is not to slow AI adoption for its own sake. AI is real, useful, and in some places genuinely transformational. The right answer is organisational and operational discipline.
Ring-fence maintenance, or outsource it properly. Ring-fence AppSec. Protect QA where the risk warrants it. Treat internal transfers as governance events. Make the budget language do the work: name what is being deprioritised, which controls are being preserved, and what assumptions are being made about automation.
The companies that win with AI will use it to eliminate genuine toil without hollowing out the essential, boring engineering disciplines that keep systems safe, maintained, recoverable, and compliant. The ones that lose will treat AI as a convenient budget-reduction story. Cut people from maintenance, stretch security thinner, compress QA, and assume the machines will notice what humans no longer have time to check.
That is just unmanaged risk with a cool name.
And there are people and machines actively waiting to exploit it.
AI Changes the Attacker Economics Too
I have been talking about software supply chain security since around 2014. For a long time, it felt like shouting into the wind. Then things improved: SBOMs became a serious topic of conversation, dependency scanning became normal, and signing and provenance moved from specialist concerns to mainstream platform thinking.
That progress is real. AI is now stress-testing it from two directions at once.
Attackers get better automation. Defenders get more surface area. Developers get faster generation. Reviewers get more to review.
AI does not need to invent new attack patterns to make supply chains worse. Dependency confusion and typosquatting already existed. But AI makes the economics nastier. It generates package names, README files, fake usage examples, plausible changelogs, issue comments, and pull requests at scale. It helps attackers mimic the tone and shape of legitimate open-source activity. It produces variants faster than a human reviewer can build confidence.
Sonatype identified over 454,000 new malicious packages across npm, PyPI, Maven Central, NuGet, and Hugging Face throughout 2025, bringing its cumulative known-and-blocked malware count above 1.2 million packages.
Unit 42 showed that LLM-assisted rewriting of existing malicious JavaScript produces variants harder for classifiers to detect — mutating malware past signature-based defences rather than generating it from scratch.
When the Queue Breaks
Traditional scanners struggle because they are designed to recognise what they have already seen. A newly published package with plausible metadata and slightly different code often defeats them. Behavioural analysis, provenance, maintainer identity, and human review all become more important precisely when human review is overwhelmed.
When queues get too long, people cut corners. They rubber-stamp reviews. They lower the bar. They approve exceptions. They rely on the tool because the tool is faster than the human process. They stop reading every diff. They trust the generated tests. They defer the threat model. They accept the dependency because the build is green.
That is exactly what offensive supply-chain attackers want. They do not need every malicious package to work. They need volume, plausibility, and enough exhausted humans to let one thing through.
The defender has to be right repeatedly. The attacker needs one successful package, one stolen token, one confused namespace, and one AI-assisted PR that nobody quite had time to unpack.
The external threat is real. But the more fundamental problem is internal. A broken piece of maths that makes the trade-offs look better than they are, and lets organisations keep burning the ship without realising how much they have already lost.
Part Two, The Denominator Problem, coming next