AI didn't start the fire
Imagine joining a team retrospective. PRs wait open for days. Deployments are too slow to keep up with the changes. Production incidents are waking people up more often than anyone wants to admit. And, on top of all that, there’s pressure to move even faster…
It sounds like a typical team in 2026, but actually it gives me déjà vu. I heard similar complaints 10 years ago. And even then, they were not new. That fire was already burning.
There’s no denying that AI has changed programming for good. Coding has become cheap, prototyping has never been easier, and most folks at least feel more productive. Yet, despite all its greatness, AI has left many teams producing more than they can digest (review, verify, or even read). Some of my colleagues say that they now have more work than before!
Brave new world?
Old sins in new costumes
AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.
AI can give us superpowers. At the same time, every inefficiency of our teams, processes, projects, and organisations that was never about writing the code has now become a bottleneck. Or, I should say: a more visible bottleneck than before. AI only removed the cover.
There’s an old idea that explains this well. Goldratt’s theory of constraints says that a system moves at the speed of its bottleneck, and speeding up anything else just piles up inventory in front of it. AI optimised the coding part, which for most teams was never the only constraint. That’s why the inventory piles up elsewhere now: open PRs, undeployed or unverified changes, and, eventually, incidents.
Let’s take the long-waiting PRs as an example. Booking mandatory “code review time” first thing in the morning has been tried for as long as PRs have existed, and it was only partially helpful. Too many contributors, too many open items at once, or code changes that were too big would eventually fill up that time as well. And merging was rarely the end of the story. With infrequent deployments, changes piled up waiting for the next release, making each of them a risky leap of faith.
Before AI, we would make teams smaller, limit work in progress (Kanban style), split our PRs into smaller changes, and deploy more often. Some teams went further and dropped PR reviews altogether. But the ones that succeeded didn’t really remove the review. They moved it closer to writing the code, into pair or mob programming.
And now, AI comes into the picture. The number of (virtual) contributors increases, even though the team size stays the same. We’re multitasking more than before because it’s allegedly “cheap”, and we stop splitting big changes because our PR queue is already too long… It feels like we can no longer recognise the well-known sins of the past in their new costumes.
The same goes for tests. AI makes writing them easier, but what I see most often is AI repeating the testing patterns that already exist. If those patterns aimed at coverage rather than confidence, we now get more of them, faster. The codebase looks better tested than ever, while our confidence in it stays low. Confidence was never about the amount of test code. It’s about trusting a green pipeline enough to click “Merge”.
Things have changed
That doesn’t mean there are no new challenges. The pace of writing code used to act as a natural brake for the rest of our work pipeline. The coding part got superfast, but the rest did not. Even if not all of the problems are new, we’re now dealing with them at an unprecedented scale.
What’s worse, some of the quality signals we relied on no longer work the same. Clean code, green tests, a detailed description or a good-looking design document no longer act as a sign of the author’s craftsmanship or as evidence of the thinking process. It can be impossible to tell if someone genuinely investigated the issue, or just happily accepted what AI proposed and moved on. Most terrifying of all, a change can now reach production without anyone really understanding it.
And of course, there’s plenty to learn too. Most of us are still figuring out how to work with AI agents effectively: how to give them the right context, when to trust them, and how to verify what they produce. The way we work is changing so fast that keeping up with everything feels almost impossible. And this revolution seems to be far from over…
AI-native isn’t a tooling question
“The issue is the legacy SDLC”, some say, “you must become AI-native”. But what does that actually mean, especially without the sell-me-the-tool part? The more radical folks remove the human from the loop, as humans are the main synchronisation point. Drop code reviews for most changes, let another agent review the code, push it to production, and roll back if yet another agent notices a regression…
Such an approach could work, but only under a few assumptions. We need solid automated testing that gives us enough confidence to merge when everything is green. We need a pipeline that deploys every change quickly and verifies whether it should stay or be reverted. And, most importantly, we need to be sure that what we’re building is exactly what we need.
None of these “features” is new, or “AI-native”. Most of the teams I’ve observed didn’t hit 100% on that checklist even before they adopted AI. One could argue that AI makes them cheaper to reach. Well, maybe. But can AI-written verification be trusted to verify AI-written code, especially when it copies the same poor patterns?
And then there’s accountability. AI can’t be truly accountable for its decisions. In highly regulated environments (SOX compliance, finance, medical) that’s a hard requirement. Can some teams safely take the human out of most of the loop? My honest answer is: I don’t know yet. But I’m fairly sure it’s not a tooling question. Just like with autonomous cars, someone needs to be accountable for a crash.
Knowing what to build is still the hard part
Yes, AI made prototyping a breeze. Online ads claim that everyone can vibe code a “product” in minutes without any engineering support. But that technical person in the chain was never only about writing the code. Business requirements are rarely precise enough to avoid drifting from the initial idea or introducing unexpected consequences, especially as the system gets bigger and older.
Shouldn’t we then just try harder to define all our requirements up front? We tried that as an industry before. Does anyone still remember the Rational Unified Process (RUP)? Its focus on documenting requirements and architecture before introducing changes bears a striking resemblance to the recently rediscovered Spec-Driven Development. Back then, such a formalised approach turned out to be too heavy.
Today, AI can produce long documentation in seconds (and then summarise it for us, because it’s too long to read). Unfortunately, the human brain is still not scalable when it comes to digesting documentation, and it’s almost impossible to avoid inconsistencies and gaps there. And the bigger the system, the more documentation it needs.
In “AI-native” environments, those gaps multiply. An implicit assumption made by one agent, which other agents immediately build upon, can easily become a foundation of the system that’s really hard to get rid of. AI models are true wonders, but as far as I know, they still don’t read our minds.
AI won’t fix the organisation
The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams.
That part of the DORA 2025 report sounds extremely familiar. When I join a new team and look into why PRs pile up, I usually find three related reasons.
First, people don’t trust their tests enough. Green pipelines should let reviewers approve a change with confidence, but when tests aren’t trusted, the reviewer becomes the real quality gate.
Second, when quality gates don’t give enough confidence, approving a change means taking responsibility for someone else’s risk. People are afraid to break things, so they get super cautious. That’s often also a sign of not having enough domain understanding.
Finally, when the pipeline is too slow, we end up rebasing and re-reviewing our changes again and again before they can finally be merged. Every round adds more work to the same queue.
None of this is a discipline problem. It’s a rational response to a weak safety net. These issues can be addressed by making verification trustworthy, mistakes cheaper, and feedback faster. I know, this may sound like decade-old advice. What has changed is the cost of ignoring it. A weak safety net used to mean slower delivery and higher risk. With AI-level throughput, it means a queue that never drains and changes that ship without any real verification.
Organisations with tests they actually trust and the ability to roll back quickly have much lower risk aversion. In such environments, the AI-increased pace of changes can be embraced. In the ones I’ve described, it is the end of the world.
An organisation that doesn’t trust developers won’t trust AI either. Extensive gatekeeping, processes followed for their own sake, and bureaucracy can kill every sign of efficiency. And you can’t gatekeep ten times the output. Just as buying a task-management system with “sprints” doesn’t make you agile, surrounding yourself with AI tools won’t make you “AI-native”. The much-needed culture and mindset change has become far more urgent than it was a year or two ago.
A new dawn for craftsmanship
Software craftsmanship is not dead, but it has to adapt. The author’s name on a change used to work like a quality trademark. AI has blurred that signal, but I believe we can still restore it. Instead of “I wrote this”, it should now mean “I understand this and I stand behind it”.
Luckily, that doesn’t mean doing everything by hand. As Gregor Hohpe put it, borrowing a line from Agent Smith in The Matrix, we should “never send a human to do a machine’s job”. Routine, low-risk changes can be offloaded to our new artificial friends. Risky, substantial changes or those setting the direction still deserve human attention.
Since coding is no longer a natural brake, we have to apply the brake ourselves. The modern craftsman knows when it’s worth slowing down.
Technical excellence is becoming the deciding factor between teams that move fast with AI and teams buried under AI-generated artefacts, unable to explain why AI has made them slower. Small but frequent changes, fast feedback loops, reliable tests, and stable pipelines are what turn AI’s speed into a real productivity boost.
The lessons of the past
In 1972 (!), Edsger Dijkstra described the software crisis of his time this way:
As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming had become an equally gigantic problem. (…)
So much for the past. But there is no point in making mistakes unless thereafter we are able to learn from them.
~ Edsger W. Dijkstra, The Humble Programmer
As an industry, we’ve spent decades fighting this fire, one software crisis after another. This time, it may be spreading faster than ever, and we’ll need new tools to contain it. But that’s no reason to forget what we’ve learned along the way. Many of today’s problems are ones we’ve faced before, just at a different scale.
Isn’t scaling solutions engineering’s bread and butter?