When Understanding Becomes the Bottleneck

Software engineering has always evolved by raising the level of abstraction.

There was a time when developers wrote machine code. That gave way to assembler, then high-level programming languages, object-oriented design, frameworks, cloud platforms and Infrastructure as Code. Each step moved us a little further away from implementation details and a little closer to solving business problems. Very few developers today concern themselves with the machine code generated by a compiler. The implementation still exists, but it has become an implementation detail.

AI agents feel like the next step in that journey.

Much of the current discussion focuses on AI’s ability to generate code. While that is undoubtedly impressive, I suspect it isn’t the most significant change we are about to experience. The more profound shift is that AI raises the level of abstraction at which software is developed.

As AI agents take on an increasing proportion of implementation and testing activities, the effort required to produce software is likely to reduce significantly. Implementation will remain an essential engineering activity, but it may no longer dominate software development in the way it has for decades.

This raises an interesting question.

If implementation becomes significantly cheaper, where does the bottleneck move?

For decades, software delivery has largely been constrained by implementation effort. We have organised our teams, our delivery processes and our ways of working around that assumption.

That assumption may no longer hold.

The scarcity in software development is no longer the ability to write code; it is the ability to understand the problem well enough that both people and AI agents can solve it.

Solution Context

An AI agent without sufficient understanding behaves much like a developer without sufficient understanding. It remains productive, but not necessarily in the right direction.

It will happily satisfy the request it has been given, but without understanding the wider objectives it is difficult to judge whether that decision contributes to the overall solution. As the solution grows, individual decisions that make sense in isolation can gradually erode its coherence.

Many developers may have already experienced this.

Development begins at an impressive pace. Then progress slows. Prompts become increasingly detailed. Eventually, instead of describing the outcome we want, we find ourselves explaining exactly how to implement it. At that point, we haven’t eliminated programming. We’ve simply moved it into the prompt.

The issue is perhaps not the capability of the AI agent. It is the absence of sufficient understanding.

That shared understanding is the knowledge required to construct the right software product in the right way.

Throughout this article I will refer to it as Solution Context.

Solution Context captures the shared understanding needed to develop a solution that both people and AI agents can draw upon throughout the software lifecycle. It is the collective knowledge produced by the activities that precede implementation. In practice, it is often captured in documents and other project artefacts that describe business objectives, requirements, architectural decisions and design knowledge. Requirements define what needs to be achieved, architecture establishes the structure and guiding principles, and design determines how those principles are realised. Together they create the Solution Context from which implementation can proceed.

The activities that follow implementation have a different purpose. Testing, quality assurance and deployment are concerned with verifying, validating and delivering the solution. AI agents can assist throughout the lifecycle, but the quality of the implementation is fundamentally constrained by the quality of the Solution Context that precedes it. In other words, AI can accelerate implementation, but it cannot compensate for an incomplete understanding of the problem.

Like the architecture itself, the Solution Context evolves continuously as business priorities change, new requirements emerge and the solution develops. It becomes the thread that connects business intent to implementation throughout the software lifecycle.

Importantly, Solution Context is not owned by a single role.

Product owners contribute business objectives. UX specialists contribute an understanding of users. Architects establish structure, constraints and technical direction. Developers contribute implementation knowledge and practical experience.

Together they create the shared understanding that allows both people and AI agents to make consistent decisions.

The Role of the Architect

The role of the architect does not fundamentally change.

Architects bridge the gap between business and technology by translating business objectives into technical solutions. They create the conditions in which good engineering decisions can be made.

Those responsibilities remain unchanged. What changes is the leverage.

AI agents can explore design alternatives, evaluate architectural options and implement significant parts of a solution in a fraction of the time previously required. That should be seen as an opportunity rather than a threat.

It allows architects to spend less time on activities that AI can readily accelerate and more time understanding the business, challenging assumptions and refining Solution Context.

Architecture is a continuous activity because businesses evolve continuously.

AI does not change this principle. What it changes is the speed at which implementation can happen.

A weak architectural foundation often results in technical debt. Using AI agents to perform implementation based on a weak foundation simply enables that technical debt to be created much faster.

Conversely, a well-defined architectural foundation enables AI agents to accelerate delivery while preserving the integrity of the overall solution.

The architecture is a vital part of the Solution Context and the speed of AI agents makes the consequences of poor architecture far more visible.

This is the point at which understanding becomes the bottleneck. The challenge is no longer whether we can implement software quickly enough, but whether we can develop and maintain sufficient shared understanding to guide both people and AI agents at the pace of implementation.

Organising Around Understanding

The software development lifecycle itself does not fundamentally change. Requirements still drive architecture, architecture still guides design, and implementation remains essential. What changes is where software teams invest the majority of their intellectual effort.

In traditional software development, implementation has typically represented the greatest investment of time and effort. Requirements, architecture and design establish the direction of the solution, but much of a team’s capacity has historically been devoted to building, testing and delivering the software.

AI changes that balance.

As AI agents assume an increasing share of implementation and testing activities, the lifecycle itself remains unchanged, but the centre of gravity moves. More effort is invested in developing and maintaining the Solution Context that enables AI agents to work effectively. Requirements, architecture and design become increasingly important because they capture the shared understanding from which implementation is derived.

Implementation does not disappear; it becomes increasingly automated. The challenge for software teams is no longer simply writing software, but developing sufficient clarity for both people and AI agents to deliver the right solution.

If implementation can happen in minutes rather than weeks, sprint planning and backlog refinement become less about allocating coding effort and more about creating sufficient clarity for both people and AI agents to deliver independently. The cadence of delivery is no longer constrained primarily by implementation capacity, but by how quickly a team can develop a shared understanding of the problem they are trying to solve.

This may also influence how software teams organise themselves.

Rather than optimising around implementation, teams may increasingly focus on developing and maintaining the Solution Context for individual business capabilities. This allows multiple AI agents to work in parallel because they are guided by the same understanding of the problem.

Business objectives still drive requirements.
Requirements still influence architecture.
Architecture still guides design.
Design still informs implementation.

The difference is that implementation is no longer where the majority of intellectual effort is applied.

Conclusion

Perhaps the most interesting aspect of AI isn’t that it writes code.

Throughout the history of software engineering, every significant advance has raised the level of abstraction. AI agents simply continue that trend.

At one time we worried about machine instructions. Today we rarely think about the machine code generated by our compiler because that abstraction has become part of the platform.

It seems entirely possible that implementation will follow the same path. As implementation becomes increasingly commoditised, understanding becomes the scarce resource.

If that happens, the competitive advantage of a software organisation will no longer be determined primarily by how efficiently it writes code. It will depend on how well it understands the problem it is trying to solve and how effectively it captures that understanding in its Solution Context.

AI does not change the principles of software engineering.

It simply reminds us which ones have mattered all along.