Architecture as a Constraint: Narrowing the AI Solution Space

In many projects I have worked on over the years, a sentence eventually came up that, in different variations, always meant the same thing:

“We don’t need an architect.”

Sometimes it really referred to the role itself. Sometimes it was more about the idea that architecture would emerge from the team anyway and therefore did not need any special attention. And surprisingly often, that worked quite well at first. Features were implemented, releases shipped, and technical decisions were made wherever they happened to become necessary.

The problem rarely appeared the next day. It emerged over years.

A service accessed something directly that should really have been behind another boundary. An exception made sense for an urgent use case and later became the reference for the next exception. A second pattern appeared next to an existing one, then a third. State acquired multiple owners. Features started using the internals of other features. New developers could find some existing example to justify almost any structural decision.

At some point, it was no longer clear which path was actually the intended one.

This is not a new story of the AI era. Software engineering has spent decades dealing with modularization, information hiding, cohesion, coupling, stable interfaces, dependency direction, and clear responsibilities. David Parnas published his foundational work on module decomposition in 1972. In 1974, Stevens, Myers, and Constantine described principles for reducing complexity through functional modules in Structured Design. In the late 1990s, Foote and Yoder gave a particularly advanced counterexample a memorable name: Big Ball of Mud.

Coding agents did not invent these problems. What changes is throughput.

A coding agent can modify code, tests, configuration, and documentation at a speed that would be difficult for a purely human team to match. In a February 2026 practice report, OpenAI describes an internal project whose code was generated entirely by Codex and in which a small team merged roughly 1,500 pull requests within a few months. Those numbers are not a general productivity benchmark. But they do show how dramatically the possible rate of change can shift.

That suddenly makes an old problem more urgent.

Many problems of agentic software development are old software problems under higher throughput.

If local structural decisions used to be made ten times a month and will be made a hundred times in the future, their nature does not necessarily change. But inconsistent decisions can multiply faster, become new precedents faster, and reshape the structure faster—the same structure from which the next agent will draw its evidence.

That is exactly why architecture interests me in the context of agentic work for a very specific reason: not because “good architecture matters” would be a particularly new insight, but because:

Architecture reduces the decision space of a coding agent.

Requirements were only the first boundary

The previous article described requirements as a boundary. A coding agent may construct different solution paths, but that does not make every result acceptable.

Requirements answer questions such as:

What must be true from a business perspective?

Which states are allowed?

What counts as success?

Which error cases must be handled?

What is out of scope?

That narrows the business outcome space.

But assume all of these questions have been answered perfectly. The agent knows exactly what the feature must do in the end. Even then, there may still be numerous structural ways to reach that result.

That is where architecture begins.

Requirements constrain the business outcome space. Architecture constrains the structural solution space.

Simplified:

all conceivable solutions
↓
Requirements
↓
functionally acceptable solutions
↓
Architecture Constraints
↓
structurally acceptable solutions
↓
smaller decision space

This is not the idea that architecture should provide a complete construction manual for every individual task.

An agent should still be able to make local decisions. It may cut a helper function differently, formulate a loop differently, or decide within a module which concrete implementation best fits the current problem.

Architecture instead defines decisions that I do not want to make again for every feature.

May Presentation access Infrastructure directly?

May Feature A import internals from Feature B?

Who owns a given piece of State?

Through which Contract may a module be addressed?

Which Dependency Direction applies?

These are structural decisions with a much larger radius of consequence than the question of how a local function is implemented.

Good architecture does not take every decision away from an agent. It mainly takes away decisions that should not be made again for every feature.

When the repository provides six correct answers

Consider a functionally simple change. A component needs new data.

In an evolved repository, an agent may find variants like these:

Component → API

Component → Shared Service → API

Component → Store → API

Component → Feature Service → API

Component → another Feature → API

Component → historical Utility → API

The problem is not necessarily that all six variants are obviously bad.

Perhaps they really all exist.

Perhaps each of them works somewhere in production. Perhaps each has a perfectly understandable history. The direct API call dates back to the early days. Later, a Shared Service was introduced. A new team used Stores. Another Feature has its own Application Service. For an urgent edge case, an existing flow from a neighboring Feature was eventually reused.

