When you stop reading code

Introduction

Coding agents are changing not only how software is written, but also how software is reviewed. When an agent implements a feature, runs the tests and produces the expected behaviour, there is a growing temptation not to inspect every line of code it generated.

And increasingly, that may be the rational thing to do. If software production scales through AI, humans cannot remain the final line-by-line reviewers of everything machines create. The amount of code will simply become too large.

But that creates an obvious problem. If we stop reading all the code, how do we remain confident that the system is still well built? This is one of the areas where we believe explicit architecture can become an important quality mechanism.

Working code is not necessarily good software

Tests are essential, but they answer a specific question:

Does the software behave as expected?

They do not necessarily tell us whether the system is structured correctly. We encountered a simple example ourselves while developing with coding agents. One vmblu node needed functionality provided by another node. The system worked and the tests passed. But instead of communicating through the connection defined in the architecture, the generated implementation called code in the other node directly.

Functionally, nothing was wrong. Architecturally, something important had changed. A dependency had appeared that was not visible in the model.

That kind of problem becomes especially dangerous in agent-generated software because it can accumulate silently. Each individual shortcut may appear harmless, while the overall system gradually becomes more coupled and harder to understand.

Architecture as a quality boundary

vmblu makes the intended structure of the system explicit. Nodes have responsibilities. Interfaces and pins define how they communicate. Connections describe which components are allowed to interact. This means that the architecture can be used for more than design.

It can also be used to inspect the implementation. If node A is connected to node B through a defined interface, source analysis verifies that the implementation follows that path. If A starts importing B's internal implementation directly, vmblu flags it.

If a node sends a message for which no architectural connection exists, vmblu detects it. If a component suddenly starts accessing the filesystem, an external API or a database that was not part of its intended responsibility, that can become visible as well.

The architecture therefore becomes a set of constraints against which generated code can be checked.

Three levels of verification

We see software quality increasingly being verified at several levels.

• Tests verify behaviour.
• Traditional tooling verifies implementation details: type correctness, security problems, dependency vulnerabilities, complexity and coding standards.
• vmblu can verify architectural conformance.

These are different concerns.

A system can pass its tests and still have poor architecture. It can have beautifully formatted, type-safe code and still contain the wrong dependencies. Architectural verification asks a different question:

Is this still the system we designed?

That question becomes more important as coding agents become capable of changing larger parts of the application autonomously.

Intended, implemented and observed architecture

There is an interesting opportunity to go even further.

With vmblu, we can potentially compare three representations of a system. The intended architecture is the model created by the developer. The implemented architecture can be derived through static analysis of the source code. The observed architecture can be derived from what actually happens in the running application. If all three agree, confidence increases substantially.

Suppose the model says that an Order node requests payment through a Payment interface. Source analysis confirms that the Order node uses that interface. Runtime observation confirms that requests actually travel through the expected connection.

The architecture, implementation and behaviour are aligned.

Now imagine that source analysis discovers a direct import from Order into the internal implementation of Payment. The application may still work perfectly. But vmblu can tell us that the implementation has diverged from the design. That is exactly the kind of problem humans are unlikely to discover if nobody is reading the generated code carefully.

Quality at the level humans can still understand

This does not mean that architecture replaces code quality tools.

Agents can still generate inefficient algorithms, poor database queries, unsafe input handling, unnecessary complexity or subtle security vulnerabilities. Linters, type systems, tests, dependency scanners and security analysis remain essential. But they operate primarily at code level. vmblu operates at system level. That distinction matters.

As AI generates more software, humans will increasingly need to review abstractions rather than implementations.

Instead of asking: Is this function written well?

we may increasingly ask:

• Is this component doing what it is supposed to do ?
• Are its dependencies appropriate ?
• Is communication happening through the interfaces we designed ?
• Has this part of the system acquired responsibilities it should not have ?
• Does the running application still correspond to the architecture ?

These are questions a developer can realistically answer even when the underlying implementation contains hundreds of thousands of lines of agent-generated code.

From code review to system review

Traditional software development places enormous emphasis on code review. That made sense when humans wrote the code. In an AI-driven development environment, code review will not disappear, but it cannot remain the only governance mechanism.

The unit of review has to move upward. Developers will increasingly review components, interfaces, dependencies, capabilities, tests and runtime behaviour. The implementation itself becomes something that is continuously checked by machines.

This is an important part of what we want vmblu to become. Not a tool that claims to guarantee that every line of generated code is perfect. A tool that helps ensure that, even when you stop reading every line, you still understand and control the system being built. Because as coding becomes easier, keeping software structurally sound may become one of the hardest parts of the job.