What AI Changes About Software Engineering Careers

The headline claim is that AI writes code, so fewer engineers will be needed. The measured evidence does not support it. What the evidence does show is stranger, more specific, and more useful if you are making decisions about a team or a career.

AI’s effect on engineering work is not uniform. It is steeply dependent on what kind of work is being done, and the gradient runs in exactly the opposite direction to how most engineering organisations are structured.

Two findings matter, and each is misleading on its own.

Research cited in Google Cloud’s DORA work puts productivity gains at roughly 35 to 40 percent on simple greenfield tasks, and often 10 percent or less on complex legacy code. Real gains, concentrated at one end of the difficulty range.

A randomized controlled trial by METR pushed further. Sixteen experienced open source developers worked 246 tasks in repositories they already knew well. With AI tools available, they took about 19 percent longer. Afterwards, they estimated AI had made them about 20 percent faster. The gap between measurement and perception was about 39 percentage points.

That study deserves its caveats: small sample, one kind of work, models that have since moved on. It is not evidence that AI assistance fails. But it is the most rigorous measurement available, and the slowdown appeared precisely where expertise was deepest and the codebase most familiar.

Put the two together and the pattern is clear. AI helps most with work that is new, simple and unfamiliar to whoever is doing it. It helps least, and sometimes hurts, with work that is complex, existing and already well understood.

The Band That Compressed Was the Training Ground

The work AI compresses most efficiently closely resembles the work junior engineers were historically given. Bounded, well specified, self-contained, low-context. Build the endpoint. Write the parser. Add the tests for this module.

Those tasks were never only about output. They were the mechanism by which people acquired judgment: do a bounded thing, have it reviewed, learn why the review said what it said.

When that band compresses, output gets cheaper and the apprenticeship route narrows. This is a structural problem, not an individual one. It is also entirely solvable, but only by organisations that notice it is happening and replace the mechanism deliberately rather than letting it erode by default.

DORA’s 2026 work on returns from AI-assisted development describes a temporary productivity dip that adopting organisations should expect. It attributes that dip partly to the verification burden of reviewing AI-generated code, alongside the learning curve and the need to adapt testing and change approval. It calls this the tuition cost of the transition.

That burden does not go away afterwards. It relocates permanently.

Reviewing code is a different skill from writing it. Reviewing code nobody wrote is different again. There is no author to ask what they intended. The output is fluent, idiomatic and plausible, which makes review harder rather than easier, because fluency suppresses the instinct that unfamiliar code normally triggers. And the volume arriving for review rises precisely because generation got cheap.

Every engineer has met a diff that looked right and was not. That detection skill is now the scarce part of the job, and almost nobody was trained in it deliberately.

DORA’s 2025 survey recorded adoption among software professionals rising to around 90 percent from 76 percent the year before, with over 80 percent reporting productivity gains.

Over the same period, trust in AI output fell. The share reporting trust at somewhat or above dropped to roughly 70 percent, from nearly 88 percent.

More use, less confidence. That combination describes the actual working conditions now: high volume output from a source you have consciously decided not to fully trust. Managing that is a skill in its own right, and it is not the same skill as writing software.

The same research found AI acting as an amplifier. It magnifies the strengths of organisations with strong version control discipline, small batches, good internal platforms and solid testing. It magnifies the dysfunctions of organisations without them.

We build blockchain systems, so treat this section as the one written against our own interest.

If your review capacity is already the constraint, that is an argument against adding immutable infrastructure, not for it. The amplifier finding applies to architecture decisions, not just process ones.

Smart contracts are the worst available place to ship fast and fix later. A deployed contract bug is expensive, public, and sometimes not fixable at all. A team generating more code than it can carefully review should not be putting that code behind an upgrade path it cannot reverse. The honest sequencing is to fix review capacity first, then consider what belongs on a ledger, and for a great many requirements a conventional database with signed audit logging is sufficient and considerably cheaper to operate.

Where a ledger genuinely is right, the same logic tightens rather than relaxes. Compliance rules belong in deterministic code that can be tested exhaustively, not inferred by a model: investor eligibility and transfer restrictions enforced at transfer time under something like ERC-3643, with KYC and AML checks wired into identity. Keys stay scoped, under threshold approval, in hardware. Contract logic goes through independent audit before it holds anything of value, with time budgeted to fix what the audit finds rather than to acknowledge it.

None of that is faster. All of it is cheaper than the alternative.

What This Changes About Hiring and Scoping

Cutting junior hiring because output got cheaper is the move DORA’s research explicitly cautions against; its guidance emphasises process redesign and retaining staff over headcount reduction. The cost of that decision does not show up in year one. It shows up when you need senior engineers you never grew.

Interviewing needs rethinking rather than defending. Asking a candidate to produce a function from a prompt tests the thing that got cheap. Handing them a fluent, plausible, subtly broken change and asking what is wrong with it tests the thing that got scarce.

And scoping matters more than it used to, not less. A vague specification used to produce a stalled ticket and a clarifying question. It now produces a large volume of confidently wrong code that looks finished. The cost of ambiguity went up, which is an argument for doing the unglamorous definition work before anyone starts generating.

If generation is the cheap part, the durable assets are everything around it: the specification, the tests, the evaluation criteria, the review discipline, the deterministic controls, the keys.

Those artefacts are the system. Keep them. If they live with a vendor, your ability to change tools, change providers, or prove what your controls actually do leaves when they do.

One last thing, aimed at individuals rather than organisations. The clearest finding in this literature is not that AI slows people down. It is that capable people were confidently wrong about their own speed, in the direction that felt good. Whatever you conclude about your own productivity, measure something.

RWaltz is a technology partner building blockchain, AI, and enterprise software, including smart contracts, tokenization platforms, and custom integrations. Our approach is security first and build to own: honest scoping, independent audits, and client owned IP and keys, so what we deliver belongs to you.

📖 Read the full blog: https://www.rwaltz.com/blogs/what-ai-changes-about-software-engineering-careers

LinkedIn: https://www.linkedin.com/company/rwaltzsoftware X (Twitter): https://twitter.com/rwaltzsoftware Facebook: https://www.facebook.com/RWaltz-Software-PvtLtd-255590135349493 Telegram: https://t.me/RWaltzCrypto GitHub: https://github.com/rwaltzsoftware Clutch: https://clutch.co/profile/rwaltz-software Website: https://www.rwaltz.com