What is a coding agent supposed to learn from that?

A commonly used instruction is:

Follow the existing pattern.

That sounds precise until we actually look into the repository. Which pattern is the agent supposed to follow? It can open different files and find local evidence for several opposing variants. The codebase itself is telling it at the same time:

This is how we do it here.

and:

No, this is how we do it here.

At that point, variance is no longer only a property of the model. The repository itself contains an ambiguous structural solution space.

“Follow the existing pattern” only works if a system actually has recognizable patterns.

An agent can try to infer from frequency, recency, spatial proximity, or naming which example is more relevant. It can search additional documentation or open more files. Perhaps it even makes the right decision in the end.

But every one of those activities is additional interpretation.

The global architectural decision was not made beforehand. So the agent has to reconstruct it during a local feature.

Architecture eliminates unwanted variance

Now consider a system in which the following is binding for this area:

Presentation
↓
Application
↓
Domain
↓
Infrastructure

This layering is not a universal architectural recommendation. Another system may reasonably be structured with vertical slices, ports and adapters, a modular monolith, self-contained systems, or something entirely different.

The important point is not this particular diagram.

The important point is that the structure makes a statement.

If Presentation is not allowed to access Infrastructure directly, an entire class of structural solutions disappears from the acceptable space. If a business module may only be addressed through its Public Contract, more variants disappear. If State has one clear owner, an agent no longer has to decide for every feature where a second source of truth would be convenient.

The agent remains probabilistic and can still produce different solutions within the allowed structure. That is exactly what we want.

Architecture does not eliminate variance. It eliminates unwanted variance.

For me, this is one of the most important connections between classical software architecture and agentic development.

We are not trying to turn a coding agent into a deterministic compiler. We are defining where freedom is valuable and where it creates structural risk.

Fewer edges are more than a pretty diagram

“Modularity” quickly becomes abstract. The question gets more interesting when we look at dependencies.

Imagine a business module with a clearly defined responsibility, control over its own state, only a few dependencies, and a small public contract through which it can be used.

Its structural neighborhood is limited.

For a change inside it, perhaps five files, two contracts, and one external adapter are relevant. The agent can of course still inspect additional areas. But the architecture already provides a strong prior about where relevant information should even be located.

The intuition is simple:

fewer allowed edges
↓
fewer structural alternatives
↓
fewer repository areas potentially relevant
↓
smaller decision space

This is not a mathematical law. A small module can be extraordinarily complex from a business perspective. A system with few dependencies can be poorly documented. And low coupling guarantees neither correct requirements nor correct code.

But architecture changes the number of plausible structural paths.

A strongly coupled area, by contrast, has many entry points and many exit points. Changes may affect State, Services, Utilities, other Features, and global mechanisms. Even if only three files eventually need to change, a much larger environment is initially plausibly relevant.

The agent has to rule more of it out.

For agentic work, that is why I find Loose Coupling at least as interesting as modularity as an abstract goal. Low coupling does not only reduce change radius and coordination effort for humans. It also limits the set of structural relationships an agent has to reason about during exploration.

Classical research studied this direction long before LLMs. Stevens, Myers, and Constantine described Structured Design as early as 1974 as an approach to reducing program complexity through functional modules and thereby making coding, debugging, and modification easier. Cohesion and Coupling became central concepts of software design from there.

Here too, it would be ahistorical to claim that these authors developed principles for coding agents.

They developed principles for software. That is precisely why the modern observation is interesting: properties that help humans understand systems locally and change them in a controlled way can also become relevant for agents.

SCS as an illustrative example

A Self-contained System is a useful mental model for this.

SCS architecture describes business-oriented, largely autonomous systems that own their own data and business logic, can fulfill their purpose as independently as possible, and deliberately reduce coupling to other areas. Shared business logic should be avoided, and synchronous dependencies should be limited where sensible.

For our argument, it does not matter whether a concrete project actually uses SCS.

What is interesting is the shape of the boundary:

