Vibe coding para proteger lógica sensível no servidor

O código que desce para a máquina do usuário fica ao alcance dele. Antes de construir qualquer funcionalidade, vale separar qual metade daquele código pode descer e qual metade nunca desce. Moretté fez essa separação em voz alta na live "Just Coding, No Stress", explicando a um colaborador por que um trecho do sistema ia ficar inteiro do lado do servidor.

Ele não empurrou tudo para o servidor. Na sequência delimitou o que precisa mesmo rodar do lado do usuário, e o corte que fez passa por dentro de uma única funcionalidade, separando o que mostra do que decide.

A regra fica de um lado, a apresentação do outro

Os dois estavam desenhando um menu. Sobre a parte que aplica a regra, ele foi direto:

"Isso aí fica só no na parte do servidor, então não tem como ninguém copiar, certo? Então, só você tem acesso, é só seu, vamos assim dizer, a não ser que você espale para alguém, eh, porque ele fica na parte do servidor, o jogador não precisa ter conhecimento disso."

Logo depois, ele delimitou o outro lado:

"A partir do momento que você interagir com o menu, a gente vai ter uma parte que vai ter que rodar no cliente, que no caso seria só a parte da mensagem"

O pedaço que desce para o cliente é a exibição: desenhar o menu, mostrar o texto que aparece depois que a decisão já foi tomada em outro lugar. O critério que produziu aquela decisão não viaja junto.

Preço e permissão têm o mesmo endereço que a regra daquele menu

Ele constrói para um servidor de jogo, e no vocabulário dele o cliente é a máquina do jogador. Troque por navegador, por aplicativo, por qualquer coisa que roda no aparelho de quem usa, e a divisão continua de pé. Preço final, permissão de acesso, limite de uso, cálculo de pontuação, valor de desconto: são regras que perdem a graça se o usuário puder ler o critério e mexer no número. O endereço delas é o servidor.

Ao cliente sobra a parte que precisa aparecer na tela. Um menu tem que ser desenhado, uma mensagem tem que ser exibida, e isso desce porque não tem outro jeito. Desce sem carregar o critério junto. Isso aparece também em skill claude code.

Vibe coding é rápido demais para essa fronteira ficar implícita

Quando você descreve a funcionalidade em uma frase e o assistente devolve o arquivo pronto, a escolha de onde cada pedaço roda já vem embutida na resposta, e você não participou dela. Foi por isso que ele parou o trabalho e explicou a divisão ao colaborador antes de existir código. Boa parte do que o vibe coding exige de você são as poucas decisões que o modelo não tem como tomar no seu lugar, e a fronteira entre cliente e servidor é uma delas. Essa mesma decisão de repartir o trabalho antes de começar aparece também em vibe coding com varias sessoes de ia ao mesmo tempo. Vale ver como isso terminou em vibe coding para nao misturar dois produtos no mesmo servidor.

Outro builder atacou a ponta oposta do mesmo problema e escreveu sobre segurança de painel admin, com subdomínio separado, senha forte e segundo fator. Aquele cuida de quem consegue entrar pela porta; este cuida do que nunca sai do servidor.

O mesmo princípio, aplicado a ele mesmo

Poucos minutos depois, procurando uma imagem antiga para mostrar ao colaborador, ele foi abrir as próprias pastas com a tela compartilhada e se conteve antes:

"Vamos ver se vai ser alguma coisa confidencial aqui. Tá na live."

Mais adiante, passando rápido por uma imagem, ele comentou:

"Quase que saiu dado da VM."

Ele percebeu a tempo e se segurou. É o mesmo raciocínio da conversa anterior, aplicado a outro canal: a transmissão ao vivo também é um lugar por onde coisa sensível pode chegar do outro lado. Quem trabalha com a tela compartilhada ganha uma checagem a mais na rotina, e a dele foi conferir a pasta antes de mostrar. Essa é a mesma disciplina de vibe coding para testar antes de lançar feature nova: a conferência acontece enquanto ainda dá para voltar atrás, não depois que a coisa já saiu. Dá para assistir à live e ver os dois momentos com poucos minutos de distância.

2 listas antes de pedir o código

Pegue a próxima funcionalidade da sua fila e escreva 2 listas. Na primeira, o que a tela precisa mostrar. Na segunda, o que o sistema precisa decidir para que a tela mostre aquilo. A primeira lista pode rodar no aparelho do usuário. A segunda fica no servidor, e o cliente recebe só a resposta pronta.

Quando as duas listas se misturam, costuma ser porque a regra virou um parâmetro que a tela manda de volta. É fácil deixar isso passar no vibe coding, porque o código funciona igual dos dois jeitos, e a diferença só aparece quando alguém resolve mexer no que chegou até a máquina dele.