Vibe Coding e Arquitetura: Como Definir Fronteiras de Serviço para Evitar Acoplamento

Você já sentiu que a vibe coding está funcionando perfeitamente no protótipo, mas começa a virar um pesadelo quando o projeto cresce? É uma sensação comum. Você pede ao modelo de linguagem para adicionar uma funcionalidade simples, ele gera o código em segundos, parece mágico. Mas, semanas depois, você descobre que essa "mágica" espalhou lógica de banco de dados pelo frontend e misturou regras de negócio com interface de usuário. O resultado? Um sistema onde mudar uma linha em um lugar quebra três coisas em outro lugar completamente diferente.

O problema não é a inteligência artificial em si. O problema é a falta de fronteiras de serviço claras antes de começar a codificar. A vibe coding, definida como uma abordagem híbrida onde desenvolvedores guiam a criação de software através de instruções em linguagem natural e código leve assistido por IA, funciona melhor quando tratada como engenharia de software tradicional, não como um passe de mágica. Se você deixar o LLM decidir a arquitetura, ele vai criar um monolito caótico. Se você definir as regras do jogo primeiro, a IA se torna uma ferramenta incrivelmente poderosa.

O Que é Vibe Coding e Por Que Ela Cria Caos Estrutural

A vibe coding fica no meio-termo entre o no-code puro e a programação tradicional. Em vez de arrastar e soltar blocos ou escrever cada caractere manualmente, você descreve o que quer em inglês (ou português) e a IA sugere o código. Segundo a Cloud Security Alliance, isso permite que "cidadãos desenvolvedores" criem fluxos de trabalho complexos sem expertise profunda. Mas há uma pegadinha arquitetural aqui.

Modelos de linguagem não têm senso inato de serviços ou módulos. Eles veem tokens e padrões. Quando você diz "faça funcionar", o modelo tenta conectar tudo da forma mais direta possível, muitas vezes ignorando separações lógicas. Isso leva ao que chamamos de acoplamento apertado. No jargão de arquitetura, acoplamento apertado significa que dois componentes dependem tanto um do outro que mudar um exige mudar o outro. Em sistemas bem desenhados, você quer baixo acoplamento e alta coesão. Na vibe coding sem regras, você acaba tendo alto acoplamento e baixa coesão.

Pense nisso como construir uma casa. Se você apenas disser "quero uma cozinha", o construtor pode colocar a pia dentro do banheiro porque ambos precisam de água. Funciona? Sim. É sustentável? Não. As fronteiras de serviço são as paredes estruturais que impedem esse tipo de decisão improvisada.

Definindo Fronteiras de Serviço Antes do Primeiro Prompt

A chave para evitar o caos é definir as fronteiras antes de tocar no teclado. Michael Shmilov, em seus artigos sobre escala de vibe coding, argumenta que microsserviços funcionam porque criam limites claros: cada serviço tem uma responsabilidade clara, possui sua própria lógica e se comunica através de APIs definidas. Ele sugere aplicar essa mesma mentalidade à vibe coding, mesmo que você não esteja usando microsserviços distribuídos.

Isso não significa necessariamente dividir seu aplicativo em dez contêineres Docker. Significa criar contextos limitados lógicos. Se você está trabalhando sozinho ou em uma equipe pequena, um monólito modular é frequentemente a melhor escolha. É mais fácil de gerenciar que microsserviços puros, mas impõe disciplina estrutural.

Veja um exemplo prático de como estruturar isso:

• Módulo de Autenticação: Lida apenas com login, sessões e tokens. Não sabe nada sobre produtos ou carrinhos de compra.
• Módulo de Pedidos: Gerencia a criação de pedidos. Pode consultar o módulo de autenticação para saber quem é o usuário, mas nunca acessa diretamente o banco de dados de autenticação.
• Módulo de Pagamentos: Integra-se com gateways externos. Recebe dados do módulo de pedidos, mas mantém suas próprias tabelas e lógica isoladas.

Se a IA tentar importar uma função do módulo de pagamentos dentro do módulo de autenticação, você deve ter uma regra automática (como um linting rule ou teste unitário) que falhe. Essa barreira técnica força a IA a respeitar os limites que você definiu.

A Estratégia da "Constituição Arquitetural"

Como fazer a IA lembrar dessas regras em cada prompt? Você não consegue confiar na memória do contexto do chat. A solução documentada por equipes como a WorldlineTech é criar uma "Constituição Arquitetural". Isso consiste em arquivos markdown específicos que a IA deve ler antes de gerar qualquer código.

O arquivo RULES.md é o mais crítico. Nele, você coloca restrições duras. Por exemplo: "O código em modules/grimoire nunca pode importar de modules/weaver". Quando você inicia uma nova sessão de vibe coding, seu prompt inicial (bootstrap prompt) instrui a IA: "Leia o RULES.md e os ADRs relevantes antes de sugerir qualquer mudança". Isso transforma decisões arquiteturais humanas em constraints imutáveis para o modelo probabilístico.

