When Implementation Is Free, What Is Architecture?

In 1972, David Parnas wrote a paper — "On the Criteria to Be Used in Decomposing Systems into Modules." Twelve pages. It defined the next fifty years of software architecture.

Parnas' thesis: the criterion for modularization is not "function" — not "group everything user-related together." The criterion is information hiding — encapsulate the parts of the system most likely to change inside modules, so that the interfaces between modules do not expose those changes.

This principle — "cage the change" — runs through every subsequent architectural movement. Microservices isolate "change" into independent deployment units. Domain-driven design aligns "change" with business domain boundaries. Layered architecture layers "change" — upper-layer logic changes without affecting lower-layer data operations.

But these principles share an unexamined premise: implementation is costly. Modularization is effective because "changing code" is expensive — it takes a person, understanding the context, rewriting code. If your modularization can cage "what is expected to change" — you are reducing the systemic cost of modification.

Now — AI has changed that premise.

The cost of implementation is approaching zero.

If the cost of "rewriting a function" — to you — is near zero — what is architecture? If "refactoring a module" — only requires you to describe your needs clearly and let AI regenerate — what is architecture? If "modifying code to meet new requirements" is no longer your main time allocation — do you still need Parnas-style information hiding?

One immediate corollary: if implementation is free — modules don't need to "isolate change" — because change itself has become cheap. You can stuff two functions into the same module. When they start to conflict — you let AI rewrite the entire module. Architecture's original function — "caging change" — is being hollowed out.

But this is not the end of architecture. It is a paradigm shift.

When implementation cost disappears — what costs do not disappear?

The first is cognitive cost. A module — even if AI can rewrite it instantly — is still a unit of understanding. When you need to trace a bug across six AI-generated modules — you will discover that the original function of information hiding — reducing human cognitive load — does not disappear just because implementation is free. It just shifts — from the "first principle" of architectural design to the "last surviving principle."

The second is integration cost. Two modules — each generated by AI — with an interface between them — will, on first contact, almost certainly mismatch. AI generated Module A — assuming input is {userId: string, role: "admin"|"user"}. AI generated Module B — reading user data — outputs uid: number, type: string. No compilation error. Runtime — userId not found.

An interface — in this new world — is not "part of implementation." An interface is a contract. When implementation is outsourced to probability — contracts cannot be outsourced. Because a contract — in its essence — is deterministic. One party commits to provide X. The other commits to produce Y given X. Probability cannot commit.

The third is evolution cost. A system — over time — accumulates knowledge that can only be understood in context. Why is this field called legacy_id? Why does this table have two nearly identical timestamp columns? Why does this line of code — deleted six times — still exist in the repository, because every deletion breaks an unmaintained CI step? AI does not know this. Can never know it. It is not in the training data. It is in the history of this organization.

Architecture — in the new paradigm — is no longer "how to decompose a system into modules." Architecture is — "what cannot be handed to AI."

First: interface contracts — cannot be handed to AI. Not because AI cannot write interfaces — but because the definition of an interface must be a deterministic agreement, made by a human who knows the needs of both sides. AI can assist — "generate two candidate input formats — which is cleaner?" — but the contract itself is non-delegable.

Second: the data model — cannot be fully handed to AI. Table structures. Field semantics. Constraints. These are the system's deepest "facts" — all upper-level behavior rests on them. AI can generate table schemas. It can optimize indexes. But it cannot own the data model. Because modifying a data model — unlike code — cannot be losslessly rolled back. Data, once written wrong, is wrong — and you may not discover it for a year.

Third: invariants — must be defined by humans. A banking system's ledgers must balance. A chat app's private messages must not be readable by third parties. A medical system's prescription dosage must pass an upper-limit check. These are not implementation. These are rules. Rules cannot be sampled from a probability distribution. Rules must be hardcoded — not in "some branch of the code" — but in the contract layer of the system — verified by tests — contracts constraining behavior.

Fourth: architectural decision records — cannot exist only in AI's output. Why did you choose event sourcing over CRUD? Why was this service extracted and not that one? These decisions — two years into system evolution — are the only thing that can explain "why the system looks like this." If you let AI make these decisions — two years later, no one — including you — will understand the reasons.

AI's correct role in architecture — is not replacing decisions. It is generating the decision space.

"Give me three ways to design this search module — and the tradeoffs of each." "Take approach A — but map out its in-memory data structure for me." "What happens to approach B at thirty million users — can you simulate it?"

The best use of AI — is not having it make decisions — but having it unfold "what decisions you can make." Before AI — the cost of evaluating multiple architectural options was prohibitive. You picked one based on experience and intuition — got on the boat — hoped it didn't sink. Now — AI can, before you decide, reduce the comparison between options — concretely, at the code level — to something a single human brain can cover.

This is not "AI doing architecture." This is "AI letting the architect see more possibilities — and then the architect chooses one — and bears the consequences of the choice." The tool expands the space. The human bears the direction.

What Parnas said in 1972 — in the new paradigm — is half wrong, and half more correct than ever.

The wrong half: "caging change" is no longer the core of architecture — because change itself has become cheap.

The right half: the true purpose of information hiding — was never "caging change." It was "caging complexity." A system — at any moment — can only have a limited number of "active points." A human can attend to no more than seven things at once. Architecture is not letting AI generate everything and then drowning the human in AI's output. Architecture is — defining boundaries — determining "inside this boundary, AI is free; outside this boundary, AI cannot touch."

When implementation is free — architecture is no longer a blueprint. It is a set of boundaries. On one side of the boundary — AI has full implementation freedom. On the other side — AI's input is not accepted. Truly good architecture, in the age of AI, is not "designing the best module structure." It is "defining clear boundaries and borders."