How many of your architecture rules break the build?

· Published · 2 min read

Which architecture allows robust, continuous use of AI even as a project scales?

The one that provides the maximum number of rules a machine can verify, deterministically.

Verbosity is no longer the problem

Structured architectures (Clean Architecture, Hexagonal, DDD…) are often criticised for being verbose. With AI, that is less and less of a problem. The cost of writing is collapsing… while the cost of reading and verifying is exploding.

That is where an ultra-standardised architecture becomes an asset, despite its potential verbosity.

An AI produces code that looks like correct code… and very often is not. The defence that scales is not a line-by-line review (you will not keep up, and nobody is infallible) but a harness that validates whether the code is correct or not.

An intention versus a constraint

Example rule: domain code imports nothing from the infrastructure (if you are doing Clean Architecture or Hexagonal, for instance).

That rule in a README or a CLAUDE.md is an intention. Better than nothing… but often unread or ignored.

Placed in a config, it becomes a constraint:

// eslint.config.js, applied to src/domain/** files
"no-restricted-imports": ["error", {
  patterns: ["**/infrastructure/**", "pg", "express"]
}]

The rule can no longer be bypassed.

The reflex for starting a project in 2026

It was already true before… but it is even more true today.

Once you have chosen an architecture that fits the project (a CRUD does not need Clean Architecture plus DDD…), it must be standardised to the extreme.

For every rule:

  • The holy grail: make it impossible to bypass, as in the example above.
  • The fallback (some rules simply cannot be enforced by a harness): a regularity so strong that the prompt fits in two lines, and any divergence is obvious at a glance.

Tomorrow, ask yourself: how many of your architecture rules break the build?

The others are actually intentions.

Turning intentions into constraints is one of the foundations I lay on every project.

dependency-cruiser applies the same idea to the whole import graph.

The same reflex applies to isolating customer data in a SaaS: an omitted tenant must return zero rows, not a leak.

An opinionated framework already enforces some of these constraints before you write a single one yourself.

An ADR documents the intentions that cannot become a constraint: it will not stop a bypass, but at least it leaves a written, dated trace of why the rule exists.

PS: a rule that passes does not mean the rule is good. Thinking and making the right choices for each project’s context is not optional.

I pushed this reflex to the extreme in a zero hand-written code experiment.

Conversely, writing the rule in capital letters in a prompt never turns it into a constraint.

The gain is not just quality: a verifiable constraint also lets you use a much cheaper model without losing reliability.

Sources