Predictions about AI in software development have a poor track record, mostly because they focus on the wrong variable. The interesting question was never how capable the models would become — they became very capable — but which parts of building software the capability would actually absorb.
Two years of evidence in, the answer is clearer and stranger than the predictions were. Some of the work collapsed almost entirely. Some of it barely moved. And a category of work appeared that did not previously exist.
What actually collapsed
The tasks that compressed hardest share a property: a clear specification, a verifiable result, and a bounded scope.
- Writing the second version of something. Given an existing pattern in a codebase, producing the next instance of it is close to solved.
- Translation work. Between languages, frameworks and API versions. The rules are mechanical and the result is testable.
- Test authoring. Particularly the tedious cases people skip — boundary conditions, error paths, fixtures.
- Comprehension of unfamiliar code. The hours spent understanding what an inherited module does before you can safely change it.
- Well-specified bug fixes. Given a reproduction and a failing test, the fix is increasingly routine — the basis of the agent pipeline we describe in 500 hours of engineering, done in 10.
The published figures are substantial where teams have built the surrounding infrastructure — Spotify's internal coding agent has produced over 1,500 merged pull requests at a claimed 60–90% time saving against writing the code by hand. Around 86% of organisations now report using coding agents against production code.
What barely moved
The complement is just as consistent. Work resisted compression where the difficulty was never in the typing.
- Deciding what to build. Requirements work is a negotiation between people who want incompatible things and have not said so out loud. No model resolves that, because the information does not exist yet in any form a model could read.
- Architecture under real constraints. Not "what is a good architecture" — that is answerable — but "what is right given our team, our existing systems, our budget and the three commitments we already made."
- Debugging genuinely novel failures. The bug that only manifests under production load, across a service boundary, on the last day of the month. This is hypothesis-driven investigation against a system nobody fully holds in their head.
- Everything organisational. Alignment, sequencing, deciding what not to do, knowing which stakeholder's objection is real. This has always been most of a senior engineer's job and it is untouched.
The tasks that compressed were the ones where the hard part was already finished before anyone started typing.
The work that appeared
Less discussed, and increasingly the larger story: a category of engineering that did not previously exist.
Building systems with a probabilistic component turns out to require its own discipline. Evaluation harnesses — because you cannot tell an improvement from a regression by looking. Retrieval and context pipelines — because what the model sees determines most of the output quality. Guardrails and abstention design — because the behaviour when uncertain matters more than the behaviour when confident. Cost instrumentation — because spend scales with usage in a way conventional infrastructure does not. Trace and audit infrastructure — because a non-deterministic run cannot be reproduced after the fact.
None of this existed as a specialism three years ago. All of it is now the difference between a system that survives production and one that does not — which is the subject of why 88% of AI pilots never ship.
What this means for a development team
- Verification became the bottleneck. When producing a change is cheap and reviewing it is not, review capacity governs throughput. Teams that adopted agents without strengthening review simply moved the queue.
- Code review is now a first-class investment. Automated review, stronger test suites and clearer conventions pay more than they used to, because more code is arriving.
- Codebase legibility compounds. Clear structure and consistent conventions help models for the same reason they help new hires. Messy codebases got relatively harder to work in, not easier.
- Junior work changed shape. The tasks juniors traditionally learned on are the ones that compressed. Teams that have not deliberately redesigned how people gain experience are accumulating a problem that surfaces in a few years.
- Irreversible actions still need a human. Merging, deploying, anything with a blast radius. This has held everywhere it has been tested.
The reasonable expectation
The plausible near-term future is not autonomous software development. It is a larger share of implementation produced by agents, reviewed by people, inside pipelines that make the review tractable — with humans concentrated on specification, architecture, judgement and the decision about what should exist at all.
That is a significant change to how software gets built and a modest one to what software engineering fundamentally is. The scarce skill is still knowing what to build and recognising when it is wrong.
We build custom software with agent pipelines where they help and people where they matter. Start a project with us.
