AI Did Not Make Design Obsolete. It Made Bad Design Expensive.

Preface: we are standing at a fork in the road

In the software industry of 2026, almost every conversation circles the same question: once coding agents are capable enough to carry most of the development work, what exactly is the human role in the software lifecycle? Put more sharply: when AI can write the code, test it, and deploy it, does good software design still matter?

Two extreme positions have emerged. One holds that agents must be kept on a short leash and reviewed line by line. The other argues for delegating development wholesale to agents, with humans writing specifications and code demoted to “a transient implementation detail.”

We have fundamental reservations about both. Not because we doubt what AI can do — quite the opposite. We have integrated agents deeply into our production work and seen the acceleration first-hand. It is precisely because we use them this heavily that we are more convinced, not less: letting agents run unsupervised is one of the riskiest bets a company can place on its digital assets.

The purpose of this memo is to give our clients a clear decision framework: in the age of AI, what engineering discipline keeps a software investment appreciating rather than depreciating fast.

Agents learned from the best of us

Today’s coding agents were trained on decades of code written by people.

That is not a piece of technical trivia; it is a variable with direct commercial consequences. What agents learned from was not haphazard code that happens to produce the right output. It was thoughtful abstractions, modules with clear boundaries, functions and classes named consistently and with evident intent. In other words, the whole body of design wisdom accumulated by human software engineering is the very ground on which agents make reliable judgments.

What follows from that?

When the internal quality of a system starts to degrade — modules tightly coupled, business logic duplicated and scattered, naming losing its consistency — agent behavior degrades with it. More wrong assumptions. More context consumed. More wandering into unnecessary debugging paths. Higher error rates. More human intervention.

The cost of poor design does not disappear because the consumer changed from a human to an AI; it simply arrives on a different invoice. Technical debt used to be abstract and hard to quantify. Now it shows up precisely, in a team’s monthly AI spend and in hours of rework. For the first time in the history of software, we can put an explicit price tag on bad design.

For a business, that is a strategic signal: maintaining a high-quality codebase is no longer a matter of engineering pride. It is a quantifiable, trackable commercial decision that lands on the income statement.

Three structural risks on the fully autonomous route

We do not argue for micromanaging agents. But across a great deal of practical observation we have identified three deep problems that a purely agentic workflow cannot correct on its own. We name them here, because what cannot be named cannot be governed. These are not temporary technical limitations; they are structural risks of building on top of a non-deterministic system.

The entropy curve has steepened

Software entropy — the tendency of a system to degrade over time — is not a new idea. What is new is the rate at which agents drive it.

Human engineers follow, to some degree, an implicit instinct for quality: they extract duplicated logic, they fix a poor name while passing through, they stop and reconsider when the architecture drifts from its original intent. Agents have no such instinct. Their objective function is “make the feature pass its tests”, not “keep this system easy to change six months from now”. They will find every available shortcut to a green build, without weighing what those shortcuts cost in long-term maintainability. The agent will not flinch while writing the third copy of the same business rule — it has no face to flinch with.

More important still, agents introduce change far faster than people do. Design drift that might take a human team three weeks to accumulate, agents can produce in three days. When technical debt compounds an order of magnitude faster, by the time the problem visibly slows the business down, the cost of repair has long exceeded whatever time was saved at the start.

This is the first line of defense we hold for our clients: alongside the speed of AI output, a systematic cadence of design review that intervenes before the entropy curve turns steep.

The specification trap

The intuitive answer to the first risk is to write extremely detailed design specifications and require agents to follow them strictly — architectural constraints, module boundaries, error-handling strategy, naming conventions, performance budgets, all of it.

Where does that line of thinking end?

Once a specification is precise enough to eliminate the inherent ambiguity of natural language, it becomes hard to distinguish from code itself. You have only switched to a different syntax for programming — one with less precision, weaker verification and poorer tooling than a real programming language.

Natural language is expressive, but it is terrible at being exact. In software development as we have known it, turning vague requirements into unambiguous implementation is one of the core things an engineer is for. If code is turned into a black box in the pursuit of speed, that responsibility for removing ambiguity does not go away; it is merely pushed up into the specification, in a less reliable form.

Our route is different: we do not treat code as an enemy to be hidden, but as the shared language in which we collaborate with agents. In our practice, engineers and agents use code as a precise, unambiguous medium of communication, converging on design intent as they pair — rather than trying to foresee every edge case in a specification document and then letting agents improvise.

The probabilistic machine

Every layer of abstraction the industry has adopted so far — from assembly to high-level languages, from physical servers to virtual machines to containers — shared one premise: they were deterministic. The same input always produced the same output.

Coding agents break that premise at the root. Ask the same agent to implement the same feature five times and you will likely get five different architectural choices, naming strategies and error-handling approaches.

This is not a defect; it is the nature of such systems. An agent’s decisions come from feeding context and assumptions into a model whose internal mechanism is opaque, and its output is probabilistic by nature. The first two risks are accelerants; this one is the fuel. Which means that every design choice an agent makes needs a person with judgment evaluating it on the output side: is this choice sound for the system as a whole? Is it consistent with the technical direction? Is the trade-off between maintainability, performance and delivery speed the right one here?

That work is not an extension of code review. It is architectural governance at a higher level — it cannot be automated, and it should not be outsourced.

Design lives in the code, not in the document

The analysis above points to a single conclusion: good software design is not a property that can be specified once and then handed to agents to execute autonomously forever. Design lives in continuous feedback and adjustment, renegotiated as business needs evolve.

More importantly, real design judgment has to happen at the level of the code. Where is the coupling? Where has cohesion broken down? Which abstraction has been generalized past its usefulness? Which two concepts should be merged? The answers are not in an architecture diagram or a design document — they exist only in the details of the code. Code is the ultimate litmus test for any design hypothesis.

Even when agents produce most of the code, people still need to descend to that level to assess the health of the system. That is not micromanagement; it is a governance responsibility.

Four commitments, one definition of success

We translate the above into four concrete commitments.

Speed and quality are not a trade-off; they are two engines. We do not ask clients to choose between shipping fast and lasting well. Agents accelerate output and remove repetitive labor; our engineers own architectural judgment, design governance and the quality bar. The two are not in competition — they are a deliberately designed division of work.

Technical debt stops being an unexamined account. For every project we establish quantifiable health indicators — context consumption trends, agent error rates, how often humans have to intervene, the velocity curve — turning technical debt from a vague engineering anxiety into a clear report you can discuss with a CFO.

Designed for two audiences. The software of the future will be maintained by people and agents together. That is not a prediction; it is already happening. Every system we design accounts for both kinds of collaborator — quick for a person to understand, and effective for an agent to navigate. This is not an added cost; it is the baseline competitiveness of the next generation of software.

The second year is the real test. Any team can use agents to produce a working system from scratch in a month. The real difference shows a year after launch, fifty feature iterations in: can the system still be changed at a steady pace, at a running cost that stays under control? Our engineering method starts from that long-term definition of success.

In closing: code is not going away

A popular argument holds that AI will turn code into a black box, and that people need only care about the input (the specification) and the output (working software).

We think that argument is not only technically unsound but commercially dangerous. Code is not going away. It remains the thing we inspect, criticize, improve and govern — whether a change was made by hand, generated by an agent, or produced by the two working together.

The real shift is not about who writes the code. It is that our definition of good design has to widen: from “easy for humans to change” to “easy for humans and AI to change together”. This is a new discipline, and a new dimension of competition. We are already inside it, and we are ready to take our clients through the turn.

We would be glad to talk with you about building a technical foundation for your next critical system that genuinely holds up in the age of AI.