O Lado Sombrio do Vibe Coding: Quando o Código Funciona Mas Não Dura

Vamos ser sinceros: vibe coding é uma revolução. Você descreve o que quer, assiste o agente construir, vê os testes passarem, e manda pro ar. Parece mágica — até parar de parecer.

Esse "até" costuma aparecer às 3 da manhã. Seu app startou de boa, aguentou uns requests belíssimos, e aí morre sem piedade por um OOM killer. Ou abre dez mil file descriptors e desmorona. Ou roda liso com seu dado de teste e derrete quando usuário real aparece.

O código estava correto. Resolveu o problema exatamente como especificado. Só tinha um detalhe: assumiu memória infinita e file handles infinitos. Porque nada no seu prompt dizia o contrário.

O Assassino Silencioso: Pressupostos Não Declarados

Aqui está o ponto perigoso do vibe coding que ninguém discute em conferências. Quando você escreve código, carrega mental models de restrições para todo lado. Você sabe que está rodando num notebook com 16GB RAM. Sabe que o servidor de produção tem limite de file descriptors. Sabe que aquele CSV de 400GB não é algo que dá pra carregar na memória assim, de boa.

Mas quando uma IA escreve seu código, essas restrições não existem. A IA olha "carrega o arquivo, ordena, escreve o resultado" e pensa: show, vou carregar tudo. Funciona perfeitamente nos testes. O arquivo de teste tem 50KB.

Revisões de código não captam isso também. As linhas problemáticas parecem completamente razoáveis. Não existe nenhum alerta quando você está escaneando erros de lógica — porque não existem erros de lógica. O bug não está na lógica; está na caixa invisível onde a lógica foi projetada pra caber.

E Se o Compilador Soubesse das Restrições?

Aí é que a coisa fica interessante. Um developer chamado Nicolas Grislain está experimentando uma ideia provocativa: e se restrições de recursos fossem tipos, não comentários?

Em vez de torcer pra seu código gerado por IA respeitar limites de memória, e se o compilador simplesmente se recusasse a compilar código que violasse esses limites? E se "essa função nunca mantém mais de 100 registros em memória" e "esse programa nunca tem mais de 3 arquivos abertos simultaneamente" fossem fatos verificados pelo compilador, não orações sussurradas durante code review?

Isso não é só teoria abstrata. O experimento usa Lean 4 — sim, o mesmo Lean que está causando rebuliço em matemática formal — para codificar budgets de recursos diretamente nos tipos de funções. O compilador vira um auditor de recursos, verificando automaticamente que seu código respeita os limites antes de rodar.

Fazendo Recursos Contarem

O truque central é surpreendentemente elegante: passar contadores de recursos pelo sistema de tipos. Em vez de rastrear "quantos arquivos estão abertos" como uma variável runtime que pode ser ignorada, o sistema de tipos rastreia como um parâmetro fantasma que precisa balancear.

Quando você abre um arquivo, a assinatura do tipo reflete a mudança: você entra na função com N arquivos abertos e sai com N+1. Quando fecha, volta de N+1 para N. O compilador rastreia isso em cada passo, e você literalmente não consegue compilar código que abre arquivo sem fechar, ou abre arquivos acima de um limite definido.

Memória funciona de forma similar, mas com um toque. Registros não flutuam livremente na memória — vivem num pool limitado com número fixo de slots. Você não mantém um objeto Event; mantém uma referência naquele pool. O tipo rastreia quantas referências vivas existem a qualquer momento, e alocação requer prova de que tem espaço.

A mágica acontece no entry point: o programa precisa começar com zero recursos em uso e terminar com zero. Você não pode vazar handles ou refs. Não pode exceder caps. O compilador simplesmente não deixa.

Por Que Isso Importa Pro Vibe Coding

Essa abordagem transforma como pensamos em fazer prompting de assistentes de IA. Hoje, você talvez adicione uma nota como "cuidado com uso de memória" ou "feche todos os file handles" — torcendo pra IA prestar atenção. Com tipos cientes de recursos, você especifica restrições formalmente, e a implementação precisa se reorganizar pra satisfazê-las.

A IA recebe a versão irrestrita primeiro. Testes passam. Aí você habilita os limites. O compilador rejeita a implementação imediatamente. A IA precisa restructuring sua abordagem — talvez processando o arquivo em chunks em vez de carregar tudo de uma vez, ou usando um connection pool em vez de abrir arquivos diretamente.

A implementação não só funciona por sorte; funciona provavelmente dentro do budget.

A Realidade Prática

Seja claro: isso não é tooling production-ready pra maioria dos times ainda. A abordagem com Lean 4 requer setup significativo, e tem overhead em pensar em termos de tipos indexados. Mas o insight por baixo é valioso independente da implementação.

Quando você faz vibe coding, está terceirizando não só a escrita do código, mas o mental model do seu sistema. Seu assistente de IA não conhece seu ambiente de produção. Não sabe que seu container tem 512MB de RAM. Não sabe que seu kernel Linux limita file descriptors em 1024.

Enquanto não tivermos melhores formas de codificar essas restrições, temos algumas opções pragmáticas:

1. Seja explícito nos prompts — "O arquivo de input pode conter até 10 milhões de linhas" é melhor que "cuide bem com arquivos grandes"

2. Teste com dados em escala de produção — Se seu dado de treinamento é minúsculo, sua IA não vai aprender padrões de recursos

3. Use APIs com limites — Arquitetura que naturalmente limita uso de recursos (connection pools, streaming em vez de load) é mais difícil de usar errado

4. Fique de olho em tooling ciente de recursos — A indústria está começando a explorar formas de tornar restrições explícitas em código gerado por IA

O Recado Final

O segredo sujo do vibe coding não é que ele escreve código bugado — é que ele escreve código correto dentro de um espaço de restrições invisível. Esse espaço inclui seu notebook, seu ambiente de teste, e talvez seus primeiros mil usuários. Definitivamente não inclui "produção em escala."

Sistemas de tipos cientes de recursos como esse experimento com Lean 4 apontam pra um futuro onde "correto" significa mais que "logicamente certo." Significa "provado que respeita os limites que realmente existem."

É um futuro vale a pena construir. Até lá, mantenha seus dados de teste próximos do tamanho de produção, e talvez adicione uma nota extra nos seus prompts sobre aqueles limites de file descriptors.

Seu futuro eu de plantão vai agradecer.