Why vmblu

Software Needs an Explicit Architecture Again

Coding agents have accelerated writing code dramatically. It is a sobering experience to witness how fast and accurate 'vibe coding' can convert a prompt into working software. And coding agents will only get better: faster, longer contexts, less mistakes.

But this exposes a deeper issue with software development today: architecture, control, and safety become the real bottlenecks.

Faster code generation makes architecture, control, and safety the real bottlenecks.

• How do we verify that what the machine produced truly matches our intent ?
• How do we ensure there are no unsafe lines hidden in a sea of files ?
• And what about code maintenance ?

A 'vibe coded' game of snakes and ladders you can just throw away if it turns into slop after too many changes, but for a business application you want to be able to reliably maintain and build on it over time.

If we want to fully benefit from faster AI-assisted development, we need tools that provide structural insight into what is being built. vmblu is designed for exactly that purpose.

It makes the architecture of a system a first-class artifact where functionality and contracts are formally defined. It enables verification against those contracts. And it allows runtime interception of behavior that is not explicitly permitted.

At the same time, software itself is evolving: the intelligence of applications increasingly resides in the agent that uses the system, not just in the code. vmblu is explicitly designed with this shift in mind. Well-defined functional blocks with formalized interfaces become ideal tool definitions for agents, without sacrificing correctness or safety.

Problem Framing

Coding agent software development faces a structural challenge:

• Architecture Is Implicit. Most applications describe architecture informally: prompts, diagrams, README files, or tribal knowledge. The actual wiring lives only in code.

• Contracts Are implicit. What code expects or needs to deliver is often unclear or burried in the code and the blast radius of changes to a system is often unclear.

• Security and Observability Are Afterthoughts - When boundaries are unclear, enforcing policies and auditing behavior becomes difficult.

For human-written code, teams rely on reviews, testing, and accumulated knowledge to manage these risks. We could apply the same rigor to AI-generated code, but then much of the productivity gain disappears, because teams must first reconstruct and understand what was generated.

We need structural tooling.

Architecture as Executable Blueprint

vmblu is a collection of tools, formats and prompts designed to build, understand and maintain software created with coding agents. The central idea of vmblu is simple: make the architecture explicit, formal, and executable.

Functionality lives in nodes. Nodes expose formal interface contracts. The blueprint defines how the system is wired.

This explicit architecture is ideal as a context for a coding agent: it does not need to have the entire code base in its context to make decisions but can reason at a higher more abstract level.

vmblu includes a graphical editor that makes the architecture visually clear for the humans in the loop, simplifying reasoning and architectural change.

The blueprint guides implementation and as the system evolves, architecture and code evolve together, but always remain synchronized.

The blueprint is not documentation.

This blueprint is not documentation, the running system is generated directly from it, and changes take effect immediately. Formal contracts defined in the architecture are used to verify implementations.

Because the architecture is explicit, adding new functionality or replacing implementations becomes straightforward.

vmblu also generates a testing harness directly from the architecture, enabling structured node-level tests.

Security is treated as an architectural concern. Nodes can be assigned explicit permissions — such as network access, file system access, database writes, or process spawning. These permissions can be statically verified, and the runtime message switch can monitor and intercept disallowed behavior.

vmblu does not impose frameworks or restrict your technology choices. It can be introduced into existing systems and adopted incrementally.

At the same time, vmblu does not replace good design. Domain knowledge and engineering judgment remain essential.

What This Enables

• Clarity for coding agent and human. The entire structure of the system is visible at a glance: nodes, inputs, outputs and routes.

• Security by structure. Boundaries are explicit. External access points are visible. Policies can be enforced at runtime. Message flows can be logged and audited.

• Observability The architecture itself supports inspection: what is done where and what is shared between the components of a system. But also every interaction is a message, making observing the dynamics of a system much more feasible.

• Maintainability Changes to a system have a well defined perimeter and impact, and maintenance becomes a much more structured and less daunting task.

• Parallel Development Nodes define clear interfaces, so they can be implemented independently. The blueprint prevents structural drift.

• MCP native. In vmblu you can mark an interface of a node as a tool and generate automatically an MCP tool file from it. An LLM will then be able to use that software allowing the user to use a natural language interface with the system.

Additional Structural Advantages

vmblu allows to build modular, message based systems. This in itself, apart from the formal architectural clarity discussed above, has clear advantages:

• Loose coupling – No hidden dependencies
• Natural concurrency – Asynchronous by default
• Scalability – Same model runs locally or distributed
• Replaceability – Nodes can be swapped without ripple effects
• Evolution safety – Add messages without breaking internals

Why message passing ?

A natural question is whether vmblu really needs message passing at all. The same architecture could in principle be implemented with direct function calls: a connection from A.pin_x to B.pin_y could simply mean that invoking A.pin_x(param) ultimately calls B.pin_y(param). That mapping could be generated at compile time or resolved through a lightweight runtime table. So why make messages a defining part of vmblu?

The answer is that calls and messages encourage different ways of structuring and reasoning about software. A call-based system is naturally procedural and time-oriented: one component calls another, waits for a result, continues, and perhaps calls the next component. The architecture therefore tends to emphasize execution paths, sequencing and control flow.

A message-based system has a different character. Components behave more like departments in an organisation: each has its own responsibilities, and they communicate through explicit channels. The important architectural questions become who may communicate with whom, what information crosses each boundary, and how each component reacts when it receives something. Concurrency, asynchronous behaviour and independent evolution fit naturally into this model.

vmblu deliberately adopts this second model. Calls remain entirely appropriate inside a component, where functions, classes and libraries implement its internal behaviour. But when communication crosses an architectural boundary, vmblu makes that interaction explicit through pins and connections. The runtime can then route, inspect, trace, secure and control those interactions without either side needing to know the implementation details of the other.

This also has an important advantage for coding agents. When implementing a component, an agent only needs to understand that component's behaviour and its declared inputs and outputs. It does not necessarily need the source code, file structure or implementation details of every component it interacts with. The architecture owns the connectivity; the code owns the behaviour.

The vmblu model is therefore not fundamentally tied to one transport mechanism. Request/reply, fire-and-forget messages, broadcasts, streams or remote communication can all fit within the same message-oriented architectural model. Other execution strategies could also be supported technically, but direct call-based architecture represents a sufficiently different mental model that it may be better expressed with different architectural tooling rather than hiding both paradigms behind identical connections.

vmblu is not intended to replace function calls. It adds another tool to the developer's toolbox: use calls to structure the implementation inside components, and explicit message-based communication to structure the architecture between them.

Conclusion

AI agents can generate code but vmblu gives you the tools to guide, observe and control their output.

vmblu does not replace good engineering.

vmblu does not replace good engineering. It makes good engineering explicit.