Where vmblu Is Going

vmblu is a very useful tool.

It can make a system’s architecture visible, give coding agents a structured view of the work, connect implementation to explicit interfaces, and provide a clearer basis for testing, maintenance, and controlled agent interaction.

But vmblu is not a finished idea.

The underlying problem is getting bigger: software is becoming easier to generate, more systems will be built by small teams, and more of those systems will be changed or operated with the help of agents.

That makes explicit architecture more important, not less.

Our goal is to make vmblu useful for everything from a small application built by one person and an AI assistant to large systems where many people, services, and agents need to work without losing control of the whole.

The ambition is simple:

Make serious software easier to understand, safer to evolve, and harder to accidentally turn into a disaster.

Below are some of the directions we are working on.

More languages, more environments

Today, vmblu works primarily with JavaScript and TypeScript, both in the browser and on the server through environments such as Node.js.

That already covers a large part of modern application development.

But the core idea is not specific to JavaScript.

Nodes, interfaces, routes, contracts, architecture navigation, and agent-readable system models can apply equally well to other languages and platforms. A backend in Python, a service in Go, a desktop application in C#, or a native mobile application all have the same fundamental need for explicit structure.

Over time, vmblu should support a broader range of languages, runtimes, and operating environments.

The goal is not to force every project into one technology stack.

It is to give different stacks a shared architectural language.

Reference designs

As software becomes cheaper to produce, code reuse may become less important than it used to be.

But good design will remain extremely valuable.

A well-designed authentication boundary, workflow engine, agent interface, event-driven service, document processing pipeline, or multi-user application architecture can save far more time than a copied code snippet.

vmblu should make it possible to share not only components, but also proven architectural patterns.

These reference designs could serve as:

• examples of good system structure;
• starting points for new projects;
• reusable subsystems;
• agent-readable design templates;
• discussion material for teams deciding how to structure a system.

The value is not just “download this boilerplate.”

It is being able to start from a design that already makes important decisions explicit.

Better support for coding agents

vmblu is not a coding-agent framework.

It does not try to replace the fast-moving ecosystem of agents, models, IDE integrations, and development environments.

Its role is different.

vmblu provides the architectural reference that helps a coding agent understand what it is working on.

As coding agents become more capable, vmblu should become better at giving them the right kind of context:

• the relevant part of the system, rather than the entire repository;
• the interfaces and contracts a change must respect;
• the routes and components affected by a modification;
• the tests that are relevant to a node or interface;
• the architectural constraints that should not be violated.

The better agents become at implementation, the more useful it becomes to give them a stable and explicit model of the system they are changing.

Agent-facing application interfaces

Applications are increasingly used by agents as well as by people.

That means software needs more than APIs hidden in documentation or internal functions exposed by convenience.

It needs deliberate capabilities.

vmblu is moving toward a model where selected application interfaces can be exposed to agents as controlled tools. Those tools can be described formally, mapped to standards such as MCP, and connected to runtime policy and observation points.

The important question is not only:

Can an agent call this function?

It is also:

Should this capability be exposed at all? Under which conditions? With what permissions? With what audit trail? And where can it be stopped if something goes wrong?

That is where architecture and runtime control meet.

Stronger validation and testing

An explicit architecture creates opportunities for better verification.

If nodes, interfaces, and routes are known, vmblu can help validate whether implementations match their declared contracts. It can also provide a clearer basis for generating and organising tests around the actual structure of the system.

Over time, this should lead to better support for:

• contract validation;
• interface compatibility checks;
• route and dependency analysis;
• node-level test scaffolding;
• regression checks for architectural changes;
• detection of structural drift between model and implementation.

The aim is not to replace normal testing.

It is to make testing more aware of the system’s intended architecture.

Security and policy as architecture

Security is often added late.

A feature gets built, an endpoint is exposed, an integration is connected, and only afterwards does the team ask whether the right checks exist.

vmblu should help move some of that thinking earlier.

When a system explicitly describes its components, boundaries, messages, and exposed capabilities, it becomes easier to reason about permissions and policy.

In time, vmblu can provide stronger support for questions such as:

• Which nodes may access external networks?
• Which components may write to a database?
• Which capabilities may be exposed to agents?
• Which message routes carry sensitive information?
• Where should actions be logged, approved, throttled, or intercepted?

This is especially important as applications become more agentic.

A system that can be operated by an agent needs more than good prompts. It needs boundaries that are visible and enforceable.

From diagrams to living architecture

The larger direction behind all of this is simple.

Architecture should not be a forgotten diagram, a page in a wiki, or a collection of conventions known only by experienced developers.

It should be a living part of the software itself.

Something people can inspect.

Something agents can reason from.

Something that helps guide implementation.

Something that remains useful when the system is running.

vmblu is at the beginning of that journey.

There will be many practical steps, many design decisions, and no doubt many changes in direction as users, projects, and coding agents reveal what matters most.

But the central idea will remain the same:

As software becomes easier to generate, it becomes more important to make its architecture explicit.

That is what vmblu is here to do.