┌───────────────────────────────┐
│          business area        │
│                               │
│  UI                           │
│  Business Logic               │
│  State / Data                 │
│  technical adapters           │
│                               │
└───────────────┬───────────────┘
                │
        few explicit Contracts
                │
                ▼
          other systems

Such an area gives an agent a relatively clear workspace. The business responsibility has a place. Data ownership has a place. External relationships are limited and visible.

I am not aware of any robust study from which one could conclude that Self-contained Systems are scientifically proven to be “better for LLMs.” That would be far too strong a claim.

Here, SCS is simply an architectural example of something more general: local responsibility and few explicit edges.

The same principle can apply just as well inside a modular monolith.

The Big Ball of Mud provides contradictory evidence

I have already discussed the opposite case in detail elsewhere on this website: the Big Ball of Mud.

Foote and Yoder used the term for a system whose structure emerged loosely or incidentally and is shaped more by short-term expediency than by a coherent design. They describe uncontrolled growth, repeated pragmatic repairs, broadly shared or duplicated information, and a structure that either was never clear or eroded over time.

For agentic work, one property of this is particularly interesting to me:

The repository itself becomes contradictory evidence.

everything knows everything

many possible paths

contradictory patterns

historical special cases

unclear ownership

implicit dependencies

An agent may not find too few examples there, but too many.

There are five ways to access an API. Three models for State. Two Features interact through their public Contracts, while four others import internals. A new pattern was introduced without fully replacing the old one. Some exceptions now appear more frequently than the original rule.

That shifts the task from implementation to interpretation.

Which code is the model?

Which file is historical baggage?

Is a deviation intentional or accidental?

Is the most common pattern the intended one or merely the oldest one?

Article 6 already described how plausible local decisions can contribute to drift. We do not need to derive that mechanism again here. The new consequence is:

Architecture is a mechanism for reducing the space in which drift can occur in the first place.

If you want to explore the connection to the Big Ball of Mud in more depth, you can find it in my existing Big Ball of Mud series in AI and the Big Ball of Mud.

The idea is older than most of our programming languages

I find the historical arc of this discussion remarkable.

In 1972, David Parnas considered two different ways of decomposing a system into modules. His central observation was not simply “modules are good.” What mattered was the criterion by which they were formed. Modularization should improve flexibility and understandability; Information Hiding should hide design decisions—especially difficult decisions or those likely to change—behind suitable module boundaries.

The idea behind it still feels surprisingly modern today:

A change should not require the entire system to be understood again.

Specific knowledge should have an owner.

Other areas should know as little as possible about internal decisions.

Interfaces should carry stable assumptions, not arbitrary implementation details.

Two years later, Structured Design formulated related goals through functional binding within modules and relationships between modules that were as controlled as possible. The terminology and methods have changed repeatedly since then. Object orientation, component models, services, domain-driven design, microservices, modular monoliths, and many other architectural approaches have added different abstractions.

The underlying desire has remained remarkably stable:

understand locally
change locally
limit global consequences

Coding agents now introduce new technical constraints: limited context, repository retrieval, tool calls, probabilistic solution paths, and the need to infer structural rules from existing code.

But they encounter a system problem that is much older.

The properties that have helped humans understand large systems and change them safely for decades are also interesting for agents.

Not because Parnas anticipated AI.

But because a repository is easier for an agent to work with when its structure separates relevant from irrelevant relationships.

Architecture work does not disappear without architects

At this point, one could turn my personal project experience into a convenient role argument.

“See? That’s why every project needs a Software Architect.”

That would be too simple for me.

A project does not necessarily need a person with exactly that job title. Architectural responsibility can live with a Tech Lead, be shared within a team, be distributed through platform ownership, or be institutionalized through clear engineering processes and technical constraints.

What does not work, however, is the idea that architectural decisions disappear because nobody is officially responsible for architecture.

Architecture work does not disappear because nobody carries the role of “architect.” Architectural decisions are simply made elsewhere—often locally, implicitly, and inconsistently.

Every new import makes an architectural decision.

Every additional writer to State makes one.

Every new Shared Library makes one.

Every direct access across a boundary that should exist makes one.

The only question is whether these decisions emerge consciously within a shared framework or randomly across individual tickets.

For me, architecture therefore does not require a specific job title, but it does require responsibility.

