O VibeCoding acabou mudar conceitualmente, para sempre, toda a forma que eu programo

Por anos, continuei construindo sistemas distribuídos cada vez mais paranoicos.

mTLS em todo lugar.
Autenticação sem senha (passwordless).
DPoP.
Chaves efêmeras.
Criptografia pós-quântica.
Arquiteturas orientadas a eventos.
Isolamento de sessão.
Zero Trust.
Sistemas baseados em capacidades (capabilities).

E, no entanto, algo sempre parecia fundamentalmente errado.

Não importava o quão segura a arquitetura se tornasse, o próprio modelo de programação ainda permitia a existência de estados impossíveis.

Tokens podiam ser duplicados.
Sessões podiam acidentalmente sobreviver mais tempo do que o pretendido.
Segredos efêmeros ainda podiam ser reutilizados.
Eventos podiam, teoricamente, ser consumidos duas vezes.
Recursos que deveriam ser de uso único eram tratados como valores comuns.

Então o VibeCoding aconteceu.

E enquanto explorava linguagens de programação obscuras por pura curiosidade, descobri a Austral.

Não é o ownership do Rust.
Não é borrow checking.
Não é validação em tempo de execução (runtime).

São Tipos Lineares de verdade.

No momento em que entendi o conceito, meu cérebro explodiu imediatamente com uma pergunta:

Por que isso já não está em todo lugar?

Porque as implicações são absurdas.

Algumas coisas simplesmente não deveriam ser copiáveis.

Nunca.

Um token DPoP não deveria ser clonável.
Uma chave de sessão efêmera pós-quântica não deveria ser reutilizável.
Uma prova de autorização de pagamento não deveria sobreviver após o consumo.
Uma capacidade (capability) de uso único não deveria permanecer viva na memória por acidente.
Uma sessão não deveria se duplicar silenciosamente através de referências.

E, no entanto, a maioria das linguagens convencionais ainda trata esses valores como estruturas de dados normais.

Os tipos lineares mudaram completamente a minha forma de pensar sobre sistemas.

Não de forma incremental.
Exponencialmente.

A Realização

O insight mais importante foi este:

Alguns recursos não são dados.

Eles são obrigações semânticas.

Um token de sessão não é "informação".
É uma capacidade consumível.

Uma chave efêmera não é um "estado".
É um recurso criptográfico de uso único.

Um evento não é "apenas uma mensagem".
É uma transição em um ciclo de vida semântico.

E essas coisas deveriam ser representadas pelo próprio sistema de tipos.

Uma vez que percebi isso, comecei a ver categorias inteiras de vulnerabilidades como falhas de modelagem de tipos.

Ataques de replay?
Problemas de duplicação de recursos.

Vazamento de sessão?
Violação de propriedade (ownership).

Consumo duplo de eventos?
Semântica não-linear.

Mau uso de DPoP?
Artefatos de prova copiáveis.

A partir desse ponto, eu não conseguia mais voltar atrás.

Austral Parece um Olhar Para o Futuro

O que me impressionou ainda mais foi que a Austral ainda é relativamente pequena e obscura.

Escrita em OCaml.
Compilando para WASM.
Extremamente focada.
Extremamente baseada em princípios.

E, de alguma forma, carregando ideias que já deveriam existir em todas as linguagens de sistemas sérias.

A parte mais engraçada é que descobrir a linguagem me deixou feliz justamente porque ela ainda carece de muitas coisas.

Isso significava que havia espaço para construir.

E eu entrei imediatamente em um estado de completa obsessão técnica.

O Que Aconteceu Depois

Em questão de dias, comecei a construir em torno do próprio ecossistema.

Eu criei:

• uma versão de fã do site oficial
• um gerenciador de pacotes
• múltiplos pacotes
• utilitários de teste
• tipos semânticos adicionais
• validações de tipo mais fortes
• APIs ergonômicas (estilo JavaScript)
• ferramentas para desenvolvedores

E então as coisas escalaram.

Comecei a construir um framework de API completo em torno dos princípios que eu vinha projetando mentalmente por anos:

• autenticação sem senha
• mTLS
• criptografia pós-quântica
• chaves efêmeras lineares
• tokens DPoP lineares
• segurança baseada em capacidades (capabilities)
• execução WASM
• semântica orientada a eventos

O curioso é:
os tipos lineares subitamente fizeram todas essas ideias parecerem estruturalmente corretas.

Não "seguras por convenção".
Não "validadas por disciplina".

Realmente impostas pelo sistema.

O Problema da Experiência do Desenvolvedor (DX)

A maior tragédia das linguagens avançadas raramente é o seu sistema de tipos.

É a experiência do desenvolvedor.

A maioria dos desenvolvedores nunca descobrirá ideias como:

• capacidades lineares
• propriedade afim (affine ownership)
• consumo semântico de recursos
• execução baseada em provas
• arquiteturas seguras por capacidades

...porque o ferramental (tooling) em torno dessas ideias costuma ser doloroso.

Então, acidentalmente, encontrei um novo hobby:

Melhorar a Experiência do Desenvolvedor para linguagens obscuras, mas revolucionárias.

Quero que os tipos lineares pareçam acessíveis.
Naturais.
Úteis.
Práticos.

Quero que as pessoas descubram acidentalmente um modelo computacional mais seguro enquanto constroem sistemas normais.

É por isso que comecei a implementar APIs intencionalmente inspiradas na ergonomia do JavaScript.

Porque se os desenvolvedores puderem usar recursos semânticos lineares com APIs que pareçam familiares, a barreira desaparece.

E uma vez que você entende as implicações, torna-se impossível ignorar.

Não Acho que Tipos Lineares Sejam "Avançados"

Eu acho que eles são inevitáveis.

Especialmente para:

• tokens
• sessões
• material criptográfico
• fluxos de eventos
• provas efêmeras
• capacidades de autorização
• recursos comportamentais distribuídos

A ideia de que esses recursos são livremente copiáveis agora me parece fundamentalmente incorreta.

E quanto mais os sistemas distribuídos se tornam:

• orientados a eventos
• baseados em provas
• baseados em capacidades
• pós-quânticos
• zero-trust

...mais a semântica de recursos não-lineares começa a parecer absurda.

O VibeCoding Mudou Mais do que a Produtividade

As pessoas falam sobre VibeCoding como:
"A IA escreve código para você."

Essa não é a parte interessante.

A parte interessante é que a curiosidade foi subitamente amplificada de forma massiva.

Agora você pode explorar:

• teorias obscuras de linguagens de programação
• métodos formais
• semântica distribuída
• sistemas de reescrita
• sistemas de tipos
• cálculo de capacidades

...sem passar meses lutando contra o boilerplate antes de conseguir experimentar.

E isso muda tudo.

Porque agora uma curiosidade aleatória de madrugada sobre uma linguagem obscura pode alterar completamente a arquitetura dos seus sistemas.

Foi exatamente o que aconteceu comigo e a Austral.

E honestamente?

Acho que só vi o começo do que os sistemas semânticos lineares se tornarão.

O que acharam do logo que o GPT fez? Ultimamente de todos que eu testo, ele sempre ta ganhando, eu pessoalmente achei muito bom pois pegou bem a ideia que eu queria.