Por anos, a engenharia de software foi otimizada para:

• escrever código mais rápido;
• abstrair infraestrutura;
• reduzir boilerplate;
• gerar APIs;
• simplificar o CRUD.

A IA acelerou isso dramaticamente.

Mas acredito que estamos entrando em uma era completamente diferente.

Uma era onde o gargalo não é mais:

• a velocidade de digitação;
• o conhecimento de frameworks;
• lembrar da sintaxe.

O novo gargalo é:

Quão bem você consegue arquitetar sistemas semânticos reutilizáveis?

Essa constatação me levou a criar o que chamo de:

VibeCoding State-of-the-Art-Driven Development

E a força emocional por trás disso foi o:

BRIO-Driven Development

Porque se algo pode ser drasticamente melhor, por que se contentar com a versão básica?

---

O que é o VibeCoding State-of-the-Art-Driven Development?

A maioria das pessoas acha que "VibeCoding" significa:

• deixar a IA gerar código aleatório rapidamente;
• prototipar mais rápido;
• substituir desenvolvedores juniores;
• automatizar boilerplate.

Não é isso que eu estou fazendo.

Para mim, VibeCoding significa usar a IA como:

• um pesquisador de arquitetura de runtime;
• um teórico de sistemas distribuídos;
• um colaborador de compiladores semânticos;
• um parceiro de design de linguagem;
• um consultor de convergência e segurança.

Eu me tornei completamente dependente da IA por um motivo:

Nenhum humano consegue mais acompanhar todas as técnicas do estado da arte em todos os domínios.

Enquanto a IA gera o código, eu debato com ela:

• a melhor semântica de execução;
• as melhores garantias de replay;
• o melhor modelo de convergência;
• a melhor topologia de runtime distribuído;
• a melhor sintaxe de declaração de entidades;
• a melhor estratégia de sistema de tipos;
• as melhores garantias de segurança;
• os melhores padrões de orquestração.

Aprendi mais em duas semanas discutindo arquitetura com a IA do que nos últimos dez anos escrevendo software tradicional.

Não porque a IA me substituiu.

Mas porque ela multiplicou:

• a curiosidade;
• a velocidade de iteração;
• a exploração arquitetural;
• o pensamento sistêmico.

---

O Objetivo: Experiência Extrema do Desenvolvedor

O objetivo não é criar "mais um framework".

O objetivo é:

Criar o framework mais fácil e poderoso já construído.

Um framework onde:

• após a versão 1.0;
• eu nunca mais precise codificar um sistema manualmente.

Novos sistemas deverão ser criados apenas através de:

• arquivos de configuração e declaração semântica .be2e, .json, .yml.

A complexidade de orquestração deve existir:

• uma única vez;
• globalmente;
• permanentemente.

Todo o resto se torna:

• especificação;
• declaração semântica;
• derivação em tempo de execução (runtime derivation).

---

BE2E: Uma Linguagem Para Gerar Tudo

Um dos maiores problemas com sistemas gerados por IA hoje é este:

Os LLMs precisam gerar código para muitas linguagens, frameworks e runtimes diferentes.

Frontend.

Backend.

Sistemas de filas.

ORMs.

Bancos de dados vetoriais.

Cache.

Sistemas de eventos.

Observabilidade.

Segurança.

Isso cria:

• inconsistência;
• desvio arquitetural (architectural drift);
• lógica duplicada;
• integrações alucinadas;
• sistemas frágeis.

Então eu me perguntei:

Por que a IA deveria gerar N implementações se ela poderia gerar apenas uma linguagem semântica?

Essa linguagem se tornou:

Behavior E2E (BE2E)

Uma DSL semântica onde o comportamento de uma entidade é declarado uma única vez:

Snippet de código

behavior User.Login {

opens LoginPage

-> fill email

-> fill password

-> click submit

\-\> expect Session.created  

}

E o runtime lida com:

• orquestração;
• replay;
• observabilidade;
• segurança;
• caching;
• convergência;
• sincronização;
• projeções;
• consistência distribuída;
• event sourcing;
• validação semântica;
• persistência poliglota.

A IA só precisa se tornar excepcional em gerar:

• uma única DSL.

O runtime faz o trabalho pesado.

---

Por que Hiper-Poliglota?

Estou construindo uma arquitetura hiper-poliglota usando mais de 7 linguagens.

Por quê?

Porque problemas diferentes merecem modelos de execução diferentes.

Direção atual da stack:

E quase todas as linguagens compilam para:

WASM

Isso não é "complexidade por diversão".

Isso é:

• especialização de execução;
• especialização de corretude (correctness);
• especialização de segurança (safety);
• especialização de runtime.

Originalmente, eu pretendia usar muito Erlang/Elixir, mas depois de descobrir o Gleam, percebi que ele oferece um caminho muito mais limpo para a orquestração de atores tipados.

---

Por que Event Sourcing, Grafos, Vetores e Observabilidade São Obrigatórios

Sistemas de IA modernos não podem continuar sendo:

• centrados em CRUD;
• puramente relacionais;
• stateless (sem estado);
• opacos.

Qualquer sistema nativo de IA profissional DEVE ter:

• Event Sourcing
• Observabilidade
• Arquitetura Cache-first
• Armazenamento Vetorial
• Armazenamento em Grafo

Por quê?

Porque a inteligência exige:

• memória;
• relacionamentos;
• semântica;
• recuperação (retrieval);
• causalidade;
• rastreabilidade.

Os vetores permitem:

• recuperação semântica;
• memória contextual;
• embeddings;
• raciocínio por similaridade.

Os grafos permitem:

• relacionamentos;
• causalidade;
• travessia semântica;
• estruturas de conhecimento.

A observabilidade é obrigatória porque:

• os sistemas de IA são probabilísticos;
• distribuídos;
• emergentes;
• evoluem dinamicamente.

Sem observabilidade:

• você não consegue depurar (debug);
• explicar;
• fazer benchmarks;
• confiar;
• evoluir agentes com segurança.

E o Event Sourcing se torna crítico porque:

• a capacidade de replay (replayability);
• a causalidade;
• a convergência;
• a auditabilidade;
• a reconstrução semântica

são fundamentais para runtimes inteligentes.

---

"Por que não usar simplesmente Postgres?"

Eu poderia absolutamente construir tudo apenas com o Postgres.

E também darei suporte a essa versão.

Mas, honestamente:

Eu vejo zero problema em rodar um container Docker por banco de dados especializado.

Não estamos mais em 2012.

Mecanismos de armazenamento (storage engines) existem para propósitos diferentes:

• Redis para cache;
• Qdrant para recuperação vetorial;
• Neo4j para semântica de grafos;
• ClickHouse para observabilidade;
• EventStoreDB para event sourcing;
• MongoDB para projeções de leitura;
• PostgreSQL para escritas transacionais.

O runtime deve orquestrar essa complexidade automaticamente.

O desenvolvedor não deve sofrer porque a arquitetura é avançada.

---

Tudo-como-Código (Everything-as-Code) Levado ao Extremo

A maioria dos frameworks ainda pensa em:

• APIs;
• serviços;
• rotas;
• tabelas;
• DTOs.

Eu penso em:

• comportamentos;
• transformações semânticas;
• convergência;
• garantias;
• orquestração;
• álgebra de runtime.

O verdadeiro produto não é o código.

O verdadeiro produto é:

• o modelo semântico;
• as garantias de runtime;
• o motor de orquestração;
• a semântica de execução reutilizável.

É por isso que eu chamo de:

State-of-the-Art-Driven Development

Porque a própria arquitetura é continuamente moldada por:

• os melhores sistemas de tipos;
• as melhores teorias de sistemas distribuídos;
• os melhores modelos de runtime;
• os melhores padrões de segurança;
• as melhores técnicas de computação semântica disponíveis hoje.

---

O Objetivo Final

O objetivo final não é mais um framework.

O objetivo final é:

Um runtime semântico onde construir sistemas distribuídos complexos se torna absurdamente fácil através de linguagem natural.

Onde os desenvolvedores não lutam mais contra:

• a infraestrutura;
• a orquestração;
• a sincronização;
• o replay;
• a observabilidade;
• a consistência;
• a complexidade distribuída.

Eles simplesmente declaram:

• comportamentos;
• garantias;
• restrições (constraints);
• capacidades;
• transformações.

E o runtime deriva:

• o sistema;
• a topologia;
• a orquestração;
• a estratégia de armazenamento;
• o modelo de sincronização;
• a observabilidade;
• as garantias de convergência.

É isso que quero dizer com:

VibeCoding State-of-the-Art-Driven Development

Um futuro onde:

• a IA amplifica a arquitetura em vez de apenas gerar trechos de código (snippets);
• sistemas semânticos substituem a implementação repetitiva;
• e os desenvolvedores passam seu tempo desenhando significados em vez de conectar infraestrutura.