Architecture is risk management

I have a comparatively strict personal standard for consistency. That probably becomes obvious quickly in my projects.

It bothers me when one Feature is structured differently from all the others. It bothers me when a Layer no longer has a clear Responsibility. It bothers me when State has no clear Owner and when a Dependency crosses a boundary “just this once.”

That can easily look like architectural perfectionism. For me, something else lies behind it now.

Architecture is risk management, not a perfection contest.

An architectural rule is valuable if it makes a problematic future state less likely or completely rules it out.

For example:

Feature A may not import Feature B internally.

This rule does not guarantee good software. But it reduces the risk of Cross-Feature Coupling gradually growing over years.

Presentation may not call Infrastructure directly.

This rule also says nothing about the quality of the Business Logic. But it reduces the number of places where UI orchestration, technical access logic, and business decisions can become mixed together.

Or:

State has one clear Owner.

That does not solve every state-management problem. But it reduces competing truths and the number of possible write paths.

That is the standard by which I find architectural rules more interesting than diagrams.

Which risk do they reduce?

If I cannot answer that, perhaps the rule is not especially valuable either.

Architecture is the grammar of a codebase

In the previous article, I formulated one of my personal principles:

The project should read as if one developer had written it.

From an architectural perspective, I would sharpen that a little further today.

Architecture is the grammar of a codebase.

A language does not require every sentence to be identical. Authors can express different content, choose different words, and phrase problems differently. But the language has rules: certain constructions belong to it, others do not.

Applied to a codebase, this means two agents do not have to generate the same local implementation. Agent A may write a small helper function differently from Agent B. Agent C may choose another algorithm inside its module as long as both variants satisfy the same invariants.

What I want to avoid is every model inventing a new system grammar.

               Architecture
                    ↓
        ┌───────────┼───────────┐
        ↓           ↓           ↓
     Agent A     Agent B     Agent C
        ↓           ↓           ↓
      different local solutions
                    ↓
         same structural grammar

That is precisely where architecture helps deal with model variance.

Different generation does not have to lead to different system structure.

Invariants instead of micromanagement

The distinction matters because Architecture Constraints can otherwise quickly tip into another problematic direction.

If I prescribe every method call, every helper function, every intermediate file, and every implementation step to an agent, I have also reduced its solution space.

But then I am mainly using an agent as a very expensive keyboard.

The more interesting form of constraint is:

Invariant:
Presentation may not call Infrastructure directly.

open:
How a local helper function is implemented
inside the allowed layer.

Or:

Invariant:
A business module may only be used through
its Public Contract.

open:
How the module fulfills that Contract internally.

OpenAI describes a very similar separation in its agent-first practice report: invariants are fixed and mechanically enforced, while concrete implementation details are deliberately left open. For example, the team requires data shapes to be parsed at system boundaries but does not prescribe which specific library must be used.

That is the right level of abstraction for me.

Architecture fixes the expensive decisions and leaves local decisions open.

“Expensive” here does not necessarily mean financially expensive. It refers to decisions with a high structural follow-up risk: Dependency Direction, Ownership, module boundaries, Contracts, or the question of where a particular kind of responsibility is allowed to live at all.

Re-deciding those things every time produces little value and a lot of variance.

Explain, expose, and enforce architecture

Explain architecture

This brings us to a practical problem.

An architecture can exist and still be almost invisible to an agent.

The first level is therefore documentation:

Architecture Docs
ADRs
Agent Files
Layering descriptions
Dependency Rules

Documentation matters. It can explain why a boundary exists, which trade-offs were considered, and which cases are deliberately handled differently.

But text has limits. It can be overlooked, become outdated, or be misunderstood. And it can disappear in a large context between the task description, code, tool output, and other documentation.

OpenAI reports, for example, that a large monolithic AGENTS.md did not work in its own project for exactly this reason: the amount of guidance competed with the task, code, and relevant documentation for limited context. Instead, a short agent file serves more as a map to deeper repository documentation.

Documented architecture is therefore necessary, but not the strongest form of a constraint.

Make architecture visible

The second level is architecture that is already recognizable in the repository.

