The Bottleneck Is No Longer Writing Code

Cheaper, Faster, or Better… You can’t have all three dials set to 11. Or can we scratch in a 12 on the dial?

For most of modern software engineering, writing code was the expensive part. That reality shaped almost everything about how engineering organisations evolved over the last twenty years. Teams were built around delivery throughput, development tooling focused on implementation speed, and entire engineering cultures formed around reducing the friction involved in turning ideas into working software.

AI coding assistants are changing that equation far faster than I think many organisations are prepared for.

The more time I spend working with AI-assisted development, both professionally and on personal projects, the more convinced I become that we are entering a world where generating code is no longer the primary challenge in software engineering. Understanding the systems is.

I have seen both sides of this already. I have seen systems built by incredibly capable business SMEs that absolutely solved the immediate business problem, but collapsed the moment scale, maintainability, or operational complexity entered the picture. At the same time, I have watched modern AI coding assistants struggle their way through mature enterprise systems that were genuinely well engineered simply because the codebase itself was too large and too interconnected for the tooling to reason about effectively.

At some point, when we finally reach AGI and it can explain its experiences to us, we may genuinely have to apologise for all the context anxiety we inflicted on it.

The Economics of Software Engineering Have Changed

One of the most important things AI coding assistants change is the economics of implementation effort. Entire features can now be scaffolded in minutes. Boilerplate has become almost disposable. Patterns that once took hours to carefully replicate can now be generated in seconds.

That acceleration is real, and honestly, when it works well, it feels incredible. There are moments where working with modern AI tooling genuinely feels like the Tony Stark and Jarvis dynamic from Iron Man. You explain the intent, give it direction, and it starts building alongside you while you move on to solving the next problem. The engineer becomes less of a typist and more of an orchestrator, architect, reviewer, and problem solver. Which even allows them to get back to being an engineer, a bit like Stark in the Iron Man movie with the kid when he has no Jarvis!

But there is another side to that experience too.

Sometimes the AI gets stuck in loops, repeatedly misunderstanding the same problem regardless of how carefully you prompt it. Sometimes it produces structurally correct code that completely misses the operational nuance of the requirements. Sometimes the delivery becomes so quick that the human engineer no longer feels like they are building software at all. They become a reviewer waiting for pull requests to appear rather than someone actively creating.

And shockingly (well not really), some engineers already miss being coders.

That emotional aspect matters more than many organisations realise. Software engineering has never purely been about throughput. Engineers enjoy building things. They enjoy solving problems, refining systems, debugging difficult behaviour, and slowly improving designs through iteration. If AI adoption turns engineers into passive approvers instead of active thinkers, we risk losing something genuinely valuable about our profession.

The bigger shift though is not emotional. It is structural.

The scarce resources in software engineering are no longer just remaining sprints. They are increasingly:

• human attention
• system comprehension
• review capacity
• architectural consistency
• operational understanding
• engineering judgment

For years, we optimised engineering organisations around the assumption that writing code was the bottleneck. AI may force us to optimise around something entirely different:

preserving human understanding of systems evolving faster than humans can manually construct them.

AI Changes the Shape of Engineering Risk

A lot of the public discussion around AI coding assistants focuses on code quality. People worry about hallucinations, security flaws, or poor syntax. Those are real concerns, but I increasingly suspect they are not the most important ones.

The bigger risks are organisational and architectural.

AI dramatically increases the speed at which engineers can generate change, but most engineering processes were designed around a much slower rate of evolution. Pull requests become larger. Architectural drift accelerates. Abstractions multiply. Teams generate work faster than reviewers can realistically absorb and reason about it.

The dangerous thing is that AI also learns from our historical shortcuts. For years, engineers accepted certain compromises because implementation effort was expensive. Patterns that were once “good enough for now” become repeated endlessly by AI systems that treat those patterns as best practice. Weak engineering discipline scales faster because the friction that once slowed it down has disappeared.

I think one of the most interesting changes is how AI alters validation behaviour during development itself.

When I first learned software engineering, debugging was a constant feedback loop. You built a small piece of functionality, ran the application, checked the UX, verified the database state, confirmed the workflow behaved correctly, then moved on to the next change. By the time you raised a pull request, you had manually exercised most of the feature repeatedly. Not that we had pull requests in our rudimentary source control systems back then; at least not at my firm.

AI-assisted development subtly changes that rhythm. If the AI is generating large portions of the implementation at high speed, the human often validates the system later and in bigger slices. Validation becomes more integration-oriented rather than incremental. And if the tests themselves were generated by the same AI system that generated the feature, you start running into uncomfortable philosophical questions about whether the validation is genuinely independent at all.

Quis validat validationem? Who validates the validation?

This is where craftsmanship becomes critically important. The future value of engineers may not come from how quickly they can generate code, but from how effectively they can reason about systems, validate behaviour, identify bad abstractions, preserve maintainability, and intentionally shape long-term architecture.

We Are Returning to Software Architecture

For a long time, “software architecture” became an unfashionable term in many engineering circles. Architecture became associated with heavyweight governance, endless documentation, ivory tower design sessions, and slowing delivery down.

At the same time, agile was often interpreted as “just iterate quickly”. I have genuinely had engineering leads tell me documentation was unnecessary because “we’re agile.” Looking back now, that mindset feels slightly absurd.

The irony is that AI may actually allow us to rediscover some of the engineering practices we lost during years of delivery optimisation.

When implementation becomes dramatically cheaper, suddenly teams can afford to spend more time discussing design, validating ideas, documenting decisions, and intentionally shaping systems. AI can scaffold requirements documents, generate RAID logs, summarise discovery sessions, identify contradictions in planning discussions, and create the kind of supporting artefacts that teams previously avoided because they were too time consuming to maintain.

That is fascinating to me because it potentially brings architecture and agile back together rather than treating them as opposing forces.

Good architecture is not about producing diagrams to satisfy governance boards. It exists to reduce cognitive load. It creates boundaries, consistency, ownership, and clarity so that humans can continue understanding systems as they evolve. In many ways, architecture becomes a human scalability layer.

And perhaps that is the real shift AI is forcing on software engineering. The bottleneck is no longer writing software. It is maintaining shared understanding of systems that evolve at machine speed.

Craftsmanship in the AI Era

Historically, engineering craftsmanship was often associated with elegant handwritten code, deep framework knowledge, or low-level implementation skill.

I think AI changes that definition. Craftsmanship increasingly becomes a mixture of reasoning, intent, architectural judgement, stewardship, understanding of the trade-off; and of course, knowing when not to trust the AI.

That is why I do not believe AI reduces the importance of experienced engineers. If anything, I believe that it increases their importance. AI amplifies leverage, leverage increases blast radius, and blast radius increases the value of judgment. The engineer matters more when the tools become more powerful.

And perhaps that is the most important thing organisations need to understand right now. AI coding assistants should enhance engineering thinking, not replace it. The future of software engineering probably does not belong to the people who can generate the most code.

It belongs to the people who can still understand the system once it’s been build.

Thank you to Josh Withers, Mateusz Wacławek, Tim Gouw, and Photo by Alex Shute on Unsplash for the photos used in this post.