AI made code cheap. It did not make correctness cheap

Software engineering is a judgement profession that happens to produce code. For about forty years the code was the expensive part, so the judgement travelled with it and nobody had to separate them. Generative models separated them.

That is the whole story, and the rest is consequence. Producing code is a language task, and models are genuinely good at language tasks. Deciding whether a piece of code is correct for this business, in this system, against these constraints, is a judgement task needing context the model does not have. The cost of the first collapsed. The cost of the second did not move.

So the interesting question is not whether engineers are being replaced. It is where the value went, and what you need to be able to do to stand where it landed.

Is software engineering being replaced?#

No, but one rung of it is genuinely disappearing. Stanford's Digital Economy Lab, working from payroll records covering 4.6 million workers, found developers aged 22 to 25 lost close to 20 per cent of their jobs after late 2022, while developers over 26 held steady or grew. Entry-level roles are now 4.5 per cent of software development postings. The pessimists are measuring something real.

It is worth being precise about which work vanished, because the pattern is informative. The tasks that went are the ones with a well-specified input and a conventional output: boilerplate, scaffolding, a CRUD endpoint, a simple bug fix, a transformation with clear rules. Those are language tasks in disguise. A model does them well because the answer is largely determined by the question.

The age split in the Stanford data is the part worth sitting with. The work did not thin out evenly across the profession. It thinned out under the youngest people in it, which is the exact rung people used to climb. The traditional route to senior was to ship a hundred small safe things and absorb, from the feedback, what makes a thing safe. Removing the small safe things does not remove the need for the learning. It removes the ladder.

Anyone telling junior engineers this is a wonderful moment to be starting out is not being straight with them. It is a harder entry than it was three years ago, and pretending otherwise helps nobody.

Where did the demand actually go?#

It moved rather than vanished. Software development postings are rising again, but 71 per cent of the increase between May 2025 and May 2026 came from senior roles, and 37 per cent came from jobs naming AI in the title. Gartner has predicted 80 per cent of software engineering organisations will run platform teams by 2026, against 45 per cent in 2022.

Look at what those categories have in common. None of them is about producing more code. AI and ML work is about judging model behaviour. Platform work is about making a large volume of change safe to release. Both are the judgement half of the profession, separated out and hired for directly.

The market has not reduced its demand for engineering. It has repriced it, and it is paying for a different part.

Why does AI multiply output faster than correctness?#

Because output is a language problem and correctness is a context problem. Google's 2025 DORA research, drawing on roughly 5,000 technology professionals, measured the effect of AI adoption across ten outcomes. Its effect on delivery instability came out around three times its effect on throughput.

That comparison is easy to skim past, so it is worth stating plainly. DORA estimated a standardised effect of about +0.10 on software delivery instability, which the report explicitly marks as an undesirable direction, against roughly +0.03 on software delivery throughput. AI destabilised delivery considerably more than it accelerated it.

Three independent sources point the same way.

The ratio is the thing to hold onto. Apiiro, measuring its own deployments across Fortune 50 enterprises between December 2024 and June 2025, found AI-assisted developers committing code at three to four times the rate of their non-AI peers. Over the same six months their monthly security findings rose from around 1,000 to more than 10,000, a tenfold increase. Output roughly quadrupled. Defects rose by an order of magnitude. The gap between those two numbers is not noise, and it is not going to be prompted away.

The defects are not exotic ones. Veracode has evaluated more than 150 large language models on security-sensitive tasks and found that in 45 per cent of cases the model introduced a known security flaw. Cross-site scripting scored a 15 per cent pass rate, so 85 per cent of attempts failed to defend against it. Java was the worst-performing language at a 29 per cent pass rate.

The consequences are measurable in the open. Georgia Tech's Systems Software and Security Lab runs a Vibe Security Radar project tracking vulnerabilities traceable to AI-generated code. New CVE entries attributed to it ran 6 in January 2026, 15 in February and 35 in March.

DORA's own summary is the sentence worth keeping: AI is an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones. The report goes further and says the greatest returns come not from the tools but from investing in the foundational systems around them.

What is actually going wrong?#

Credentials, mostly, in a pattern that shows where the risk has moved. GitGuardian recorded 28.65 million new hardcoded secrets added to public GitHub commits during 2025, a 34 per cent rise year on year and the largest single-year jump it has measured.

The composition matters more than the total. Secrets tied to AI services reached 1,275,105, up 81 per cent year on year against an overall rise of 34 per cent. Eight of the ten fastest-growing detector categories were tied to AI services. Model Context Protocol configuration files alone exposed 24,008 unique secrets across public GitHub in that format's first year of existence.

Then the detail that should reorganise how you think about the problem. Of the machines compromised through leaked credentials, 59 per cent were CI/CD runners rather than personal workstations.

The failure surface moved into the pipeline.

None of this is an argument that people without an engineering background should not build software. They should, and the tools that let them are a genuine good. It is an argument about one specific limit, and the limit is structural rather than a matter of talent or care.

You cannot review what you cannot read. A hardcoded key, an injection flaw and perfectly good code all look identical from the outside. They produce the same demo. The application works. The difference between them is visible only to someone who can read the diff, and no amount of enthusiasm substitutes for that. It is the same reason you can admire a bridge without being able to tell whether it will hold.