For example:

orders/
  presentation/
  application/
  domain/
  infrastructure/

Or:

billing/
catalog/
identity/
orders/

with clear Public Contracts between the modules.

Again, the exact folder structure is not the point. What matters is that physical structure and architectural structure do not contradict each other.

If all Infrastructure Adapters contain only technical transformation and I/O, the repository creates local evidence.

A new adapter with Business Rules stands out.

If all Features have a small public entry point and internals are not imported directly, a direct Deep Import looks unusual.

If every State has exactly one Owner, a second Writer looks suspicious.

Consistency makes deviations visible.

That is one of the reasons I like “boring” layers.

An Infrastructure Layer is allowed to be boring. An API Adapter is allowed to look predictable. That predictability is valuable precisely because an agent does not have to infer the Responsibility from fifty creative variants first.

The more consistently a codebase expresses its own grammar, the more useful the existing code becomes as evidence.

Make architecture executable

The third level changes the quality of the rule once again.

We no longer merely explain:

Feature A should not import Feature B internally.

We let an Architecture Test reject that import.

We no longer merely write:

Presentation may not use Infrastructure.

A Dependency Constraint makes that state invalid.

We do not merely hope that Contracts are followed.

Types, schemas, tests, and CI verify them.

Depending on the technology, different tools are available:

• Dependency Constraints,
• Architecture Tests,
• Import Restrictions,
• Linter Rules,
• module boundaries,
• type and schema checks,
• Structural Tests,
• CI verification.

The mechanism matters more than the specific tool.

explain architecture
↓
make architecture visible
↓
make architecture executable

At the final level, an architectural rule becomes part of the verification loop.

The strongest architectural rule is the one an agent cannot violate unnoticed.

That is qualitatively different from an instruction:

Please do not do X.

Guidance becomes:

X is not a valid state of the system.

A coding agent may try to violate the boundary. The linter disagrees. The Architecture Test fails. The build produces new evidence. The agent can correct itself.

Architecture is no longer only Context.

It becomes executable feedback.

A current practice example from OpenAI’s agent-first development

This is exactly what makes OpenAI’s report Harness engineering: leveraging Codex in an agent-first world so interesting to me.

The report is not a scientific study and describes a single, unusually agent-centric internal software project. Its findings therefore must not be read as a universal law.

As a practical example, however, it is remarkable.

OpenAI describes fixed layers within business domains, strictly validated Dependency Directions, and a limited set of allowed edges. Cross-cutting Concerns enter the domains through an explicit mechanism; other dependency paths are forbidden. Custom Linters and Structural Tests enforce these rules automatically. At the same time, the team explicitly formulates the principle of enforcing invariants instead of micromanaging implementations.

The report derives a strong practical experience from this: agents worked particularly effectively in environments with strict boundaries and predictable structure. In its specific project, OpenAI even describes these constraints as a prerequisite for achieving high throughput without structural decay or Architecture Drift.

I would not derive from this:

OpenAI has proven:
strict layering = the best AI architecture.

The report did not prove that.

What it shows is something more interesting: a team that develops software consistently agent-first and produces exceptionally high generation throughput invests very early in few allowed dependency paths and mechanically verifiable invariants.

That is remarkably close to the mechanism we derived here.

Old principles meet new context problems

Current research on coding agents is now investigating precisely the places where repository structure becomes relevant: Context Selection, Fault Localization, Repository Navigation, and Dependency Reasoning.

The results do not prove that a “clean” architectural approach automatically produces better agent outcomes.

But they do show that structural information can be practically valuable for agents.

The 2026 preprint Repository Intelligence Graph, for example, gives agents an architectural map deterministically derived from build and test information. In the study with three commercial agents and eight repositories, mean accuracy on structural questions improved by 12.2 percent relative, while completion time fell by 53.9 percent. At the same time, the study has significant limitations: it uses only eight repositories, seven of them synthetic, and for some agents measures completion time rather than token usage. It also studies the representation of existing architecture, not the quality of the architecture itself.

