For years, software engineering has optimized for:

• writing code faster;
• abstracting infrastructure;
• reducing boilerplate;
• generating APIs;
• simplifying CRUD.

AI accelerated this dramatically.

But I believe we are entering a completely different era.

An era where the bottleneck is no longer:

• typing speed;
• framework knowledge;
• remembering syntax.

The new bottleneck is:

How well can you architect reusable semantic systems?

That realization led me to create what I call:

VibeCoding State-of-the-Art-Driven Development

And the emotional force behind it was:

BRIO-Driven Development

Because if something can be dramatically better, why settle for the basic version?

What Is VibeCoding State-of-the-Art-Driven Development?

Most people think “VibeCoding” means:

• letting AI generate random code quickly;
• prototyping faster;
• replacing junior developers;
• automating boilerplate.

That is not what I’m doing.

For me, VibeCoding means using AI as:

• a runtime architecture researcher;
• a distributed systems theorist;
• a semantic compiler collaborator;
• a language design partner;
• a convergence and security advisor.

I became completely dependent on AI for one reason:

No human can keep up with every state-of-the-art technique across every domain anymore.

While the AI generates code, I debate with it:

• the best execution semantics;
• the best replay guarantees;
• the best convergence model;
• the best distributed runtime topology;
• the best entity declaration syntax;
• the best type-system strategy;
• the best security guarantees;
• the best orchestration patterns.

I learned more in two weeks discussing architecture with AI than I did in the previous ten years writing traditional software.

Not because the AI replaced me.

But because it multiplied:

• curiosity;
• iteration speed;
• architectural exploration;
• systems thinking.

The Goal: Extreme Developer Experience

The goal is not to create “another framework”.

The goal is:

To create the easiest and most powerful framework ever built.

A framework where:

• after version 1.0;
• I never need to manually code another system again.

New systems should be created only through:

• .be2e
• .json
• .yml

configuration and semantic declaration files.

The orchestration complexity should exist:

• once;
• globally;
• permanently.

Everything else becomes:

• specification;
• semantic declaration;
• runtime derivation.

BE2E: One Language To Generate Everything

One of the biggest problems with AI-generated systems today is this:

LLMs need to generate code for many different languages, frameworks and runtimes.

Frontend.
Backend.
Queue systems.
ORMs.
Vector databases.
Caching.
Event systems.
Observability.
Security.

This creates:

• inconsistency;
• architectural drift;
• duplicated logic;
• hallucinated integrations;
• fragile systems.

So I asked:

Why should the AI generate N implementations if it could generate only one semantic language?

That language became:

Behavior E2E (BE2E)

A semantic DSL where an entity behavior is declared once:

behavior User.Login {

  opens LoginPage
    -> fill email
    -> fill password
    -> click submit

    -> expect Session.created
}

And the runtime handles:

• orchestration;
• replay;
• observability;
• security;
• caching;
• convergence;
• synchronization;
• projections;
• distributed consistency;
• event sourcing;
• semantic validation;
• polyglot persistence.

The AI only needs to become exceptional at generating:

• one DSL.

The runtime performs the heavy lifting.

Why Hyper-Polyglot?

I’m building a hyper-polyglot architecture using more than 7 languages.

Why?

Because different problems deserve different execution models.

Current stack direction:

And almost every language compiles to:

WASM

This is not “complexity for fun”.

This is:

• execution specialization;
• correctness specialization;
• safety specialization;
• runtime specialization.

I originally intended to use Erlang/Elixir heavily, but after discovering Gleam I realized it provides a much cleaner path for typed actor orchestration.

Why Event Sourcing, Graph, Vector and Observability Are Mandatory

Modern AI systems cannot remain:

• CRUD-centric;
• relational-only;
• stateless;
• opaque.

Any professional AI-native system MUST have:

• Event Sourcing
• Observability
• Cache-first architecture
• Vector storage
• Graph storage

Why?

Because intelligence requires:

• memory;
• relationships;
• semantics;
• retrieval;
• causality;
• traceability.

Vectors allow:

• semantic retrieval;
• contextual memory;
• embeddings;
• similarity reasoning.

Graphs allow:

• relationships;
• causality;
• semantic traversal;
• knowledge structures.

Observability is mandatory because:

• AI systems are probabilistic;
• distributed;
• emergent;
• dynamically evolving.

Without observability:

• you cannot debug;
• explain;
• benchmark;
• trust;
• evolve agents safely.

And Event Sourcing becomes critical because:

• replayability;
• causality;
• convergence;
• auditability;
• semantic reconstruction

are foundational for intelligent runtimes.

“Why Not Just Use Postgres?”

I could absolutely build everything with only Postgres.

And I will support that version too.

But honestly:

I see zero problem in running one Docker container per specialized database.

We are no longer in 2012.

Storage engines exist for different purposes:

• Redis for cache;
• Qdrant for vector retrieval;
• Neo4j for graph semantics;
• ClickHouse for observability;
• EventStoreDB for event sourcing;
• MongoDB for read projections;
• PostgreSQL for transactional writes.

The runtime should orchestrate this complexity automatically.

The developer should not suffer because the architecture is advanced.

Everything-as-Code Taken to the Extreme

Most frameworks still think in:

• APIs;
• services;
• routes;
• tables;
• DTOs.

I think in:

• behaviors;
• semantic transformations;
• convergence;
• guarantees;
• orchestration;
• runtime algebra.

The real product is not the code.

The real product is:

• the semantic model;
• the runtime guarantees;
• the orchestration engine;
• the reusable execution semantics.

That’s why I call it:

State-of-the-Art-Driven Development

Because the architecture itself is continuously shaped by:

• the best type systems;
• the best distributed systems theories;
• the best runtime models;
• the best security patterns;
• the best semantic computation techniques available today.

The End Goal

The end goal is not another framework.

The end goal is:

A semantic runtime where building complex distributed systems becomes ridiculously easy through natural language.

Where developers no longer fight:

• infrastructure;
• orchestration;
• synchronization;
• replay;
• observability;
• consistency;
• distributed complexity.

They simply declare:

• behaviors;
• guarantees;
• constraints;
• capabilities;
• transformations.

And the runtime derives:

• the system;
• the topology;
• the orchestration;
• the storage strategy;
• the synchronization model;
• the observability;
• the convergence guarantees.

That is what I mean by:

VibeCoding State-of-the-Art-Driven Development

A future where:

• AI amplifies architecture instead of just generating snippets;
• semantic systems replace repetitive implementation;
• and developers spend their time designing meaning instead of wiring infrastructure.