When Code Becomes Cheap, Architecture Becomes Everything

What Architecture Actually Means

Software architecture is the set of decisions about a system that are expensive to change later: how it's divided into parts, how those parts talk to each other, where the data lives, and which constraints everything else has to respect. For most of this industry's history, architecture and code were bought together you paid for the thinking and the typing as a single line item. AI code generation has pulled them apart. The typing is now cheap. The thinking is not.

Why We Used to Price Typing, Not Thinking

For decades, writing code was the bottleneck, so writing code is what we priced. Estimates were measured in developer-days because developer-days were the scarce resource. Whole methodologies grew up around making people type faster and waste fewer keystrokes. The implicit assumption was that producing the code was the hard, expensive part of building software.

That assumption no longer holds. A capable model will produce a plausible service, a reasonable test suite, and a working UI in the time it used to take to write the ticket. The cost of generating code has collapsed toward zero, and it isn't going back up.

The Hard Part Was Never the Typing

But the hard part was never the typing. It was deciding what to build and what to leave out, where to put the boundaries between parts, which failures the system has to survive, and which future changes you're quietly making cheaper or more expensive with every choice. None of that got easier. If anything, cheap generation makes it harder because now you can produce a tangle faster than ever, and it compiles, and the demo works.

What This Looks Like in Practice

Picture a team shipping a checkout flow for an online store. The old way, this took weeks — and somewhere in those weeks, someone made a decision about how payment logic would be separated from order logic, so that swapping a payment provider later wouldn't mean touching the checkout page, the inventory system, and the email service all at once. That decision wasn't written down anywhere. It just happened, slowly, because writing the code slowly forced someone to think about it.

Now the same team can generate the same checkout flow in an afternoon. It works. It passes the demo. But the payment logic is woven directly into the checkout page, because the model had no reason to separate them — nothing in the prompt asked for that boundary, and nothing in the process of typing it out forced anyone to notice. Eight months later, when the business needs to switch payment providers, the "quick" system turns out to be the expensive one. The team that took three weeks and drew the boundary on a whiteboard first is now the team that can make the change in a day.

Cheap Code Cuts Both Ways

Cheap code doesn't just make good systems cheaper to build. It makes bad ones cheaper to build too. A model will happily generate ten thousand lines in the shape of whatever you asked for, including a shape that will be impossible to change in eighteen months. The constraint that used to slow down bad decisions the sheer effort of writing all that code is gone.

The Anti-Patterns AI-Generated Systems Keep Repeating

A few shapes show up again and again in fast, AI-assisted builds, and they're worth naming because they're easy to miss until they're expensive:

Duplicate services. Ask a model to add a feature twice, in two different sessions, and it will often build two slightly different ways of doing the same thing rather than reusing what's already there — because it has no persistent memory of the system's existing shape unless you give it one.

Untracked dependencies. Generated code reaches for whatever library solves the immediate problem fastest, without anyone weighing whether the team wants to maintain, audit, or be locked into that dependency for the next five years.

Inconsistent data models. The same concept — a "customer," an "order," a "session" — gets represented slightly differently across services, because each generation pass solved its local problem without reference to the others.

Hidden coupling. Two parts of the system that should never need to know about each other end up quietly depending on each other's internals, because the fastest path to a working demo skipped the boundary that would have prevented it.

None of these show up in the first version. They show up in the second year, exactly where the article started.

The Leverage Has Moved Up the Stack

So the leverage moves up the stack. The scarce skill is no longer producing code; it's judgment about structure: where the seams go, what to make explicit, what to refuse, and what the cost of being wrong is. Code is the answer to a question. Models are extraordinary at producing answers and completely indifferent to whether the question was worth asking.

What Architects and Engineers Should Actually Do Now

If the typing is no longer the constraint, the discipline has to move earlier in the process, not disappear from it. A few practical shifts matter more than any specific tool:

What You're Actually Paying For Now

For anyone buying software, this changes what you're actually paying for. You're not paying a team to type — typing is the cheap part now, for everyone. You're paying for the decisions that determine whether the system is still cheap to change in its second year, or whether it's quietly become the thing your business can't move past.

Frequently Asked Questions

If AI writes the code, what is the developer actually responsible for?

The developer is responsible for the decisions a model can't make on its own: where the system's boundaries go, which tradeoffs are acceptable, and whether the generated code fits the shape the system needs to be in two years, not just today.

Does AI code generation increase technical debt?

It can, significantly, if the speed isn't paired with review. AI removes the natural friction that used to slow down bad decisions, so technical debt accumulates faster unless someone is deliberately checking for it.

How do I review AI-generated code for architecture problems, not just bugs?

Look past whether it works and ask whether it respects your system's existing boundaries: does it duplicate something that already exists, introduce a new dependency without discussion, or quietly couple two parts of the system that shouldn't depend on each other.

The Bottom Line: Architecture Is the New Bottleneck

When code becomes cheap, architecture becomes everything. The teams worth hiring are the ones who were always selling the thinking — the code was just how the thinking got delivered. The cheap-typing era doesn't threaten them. It finally makes the difference visible.