LLM Agents Can See Code Repositories, accepted for ASE 2026, investigates another form of structural support. Visual repository graphs were provided in addition to the normal text interface. In the evaluated settings, input token usage fell by up to 26 percent while issue-resolution accuracy was preserved or improved. Purely visual work, by contrast, performed worse and increased token cost. Again, the conclusion is not “modular architecture needs 26 percent fewer tokens.” The study investigates the representation of repository structure for multimodal agents.

DyRetriever, also accepted for ASE 2026, uses Partial Dependency Graphs to retrieve relevant context along dependencies for repository-level code generation. Compared with the evaluated RAG baselines, the authors report relative Pass@1 improvements of 25.63 and 59.73 percent on CoderEval and DevEval respectively, as well as a 7.4x speedup over baselines with static dependency-graph construction. That is evidence that dependency structure can help with context retrieval—not that a particular software-architecture pattern is superior.

Other recent work fits the same picture. Agent Retrieval Bench isolates the question of whether an agent finds the files it needs next at all. In 27 to 35 percent of the evaluated logged trajectories, not a single Gold File was found; at the same time, retrieval-based initial context required less subsequent exploration than random irrelevant context in a controlled intervention.

RepoMirage in turn reports that agents can degrade significantly on tasks with greater repository-context reasoning demands and describes a pattern the authors call exploration drift: agents inspect more repository context but do not reliably turn that exploration into correct structural understanding. A two-stage structure-first approach improved results in the evaluated settings. However, the work is a 2026 preprint or workshop contribution and not evidence for general architectural rules.

The research therefore does not yet answer our architecture question directly.

But it makes visible why the question is interesting.

Repository Navigation
Context Selection
Dependency Reasoning
Fault Localization
limited Context

are new technical problems of coding agents.

clear modules
few Dependencies
Information Hiding
stable Contracts
local responsibility

are very old software-engineering answers to the question of how much of a system one has to understand in order to change part of it safely.

These two lines are beginning to meet.

Does a smaller solution space also mean fewer tokens?

This connection leads me to another hypothesis.

Take two systems under conditions that are as comparable as possible:

same model
same agent
same tooling
same test quality
same linters
comparable task

System A has strong coupling, many possible dependency paths, and unclear ownership.

System B has clear boundaries, few allowed dependency paths, and clear ownership.

My computer-science intuition is:

larger structural decision space
↓
more possible exploration
↓
more relevant candidates
↓
potentially more files / tool calls / Context
↓
more wrong paths
↓
more rework

compared with:

smaller structural decision space
↓
fewer structural candidates
↓
potentially less exploration
↓
smaller relevant working set
↓
fewer wrong paths
↓
potentially lower overall cost

That seems mechanically plausible to me. Still:

So far, I have not found a robust direct measurement for it.

The current papers measure adjacent effects. Structured repository representations can make exploration more efficient. Dependency-aware retrieval can select relevant context more effectively. The paper What Context Does a Coding Agent Actually Need to Act? even shows, under fixed oracle localization, that compressed context in its SWE-bench Verified setup can match whole-file results with far fewer context tokens. But precisely this work deliberately holds localization constant and changes the code representation. It therefore also does not investigate whether a better modularized codebase itself reduces token demand.

So the careful statement is:

Under otherwise equal conditions, a smaller structural decision space could require less exploration and therefore lower inference cost. Mechanically, the hypothesis is plausible. Direct empirical evidence is still missing.

I would like to test it in a controlled way one day.

A comparison between two variants of the same application would be more interesting than the convenient comparison between a Big Ball of Mud without tests and a perfectly documented modular system with a complete agent harness. Otherwise, so many variables change at once that in the end nobody knows what was actually measured.

The more interesting cost metric lies beyond the first run

Even if we measure this hypothesis someday, I would not only look at the token count of a single generation.

An agent can produce a cheap, fast solution with very little context that then requires three repair passes.

Another run uses more context initially, understands the relevant dependencies better, and produces an acceptable change on the first attempt.

That is why I am more interested in the long term in:

Cost per verified, acceptable change.

That includes not only the tokens of a single answer, but exploration, tool calls, tests, corrections, and rework until we reach a state we can actually accept.

That deserves an article of its own. I will return to it in more detail in “The Economics of Agentic Work.”