What is a product engineer?#

A product engineer is an engineer who owns an outcome rather than a ticket. The distinction is not seniority and it is not a job title. It is whether you are accountable for whether the thing was worth building, or only for whether it was built to specification.

The distinction is well established: a software engineer traces the bug through the call stack, a product engineer asks first whether that bug matters more than the three other things competing for the week. Same skills, different question at the front.

This is the role that gains most from cheap code, for a mechanical reason. When implementation was expensive, the constraint on a team was how much it could build, so the valuable person was whoever built fastest. When implementation is cheap, the constraint becomes knowing what to build, and the valuable person is whoever can tell a good idea from a plausible one before three weeks go into it.

An agent will build the wrong feature beautifully. It has no stake in whether the feature should exist.

Does speaking business language mean talking to executives?#

No, and treating it as a presentation skill is why that advice usually lands as hollow. It means being able to tell whether an output is right, which requires knowing what right means in this business. That is a technical requirement rather than a social one.

Here is the concrete version. Ask an agent for active customers by month and it will produce something clean and plausible. Whether it is correct depends on what your organisation counts as a customer: whether someone who bought once still counts, whether trial and test accounts are included, whether deleted accounts are excluded, whether it is one person or one account. Get one of those wrong and the query still runs, the chart still renders and the number is wrong in a way that survives review because it looks entirely reasonable.

No amount of prompting fixes that, because the model is reasoning from your instructions rather than from your business. The only defence is a person who knows the domain well enough to look at a plausible number and say that it is wrong.

That is what business fluency is for. Not persuading a room. Detecting a wrong answer that looks right.

Why do platform and DevOps engineers become more valuable?#

Because when AI raises the volume of change, the systems that make change safe become the binding constraint. DORA's AI Capabilities Model identifies seven capabilities determining whether AI adoption helps or hurts an organisation, and three of them are delivery engineering: quality internal platforms, strong version control practices and working in small batches.

That finding deserves sitting with. Google did not set out to make a case for platform engineering. It measured which organisational conditions predicted whether AI made things better or worse, and delivery capability came out as most of the answer. A fourth capability on the list is a user-centric focus, which is the product engineering argument arriving from the same research.

The mechanism is not complicated. An agent can generate a week of changes in an afternoon. Whether that is an asset or an incident depends entirely on what sits between the change and production: whether the tests are real, whether version control makes reversing a decision cheap, whether a secret can reach a repository at all, whether the pipeline can tell a working change from a plausible one.

That work has a name and it is platform engineering, and DORA puts it among the seven conditions that decide whether AI helps you or hurts you.

The role does change shape. The current version of the job is less about running the pipeline and more about governing what is allowed to run through it, including agents. Mature platforms are beginning to treat an agent as a user persona like any other, with its own permissions, quotas and policies. That is a design problem, and it needs someone who thinks about blast radius for a living.

Are these two different careers?#

They are two ends of one problem. Correctness has two halves: knowing what the right thing is, and making the wrong thing hard to ship. The product engineer supplies the first. The platform engineer supplies the second. Neither is sufficient alone.

A team with excellent product judgement and no guardrails builds the right thing and breaks it on the way out. A team with excellent guardrails and no product judgement ships the wrong thing reliably, on time, with full test coverage.

What both roles share is that they are paid for judgement rather than for production, which is exactly the half of the profession generative models did not touch.

What if you are two years in?#

The honest answer is that the ladder is harder, and the first rung is missing rather than lowered. You will not become senior by shipping the volume of small tasks a previous generation used, because that work is now generated. The judgement has to be acquired another way.

The good news is narrower than the usual encouragement, and it is real. Reviewing code teaches the same lessons as writing it, and there has never been more code needing review. The engineer who can look at a generated pull request and say precisely why the change will scan the whole table, or where the secret is going to end up, is doing senior work directly rather than waiting to earn access to it.

That is an unusually fast path, and it is open now in a way it was not when a junior had to wait for someone to hand over a real problem.

What would you do on Monday?#

Six things, in the order I would do them.

1. Learn to read a diff better than you write one. Correctness review is the scarce skill. Volume of production is not.
2. Learn what your organisation actually means by its own words. Take one number leadership looks at weekly and trace it to the source. Most businesses have at least one definition that is quietly wrong, and finding it is the fastest respect you will earn.
3. Own an outcome, not a ticket. Ask what happens if the thing you are building works. If nobody can answer, that is the finding.
4. Learn the delivery half. Version control properly, small batches, what your pipeline does and does not check. Three of DORA's seven capabilities live here, and most engineers treat all three as somebody else's job.
5. Go and find where secrets live in your own environment. Given eight of the ten fastest-growing leaked secret types are AI services, this is a good week for it.
6. Use the tools heavily, and never merge what you cannot explain. That rule survives contact with deadline pressure, which is the only test of a rule that matters.

None of this is a defence of the profession. It is a description of where the profession went. The work disappearing is the work that was always closest to typing, and the work appreciating is the work that was always closest to thinking. For anyone who got into this because the thinking was the interesting part, that is a good trade.

If you are working through the same shift, there is more under AI-augmented operations and engineering leadership. I am always interested in comparing notes, so get in touch.