Blog · September 16, 2026

An agent that reads faster still can't find what was never written down.

Reading code does not scale. Neither does delegating it.

A million-line source tree on the left versus a change-scoped architecture graph on the right: payment may reach ledger only through a declared queue; a direct call is not declared.
Read the declared graph for this diff, not the whole tree.

Software engineering has not changed radically. It has always been mainly about understanding code. What's changed is the ratio: the volume of code nobody understands is now growing faster than any team can read it, and agents are adding to both sides of that ratio at once.

The industry's answer is delegation. The codebase is too big to read, so let the agent read it for you.

That's the wrong prescription. Here's why.

Reading was never the job

Reading code answers what does this do. It cannot answer what is this allowed to do.

Every senior engineer knows this from the first week on a new system. You read for days, and what you're actually doing is reconstructing intent: which services are supposed to talk to each other, which boundaries are load-bearing, which controls exist because an auditor once asked a question. None of that is in the code. It's in someone's head, a stale wiki, or nowhere.

An agent reading a million lines is doing the same reconstruction. Faster, with more confidence, and without telling you which parts it guessed. That isn't augmentation. It's moving the problem onto a reader that can't tell you where it got the story wrong.

It's archaeology at machine speed.

A senior engineer spending days reconstructing that payment talks to ledger via a queue, versus an agent doing the same reconstruction in seconds and proceeding without saying which parts it guessed.
Delegation moves the reconstruction. It does not write down what was missing.

What scales is context, not reading

What actually scales understanding is context the reader doesn't have to re-derive.

For architecture, that context is the intended system: which components exist, which relationships are permitted, which controls apply on which paths. When that intent lives in a machine-readable model — FINOS CALM, an open standard — three things become possible that reading alone never gave you.

You stop reading the whole thing. A change to the payment service doesn't require understanding the entire graph. It requires the nodes the diff touches, the relationships those nodes are allowed to have, and the controls on them. That's a bounded context, and it fits in a few kilobytes instead of a few hours.

A CHANGE-SCOPED CONTEXT, NOT A CODEBASE

diff touches:      payment-service
permitted egress:  settlement-queue        (AMQP)
not permitted:     ledger-service          (no declared relationship)
controls on path:  settlement-event-schema

Understanding becomes checkable. If intent is explicit, a proposed change can be evaluated against it deterministically. A diff that introduces a direct call from payment to ledger isn't a judgment call in review. It's a violation, with the control named and the path that already exists, before it lands.

Did the agent actually use it? This is the part delegation skips entirely. If you hand an agent context, you should be able to verify the change it produced was made with that context in hand. ArchRails keeps a signed record of that check. Context that can't be shown to have been used is context that was probably ignored.

Same model, both readers

The mistake underneath "delegate to AI" is treating the agent as a different kind of reader that needs different tooling. It doesn't. The human reviewing the pull request and the agent that wrote it need the same thing: the intended architecture, scoped to the change, in a form that can be checked rather than trusted.

A CALM architecture file feeds the same model to a human reviewer and a coding agent; both diffs pass through one gate.
Understanding the guidance and passing the gate are the same act.

Not a summarizer. Not a bigger context window pointed at more code. One source of architectural intent that both readers pull from and both get held to.

That's what ArchRails does. The context an agent receives and the gate that judges its output derive from one CALM model, so understanding the guidance and passing the gate are the same act. When they come from different places, agents learn to satisfy the gate and ignore the guidance.

The stakes are different now

Pre-AI, misunderstanding a codebase cost you a bad change a week. Now it costs you a bad change every few minutes, across every repository an agent touches, each one written by a reader that was confident and wrong in the same way.

Reading code has never scaled, and it never will. The answer was never to read faster. It's to stop making everyone, carbon or silicon, reconstruct what should have been declared.

Declare it in CALM. Enforce it with ArchRails.

Earlier: Get the Architecture Out of Your .md Files — why architecture trapped in markdown cannot be checked.

ArchRails is built on the FINOS CALM open standard. Learn more about CALM at the FINOS Architecture as Code community.

The product · More posts