For this article, the hypothesis is enough: architecture could reduce not only structural risk. Under comparable conditions, a smaller decision space could also become economically interesting.

It is just that this second claim is currently much less well supported than the first.

Throughput makes boundaries more valuable

That brings us back to the problem with which this article began.

Humans created Architecture Drift long before coding agents existed. Humans turned Shared Services into dumping grounds, broke Feature boundaries, and introduced three State-management patterns side by side, justifying every exception with an urgent ticket.

AI does not create a new category of structural mistake. It changes how quickly such decisions can emerge.

high change throughput
+
large structural decision space
=
more opportunities
for inconsistent local decisions

This is not a doom thesis.

On the contrary: I am impressed by what coding agents can do today and use them intensively. That is exactly why I care about how we translate their speed into systems that remain understandable even after another thousand changes.

If architecture sets no boundaries, AI can scale structural arbitrariness alongside productivity.

The higher the throughput becomes, the less I want to rely on every individual run intuitively reconstructing the same unwritten architecture.

I want the system itself to say what is valid.

Architecture is not an instruction for every sentence

One important distinction remains: I am neither arguing for surrounding coding agents with rules until no decision remains, nor for forcing every application into the same layering.

A system needs understandable, consistent, and verifiable boundaries. Which concrete architecture creates those boundaries depends on the problem.

A small CRUD service may need far less structure than an application with twenty business domains. A modular monolith can be the right answer, as can an SCS-oriented decomposition; layering can help or merely add overhead. Architecture Constraints are not an end in themselves.

They answer a risk question:

Which structural decisions
should we not renegotiate
with every change?

Those are the places where boundaries should be strong.

Within those boundaries, the agent may work.

That is also the connection to Article 5: different solutions remain allowed. We only constrain those dimensions in which variation produces no new insight but additional system variance.

Architecture does not eliminate variance. It eliminates unwanted variance.

The solution space becomes smaller

The last articles in this series now form a fairly clear picture. Article 4 showed that an agent can only work with the context available to it; Article 5 showed that it can choose different solution paths within that context; and Article 6 showed that a plausible path can still be wrong. Architecture replaces neither context nor verification, but it can narrow the relevant workspace and mechanically catch certain classes of structural error. Article 7 introduced requirements as the first boundary.

Now the second one is added:

Requirements
→ What must hold?

Architecture Constraints
→ Which structural paths are allowed?

That does not determine the agent.

It gives it a smaller, more meaningful workspace.

And that is exactly the role of good architecture for me in agentic software development:

Architecture reduces the decision space of a coding agent.

It does not do this by prescribing every step.

It does it through modules, Contracts, Ownership, Dependency Direction, and invariants.

Through structures that make visible what belongs together.

And ideally through rules that are not merely described somewhere but are checked by the system itself.

The project should still read as if one developer had written it—even if Agent A, Agent B, and Agent C worked on it.

Perhaps good architecture therefore does not become less important in a world of increasingly capable coding agents.

Perhaps only where its leverage lies shifts.

Less in explaining to every developer how to write their code.

More in shaping the space so that many different actors—humans and agents alike—can work locally without reinventing the global structure with every feature.

Architecture thus defines a kind of boundary for what code is allowed to do inside a system.

In the next article, we have to look at another boundary.

Because an agent does not only modify code. It can read repository contents, use tools, and process information across system boundaries.

Then the question is no longer only:

Which Dependencies may code cross?

but:

Which information is an agent allowed to see?

And which Trust Boundaries
may that information cross?

That is what comes next: Privacy, Confidentiality & Trust Boundaries.

Sources and context

• David L. Parnas – On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM 15(12), 1053–1058, December 1972, DOI 10.1145/361598.361623. Parnas examines different criteria for module decomposition and argues for modularization in terms of understandability, flexibility, and Information Hiding, among other things. In this article, the work serves as the historical basis for the idea that good boundaries localize knowledge and the consequences of change. It contains no claim about LLMs or coding agents; that connection is a contemporary inference.

