We are entering a new era of software development. AI agents can write code, refactor existing systems, investigate bugs, implement features and perform tasks that previously required human developers.
This has led to some interesting questions about the future of software engineering.
Do we still need abstractions if AI can work directly with low-level implementations? Do we still need documentation if agents can read the source code? Do we still need to care about developer experience if developers are no longer the only ones writing code?
I think we're asking some of the wrong questions.
One of the assumptions behind these discussions is that AI agents are fundamentally different from human developers, and therefore the engineering principles we've developed over decades might no longer apply.
But there's an important distinction worth making.
AI agents are not limited in the same ways humans are. They already have considerably more reasoning bandwidth in certain dimensions. They can process more information, explore more of a codebase and handle levels of complexity that would be difficult for an individual developer.
But they aren't unlimited.
And that's the interesting part.
Many of the engineering principles we've developed to manage complexity remain relevant, not because agents have human-like limitations, but because even greater reasoning capacity benefits from structure.
The problem isn't that agents are just like us. It's that we're still building systems that can become too complex to reason about efficiently.
We didn't invent abstractions just for humans
Consider why we introduced abstractions in software engineering in the first place.
We moved from machine code to assembly, from assembly to higher-level programming languages, and from low-level instructions to increasingly sophisticated abstractions.
We introduced modules, interfaces, encapsulation, libraries, frameworks and architectural patterns.
These developments weren't arbitrary. They helped us manage complexity.
A developer working on a large system cannot keep every implementation detail in their head. They need ways to reason about parts of the system without understanding everything happening underneath.
Abstractions make this possible.
They allow us to focus on what something does rather than constantly having to understand how it works.
This is one of the arguments I made in my previous article, Will AI Make Abstractions Obsolete?.
The argument was that AI doesn't make abstractions obsolete. The need to manage complexity doesn't disappear simply because we have a different way of producing code.
But there's another reason why abstractions matter.
They aren't exclusively useful to humans.
They are useful to anything that needs to reason about complex systems.
And that includes AI agents.
Agents have more bandwidth, but not unlimited capacity
Human developers have limited working memory. When working on an unfamiliar codebase, we need to spend time understanding its structure, identifying relevant components, discovering conventions and building a mental model of how everything fits together.
AI agents have considerably more bandwidth for this kind of work.
An agent can inspect many files, trace dependencies across modules, compare implementations and maintain relationships between parts of a system that would be difficult for an individual developer to keep in working memory.
In some dimensions, AI can already operate beyond human cognitive limits.
But this doesn't mean it can handle complexity without constraints.
Models have finite context windows and computational resources. As the number of components, dependencies and interactions grows, the amount of information that needs to be considered grows too. Maintaining an accurate understanding of an increasingly complex system becomes progressively more demanding.
The important distinction is that AI raises the ceiling. It doesn't remove it.
Consider an unfamiliar codebase with duplicated functionality, inconsistent naming conventions, implicit dependencies and unclear architectural boundaries.
A human developer might struggle to understand the system because they cannot comfortably keep all the relevant information in working memory.
An AI agent might be able to explore considerably more of the codebase in a single task. But it still has to discover where functionality lives, reconstruct dependencies, infer conventions and determine which information is relevant.
An important difference is that agents can often compensate for complexity by exploring more information. A human developer might need to simplify a problem to fit it into working memory. An agent might instead inspect more files, follow more dependencies and spend more reasoning resources reconstructing the system.
These are different strategies, but neither makes complexity free.
The problem isn't necessarily that the agent cannot understand the code. It's that the codebase makes understanding unnecessarily expensive.
This is where familiar software engineering practices become valuable again.
Good naming reduces ambiguity. Modular architecture limits the amount of code that needs to be considered. Clear interfaces communicate expectations. Documentation provides context that might otherwise need to be inferred. Tests provide feedback about whether an implementation is correct.
These practices don't compensate for an AI's inability to reason like a human. They reduce the amount of unnecessary complexity that any problem solver needs to deal with.
And as agents become more capable, the value of these practices becomes even more apparent.
Technical debt now has a token cost
There is an interesting development that makes this argument particularly tangible.
We can start measuring some of the consequences of poor code quality in terms of AI token consumption.
An agent working on a messy codebase often needs more tokens to understand the system before it can implement a change.
This isn't just about generating more code. A significant amount of an agent's work involves reading, exploring, reasoning and gathering context.
Some recent experiments have started investigating this relationship.
For example, SonarSource published research comparing coding-agent performance across cleaner and messier codebases. Their results showed that cleaner codebases reduced token consumption, reasoning effort and the number of files agents needed to revisit.
Other experiments have reported substantial reductions in token consumption after restructuring large, difficult-to-navigate source files into smaller, more cohesive modules.
The implications are interesting.
Historically, we've justified refactoring by explaining that it makes code easier for developers to understand and maintain.
Now we have another way to think about its value.
Technical debt has a token cost.
A poorly structured codebase doesn't just make humans slower. It can make agents more expensive to operate.
Every unnecessary dependency, duplicated implementation, unclear abstraction or implicit convention creates additional work for something trying to understand the system.
Refactoring can therefore become an investment in reducing the marginal cost of future development tasks.
You spend resources improving the structure of the codebase today, potentially saving tokens, time and money across hundreds of future agent interactions.
Of course, fewer tokens don't automatically mean better results. An agent still needs sufficient context to make correct decisions. The objective isn't to minimize context at all costs, but to eliminate unnecessary complexity and exploration.
We should also distinguish between token consumption, execution time and correctness. Reducing the amount of context an agent needs doesn't necessarily mean it will produce better results. The real objective is to make it more efficient without compromising the quality of its decisions.
Nevertheless, the direction is clear: code quality has consequences beyond human productivity.
AI amplifies the gap
This brings me to an idea I explored in my SIC2026 talk: AI amplifies the gap.
The point is that many of the things we discuss in developer experience have always been true.
A good development environment makes developers more productive. Clear architecture makes systems easier to understand. Consistent conventions reduce friction. Good documentation makes it easier to work with unfamiliar systems.
AI doesn't invalidate these principles.
It amplifies them.
Consider two development environments.
The first has clear architectural boundaries, predictable conventions, useful documentation, explicit interfaces and automated tests.
The second has inconsistent patterns, outdated documentation, unclear dependencies, duplicated logic and poor test coverage.
A human developer will probably be more productive in the first environment.
An AI agent will probably be more productive there too. But there's an additional dimension.
Agents can operate at considerable speed and scale. They can explore many files, implement multiple changes and execute numerous tasks in parallel.
They have considerably more bandwidth than an individual developer, which allows them to take advantage of good engineering environments at a different scale.
When the environment is good, this gives them leverage.
When the environment is bad, they have to spend more resources reconstructing the system, resolving ambiguity and validating their assumptions. Their ability to operate at scale can also give mistakes more opportunities to propagate.
AI amplifies the quality of the environment in which it operates.
This is the DX paradox: precisely when AI makes implementation cheaper, the quality of the engineering environment becomes even more important.
The cost of producing code is decreasing, but the cost of understanding, coordinating, validating and maintaining complex systems hasn't disappeared.
In fact, it might become more consequential.
We should rethink what good developer experience means
For a long time, developer experience has primarily been discussed from the perspective of human developers.
We optimize build times, improve documentation, simplify tooling, introduce conventions and create abstractions to make development easier.
But perhaps we should stop thinking about these practices as exclusively human-oriented.
They are ways of making complex systems easier to understand, navigate and change.
That means the audience for good developer experience is expanding.
We should increasingly consider how easy it is for an agent to understand our architecture, discover the right implementation, identify the constraints of a task and verify its work.
This doesn't necessarily mean creating entirely separate engineering practices for agents.
Many of the things we already do are useful.
Good modularity, explicit interfaces, consistent conventions, automated tests, clear documentation and well-designed abstractions remain valuable.
Some practices will evolve, and new ones will emerge. We might need better ways to communicate agent permissions, task boundaries, operational constraints and verification requirements.
But the underlying principles are familiar.
We should also resist the temptation to blindly preserve every historical practice simply because it has worked for humans. Some practices may become less relevant, while others may need to be redesigned around agent capabilities.
The important thing is to understand why these practices exist in the first place.
The future isn't about writing less code. It's about managing complexity.
AI agents are changing how software is produced, but they haven't fundamentally changed the nature of the problems we're trying to solve.
Building complex software is still difficult.
Understanding unfamiliar systems is still difficult.
Coordinating changes across large codebases is still difficult.
Making sure that changes are correct is still difficult.
These problems didn't emerge because humans write code. They emerged because software systems are complex.
AI is already capable of handling levels of complexity that would be difficult for individual developers. It has more reasoning bandwidth, can explore more relationships and can operate at a scale that would have been impractical before.
But greater intelligence doesn't make complexity disappear. It allows us to work with more of it.
And as the systems we build become increasingly sophisticated, the demands on that reasoning capacity will increase too.
We developed abstractions, architectural boundaries, documentation, conventions and engineering practices to help us manage complexity.
These principles remain relevant, not because AI has the same cognitive limitations as humans, but because even significantly greater reasoning capacity benefits from structure.
Perhaps we've been too quick to assume that the future of software engineering must be radically different simply because AI is involved.
We should certainly adapt. We should experiment. We should challenge assumptions that no longer make sense.
But we shouldn't throw away decades of engineering knowledge without understanding the problems that knowledge was designed to solve.
We didn't invent good software engineering practices because humans are bad at programming. We invented them because building complex software is difficult.
And AI hasn't changed that.