Além disso, exija rastreabilidade de saída. Se a IA propõe uma mudança significativa, ela deve gerar um novo ADR justificando a decisão. Isso cria um ciclo de feedback onde a arquitetura evolui com registro histórico, evitando que a IA "reescreva" decisões passadas silenciosamente.

Enforcement Técnico: Além do Código

Regras de texto são boas, mas enforcement técnico é melhor. Se a IA ignora suas instruções verbais, a infraestrutura precisa barrar o erro. Aqui entram conceitos de segurança e DevOps aplicados à vibe coding.

A Northflank e a Cloud Security Alliance recomendam escopo rigoroso de credenciais. Se cada serviço ou módulo tem acesso apenas às tabelas de banco de dados que lhe pertencem, a IA fisicamente não consegue criar um join cruzado indevido. Imagine que o módulo de usuários tem permissão de leitura/escrita apenas na tabela users. Se a IA tentar acessar orders a partir dali, o banco de dados retorna um erro de permissão. Esse erro força o desenvolvedor (humano ou IA) a repensar a interação, provavelmente criando uma API interna ou evento assíncrono, mantendo o baixo acoplamento.

Outra tática é o uso de sandboxes de execução. Ao rodar código gerado pela IA em ambientes isolados com acesso limitado à rede, você limita o "blast radius" (raio de explosão) de erros. Se a IA acopla indevidamente dois serviços, o impacto é contido e detectável nos logs de monitoramento, em vez de derrubar toda a aplicação de produção.

Prompts Que Preservam Fronteiras

A forma como você escreve o prompt muda tudo. Prompts amplos como "Adicione suporte a PayPal" tendem a causar acoplamento. Prompts baseados em contratos preservam fronteiras.

Em vez de pedir para a IA modificar todo o fluxo, peça para ela implementar um contrato específico. Exemplo:

"Implemente o endpoint POST /payments/create no módulo de pagamentos. Ele deve aceitar um payload JSON contendo orderId e amount. Não modifique o schema do banco de dados de orders. Retorne um status de aprovação ou rejeição."

Note como este prompt:

1. Define o local exato (módulo de pagamentos).
2. Define a interface (payload JSON).
3. Proíbe violações de fronteira (não mexer no schema de orders).
4. Define a expectativa de saída.

Shmilov sugere até usar agentes diferentes para camadas diferentes. Um agente para o frontend, outro para o backend, outro para o banco de dados. Eles se comunicam via especificações de API, não editando os arquivos uns dos outros diretamente. Isso espelha a Lei de Conway: a estrutura do sistema reflete a estrutura de comunicação organizacional (ou, neste caso, de agentes).

Erros Comuns e Como Corrigi-los

Muitos times começam com entusiasmo demais e esquecem a manutenção. Aqui estão os sinais de alerta de que suas fronteiras estão sendo violadas:

• Imports Circulares: O Módulo A importa B, e B importa A. A IA fez isso para "resolver rápido". Corrija introduzindo um terceiro módulo compartilhado ou invertendo a dependência.
• Lógica de Negócio no Controller: Se você vê cálculos de preço dentro de rotas HTTP, a fronteira entre apresentação e domínio foi apagada.
• Drift de Schema: A IA adiciona colunas a tabelas existentes para suportar novas features sem migrar dados adequadamente, quebrando compatibilidade retroativa.

A correção não é apenas editar o código. É voltar ao RULES.md e reforçar a regra violada. Se a IA continua cometendo o mesmo erro, sua regra provavelmente era ambígua. Torne-a explícita. "Não use ORM joins automáticos entre agregados raiz diferentes" é melhor que "mantenha as coisas desacopladas".

Próximos Passos Para Sua Equipe

Se você está começando agora, não tente reinventar a roda. Siga este checklist mínimo para proteger sua arquitetura de vibe coding:

1. Escolha a Estrutura: Monólito modular é o ponto de partida seguro. Defina 3-5 módulos principais.
2. Escreva o Constitution File: Crie um ARCHITECTURE.md com regras de importação e ownership de dados.
3. Configure o Bootstrap Prompt: Automatize a leitura desse arquivo em todas as sessões de IA.
4. Restrinha Credenciais: Dê ao ambiente de desenvolvimento da IA apenas as permissões necessárias para o módulo atual.
5. Revise Contratos: Antes de aceitar código que cruza fronteiras, revise a interface proposta.

A vibe coding não é o fim da arquitetura de software; é uma nova fase dela. A velocidade da IA exige mais disciplina humana, não menos. Ao definir fronteiras claras, você transforma o risco de acoplamento em vantagem competitiva, permitindo que sua equipe itere rapidamente sem afundar em dívida técnica invisível.