• W. P. Stevens, G. J. Myers, L. L. Constantine – Structured Design. IBM Systems Journal 13(2), 115–139, 1974, DOI 10.1147/sj.132.0115. The paper describes techniques for reducing program complexity through functional modules and belongs to the classic sources behind later discussions of Cohesion and Coupling. It is used here to show that controlled dependencies are not an AI-specific invention. It likewise allows no direct conclusion about agent performance.

• Brian Foote, Joseph W. Yoder – Big Ball of Mud. PLoP ’97, Technical Report WUCS-97-34; later a chapter in Pattern Languages of Program Design 4, Addison-Wesley, 2000. Foote and Yoder describe loosely or haphazardly structured systems whose organization emerges more from pragmatic growth and repair than from coherent design. The article uses the Big Ball of Mud as the counterexample to a bounded structural solution space. The work itself of course does not study coding agents.

• OpenAI – Ryan Lopopolo: Harness engineering: leveraging Codex in an agent-first world. February 11, 2026. The engineering report describes an internal software project generated entirely by agents. Particularly relevant are fixed layers, strictly validated Dependency Directions, few allowed edges, and Custom Linters and Structural Tests. OpenAI derives from this the practical rule of enforcing invariants rather than micromanaging implementations. It is a valuable practice report, but not a controlled scientific study and should not be generalized into a universal architecture law.

• Self-contained Systems – official SCS architecture description. In this article, SCS serves solely as an illustrative example of business autonomy, owned data and Business Logic, and few external dependencies. No scientifically proven superiority of SCS for LLMs is inferred from it.

• Tsvi Cherny-Shahar, Amiram Yehudai – Repository Intelligence Graph: Deterministic Architectural Map for LLM Code Assistants. arXiv:2601.10112, 2026. RIG gives coding agents an architectural map derived from build and test information. Across eight repositories and three commercial agents, the authors report higher accuracy and substantially lower completion time on structural questions. Seven of the eight repositories are synthetic; for some agents, time is used as a proxy rather than actual token consumption. Most importantly, the work studies an explicit representation of architecture, not the quality of the underlying software architecture.

• Dongjian Ma et al. – LLM Agents Can See Code Repositories. ASE 2026 / arXiv:2606.14061. The study investigates visual repository graphs as a complement to text interfaces. In the evaluated settings, input token consumption fell by up to 26 percent while accuracy was preserved or improved; purely visual use performed worse. This supports the claim that structured repository information can make exploration more efficient. It does not prove that a more modular architecture itself saves 26 percent of tokens.

• Zhongxin Liu et al. – Effective and Efficient Context Retrieval via Partial Dependency Graph for Repository-Level Code Generation. ASE 2026 / arXiv:2608.01927. DyRetriever follows dependencies via an on-demand Partial Dependency Graph to select relevant repository context. The results on CoderEval and DevEval support the importance of dependency-aware retrieval. The work studies a retrieval method, not the effect of different software architectures under otherwise identical conditions.

• Bowen Qin, Yi Xie – Agent Retrieval Bench: Evaluating Repository Context Retrieval for Coding Agents. arXiv:2607.24882, 2026. The benchmark isolates Context Acquisition before actual patch generation. It shows, among other things, that real agent trajectories often fail to retrieve relevant files completely and that good initial context can reduce subsequent exploration. The benchmark measures retrieval; better retrieval values do not automatically mean correct patches or better architecture.

• Brian Sam-Bodden – What Context Does a Coding Agent Actually Need to Act? arXiv:2607.09691, 2026. The work keeps localization of the change site fixed through an oracle and then studies different context representations on SWE-bench Verified. Compressed context can be significantly more token-efficient in this setup. Precisely because localization is fixed, the study provides no direct evidence for the hypothesis that “a smaller architectural decision space causes fewer tokens.” It is therefore an adjacent, not confirming, source.

• Hanyu Li et al. – RepoMirage: Probing Repository Context Reasoning in Code Agents with Perturbations. arXiv:2605.26177, 2026. The authors study repository-context reasoning under structure-changing, semantics-preserving perturbations and describe exploration drift as an observed problem. A structure-first prototype improves results in their experiments. The work is a current preprint or workshop contribution; its findings should therefore be read as early evidence rather than as an established general law.