In the era of AI coding agents, representing and enforcing software architecture is easier than ever. The Locality Criterion defines architecture in the simplest terms.
Ask an AI coding agent to add a feature and it will add one. Ask it not to break your architecture and it will agree, sincerely, and then break it anyway. The fault is not carelessness. It is that nobody told the agent which of the ten thousand facts about your system were the architecture — because nobody could.
The industry has arrived at half the answer. Coding agents optimise locally: they solve the problem in front of them and leave the system to absorb the consequences. Quite so. But “local” is not a figure of speech. It is a technical term with a precise definition, and it has had one for twenty years. Get that right and the rest follows: which decisions an agent can be trusted with, which it cannot, and — the part nobody expects — how short the document you have to write actually is.
In November 2024 the convener of ISO Working Group 42 invited us to present the locality criterion to the group’s 42nd meeting. It is now cited in informative annexes B and C of the draft standard — informative meaning explanatory rather than binding — and the draft is due to be published.1 We take this as an opportunity to convey, in simple terms and minimal jargon, what counts as “software architecture”, and why it is more important than ever in the era of coding agents.
That is what this essay is about. It is not about the mathematical framework, the formal definitions, and the proofs that security concerns, architectural styles, and programming paradigms are non-local. Those are presented in full elsewhere.23 Leaving behind the admittedly tedious model-theoretic vocabulary that a formal proof necessitates, we motivate the criterion and explain why it works.
The Locality Criterion
Architecture is what growth can break
That’s it. That is all it takes to separate ‘architecture’ from just any design decision.
(Pausing for caution: This is the intuitive, informal version. The Locality criterion and the nature of what “growth” exactly means are formally defined in model-theoretic terms and must be carefully unpacked before they can become useful. The criterion’s scope is “specifications of software design”, which is also carefully unpacked. Refer to the cited sources for clarification and many more examples.)
Take an example: Data can only be accessed via the authentication proxy. We ask: Is this part of the spec architectural? The Locality Criterion says it is. The test is simple: say a system satisfies the spec. The same system can break the rule by adding code: writing a new class or a procedure that circumvents the proxy and accesses data directly. This makes our example non-local, the technical term for architectural specification.
A counter example: The Observer Design Pattern announces changes to subscribers. Is this specification architectural? Let’s apply the criterion: say a system satisfies the spec, which means it implements the observer/subscriber and observable/publisher interfaces. Can we break the spec by adding code? No! Without changing parts of an existing system, the Observer lives. Hence, the Observer Pattern is local, and therefore, not architectural.
Who Needs Formalists?
Almost everyone who builds computing systems is convinced that all system design needs to be done within a rich conceptual frame. The conceptual frame provided just by a programming language is too narrow; a wider frame is needed in which to understand the specifications of systems.
— Robin Milner, Is Computing an Experimental Science? 1986
This raises the question, Who cares? Why do we need a formal criterion? Until now the answer was clarity and intellectual hygiene. But coding agents give a much more powerful motivation. Code is cheap to generate, so codifying design matters more than it ever has. The architecture above all: written down in one place, and kept there.
A revolution4 is underway, and not only in software engineering. What does it have to do with the Locality Criterion or with Software Architecture? The answer is that you cannot govern what you have not defined. Software architecture, by any number of common definitions, is strategic5 in nature. So it has to be codified — which means that we should create a single, central record of the software architecture, adding ‘hooks’ and ‘skills’ that enforce it.
What AI Makes Worse
Without an explicit representation, whatever ‘architecture’ we had in mind at one point inevitably erodes and the ever-expanding code base drifts away from it. We think, Surely we can have the AI fix that later.
Maybe, maybe not. Being first to market is all that matters, so we generate code prompt by prompt, without pausing to codify our rules, and act surprised when they break. “That’s what tests are for, aren’t they?”
The evidence is in. GitClear examined 623 million changes made between 2023 and 2026: cross-file function calls fell by 35%, refactoring line moves by 70%, and duplicated blocks rose by 81%.6 Reuse across files is precisely what an architectural specification governs and the Locality Criterion defines — and it is precisely that which is disappearing.
What AI Makes Easy
The real revolution in software engineering is well beyond code generation: No longer do we depend on reverse engineering tools, struggle with software visualisation techniques, or dream about round-trip engineering7. All we need to do is codify our architecture — and now we know exactly what counts as “architecture” — plainly, precisely.
Specs are the new code
— Sean Grove, OpenAI, The New Code 2025
Consider the specification limiting access to data given in the example above. Two things can now be said about it, with absolute confidence:
- This specification is architectural, because it is non-local
- Embedding this sentence in the harness is sufficient to enforce it (**)
(**) I’m lying here, of course, but only to err on the side of brevity. Obviously, it takes effort to unpack it, and it must be done with care: What counts as ‘access’, Which data exactly and where it is stored, Who/What is the authentication_proxy, and so forth. Effort also must be spent on building the harness with the appropriate guardrails: a ‘skill’ that inspects code before shipping and ensures it is satisfied. But our point stands: It used to be that enforcing software architecture required us to translate it to a (likely unintuitive) mathematical language, “compile” it to become meaningful to our computers, map it reliably to the code, and so forth. No longer: In the era of coding agents, that sentence alone (with the caveats sketched) already has a precise meaning, and enforcing it using a competent coding agent requires orders of magnitude less effort.
As far as architectural specifications go, there is only one rule to keep, and it makes our lives much, much easier:
Codify your Software Architecture
Write your spec, place it in one document for the entire system, shared with everyone.
This rule is simple, and far easier to enforce using coding agents, skills, hooks, audits, and tests. Sync every commit with it, and you’re done.
Keep it short. And now we know how: Only non-local spec belongs in your Software Architecture, so writing it and keeping it fresh is a lot easier than you think.
Keep your Architecture short: only non-local specifications belong there
Whether your team is one programmer or a hundred and twenty, this is our only message to you. Everything else is small change.
I have participated in writing an Architecture document for systems of 200,000 lines and for systems of 2,000. It has never run past four pages. If you write one for your own system, send it to me. I will tell you what the criterion says about it.
Dr Amnon H. Eden is a computer scientist, the Principal Scientist at the Sapience.org thinktank, and founder of Moneta Sapiens Ltd.
–» dysclaimer «–
Footnotes
- ISO/IEC/IEEE DIS 42024, Enterprise, systems and software — Architecture fundamentals. Two informative annexes reference [2] and [3] below. The convenor of Working Group 42 invited presentation of the locality criterion to the group’s 42nd meeting, November 2024. As of August 2026 the draft has completed its enquiry ballot and awaits final draft ballot; publication is anticipated in 2027.
- Eden, A.H. and Kazman, R. (2003). Architecture, Design, Implementation. In L. Dillon and W. Tichy (eds.), Proceedings of the 25th International Conference on Software Engineering (ICSE), Portland, OR, pp. 149–159. IEEE Computer Society Press.
- Eden, A.H., Hirshfeld, Y. and Kazman, R. (2006). Abstraction Classes in Software Design. IEE Proceedings – Software 153(4), pp. 163–182. London: The Institution of Engineering and Technology.
- Eden, A.H., Moor, J.H., Søraker, J.H. and Steinhart, E. (eds.) (2012). Singularity Hypotheses: A Scientific and Philosophical Assessment. Berlin: Springer. ISBN 978-3-642-32559-5.
- Eden, A.H. (2005). Strategic Versus Tactical Design. Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS’05), Honolulu, HI.
- GitClear (2026). The Maintainability Gap: 2026 AI Code Quality Research. An analysis of 623 million changes committed between 2023 and 2026. Link
- Eden, A.H., Gasparis, E., Nicholson, J. and Kazman, R. (2018). Round-Trip Engineering with the Two-Tier Programming Toolkit. Software Quality Journal 26(2), pp. 249–271.