Progress and Resistance in AI-driven Software Development

The most determined resistance to AI coding tools isn’t coming from where you’d expect.

It isn’t the veterans who’ve watched three previous “this changes everything” cycles arrive and recede. They’ve usually seen enough to know when something is different. It isn’t junior engineers either; most of them are happily using these tools as a matter of course.

The resistance is concentrated in the middle. Engineers with five to fifteen years of experience. Comfortable, fast, productive in their craft. They’ve tried the tools, sometimes once, often longer ago than they care to admit, and concluded that it’s quicker to do it themselves.

Twelve months ago, they were probably right. Today, they aren’t. And the gap is widening at a rate that should worry anyone planning their career in this profession.

The speed argument is stale

When I press on the “faster to do it myself” objection, the same pattern emerges almost every time. The engineer tried an early version of an IDE plug-in, found the suggestions noisy or wrong, and decided the tool wasn’t worth the friction. They haven’t seriously revisited it since. Some haven’t revisited it for a year, which in this field is a geological era.

Models that were merely impressive in early 2025 are now in a different category. The technique has changed even more than the models. An engineer evaluating today’s tools using last year’s approach is going to come away unimpressed, and they’ll be wrong for entirely understandable reasons.

From prompts to specifications

The shift that’s done the most to change what’s possible is the move from prompting an LLM to write a function, to writing a specification with proper acceptance criteria and letting the model run in a loop. Plan, build, test, fix, iterate. The engineer becomes the architect and the reviewer, not the typist.

This is the move that an engineer who’s only ever used autocomplete will completely miss. It looks superficially similar but operates on a different scale. I’ve written about the practical mechanics of this approach elsewhere; the headline point is that the work shifts upstream into specifications, architecture and verification, and the model handles the rest.

It is, incidentally, a much more enjoyable way to build software.

Orchestration moves in-house

At the start of the year, everyone was talking about orchestration. I spent a fair amount of time experimenting with third-party approaches like the BMAD method and Ralph-style loops, stitching together harnesses that let models plan, delegate and self-correct over long tasks.

The interesting development of the last few months is that Anthropic and others have been quietly building those capabilities directly into their tooling. The same vendors have also been adjusting subscription terms in ways that limit what some third-party harnesses can do on top of their APIs. The orchestration question, in other words, is solving itself. The capability is moving from clever community workarounds into the platforms themselves.

Combined with the “set a goal and let it work” approach, this is producing materially better outcomes than anything we had at the start of the year.

Six months, one simulator

A small ritual of mine: every time a notable coding model is released, I use it to build an air traffic simulator. Same brief, same yardstick, run after run. The progression has been the most concrete evidence I have for how fast this is moving.

In January, with the leading model of the day, I spent a few hours iterating. Prompting it, helping it solve problems, debugging on its behalf, nudging it through the bits it got stuck on. The result was respectable.

With Opus 4.X, the shape of the work changed. I spent a couple of hours writing a detailed specification covering how aircraft should behave, when and where they should climb, descend, turn, accelerate. I handed the spec to the model and told it to build the lot, then spent a few hours debugging what it produced. Less hand-holding, much better output.

With Fable 5 (now disabled, at the request of the US Government), the shape changed again. I gave it a one-paragraph, high-level description. It produced a detailed specification of its own, passed that to a fresh context for implementation, then ran autonomously for several hours. It tested the code in a browser, varied the inputs, observed the outputs, fixed bugs as it went. At the end of it, I had a version with no bugs I could find. It worked flawlessly.

Same brief. Three orders of magnitude less of my involvement. Better result.

That’s not an extrapolation or a vendor pitch. That’s what I observed in my own office.

The non-engineers are catching up

The other thing worth noting is who’s building software now. I’m seeing an increasing number of cases where people without an engineering background are producing genuinely sophisticated systems. There are still plenty of good reasons a seasoned professional gets better outcomes; judgement, architecture, knowing what good looks like, knowing what to test for. But those reasons are diminishing fast, and the gap is closing from both directions: the tools are getting better, and non-engineers are getting better at directing them.

This isn’t a story about replacement. It’s a story about the floor rising.

What this means

If the rate of progress from the last six months holds for another six, the engineers refusing to engage with these tools will be in serious trouble by the end of 2026. Not “they’ll need to upskill” trouble. Genuinely redundant trouble. A team that used to need ten engineers will be delivering more with three; the question of which three becomes brutally simple.

This isn’t a prediction made in anger or to provoke. It’s the trajectory I’m watching, on real projects, with real teams.

The remedy is unromantic. Open the most current version of a serious tool. Give it a non-trivial task, the sort of thing you’d normally do yourself in an afternoon. Write a proper specification rather than prompting line by line. Let it run. Pay attention to what surprised you.

Then do it again next month, because the gap between what you remember and what’s now possible will surprise you again.

Resistance is understandable. It just isn’t survivable.

If you’d like a more structured walkthrough of where this technology actually is and what to do about it, the AI coding series covers the economics, the risks and the role-specific actions for both executives and engineers. The Best First AI Project is a good place to start if you’re looking for a low-stakes way in.