Vibe coding para testar em ambiente local antes do servidor do cliente

Jhonatan precisava fazer um disparo de mensagens para saber se o fluxo que tinha acabado de montar funcionava. Ele podia rodar no servidor do cliente, onde estava a base de contatos de verdade, e teria a resposta na hora. Preferiu rodar na própria máquina. A escolha parece pequena e é a coisa mais importante que ele decidiu naquele minuto, porque disparo produz efeito fora do software: mensagem que chegou no telefone de alguém não tem como ser desfeita. A fala dele se embola no meio e termina fechando em local:

"Precisar fazer um disparo aqui. Vou rodar localmente. Quer saber? Não vou rodar local, mas não vou mandar no servidor da igreja da empresa, não. Vamos trabalhar aqui [música] de forma local."

O "[música]" é marcador da legenda automática do YouTube, não parte da frase dele.

Isso é tudo o que a live tem sobre o assunto: uma frase e nenhum acidente. Ninguém recebeu mensagem errada e não existe história de terror aqui. Daqui em diante, o que vem é raciocínio em cima dessa decisão.

Efeito que fica dentro do sistema e efeito que sai dele

"Não teste em produção" é conselho velho, e o motivo que sempre vem junto é a corrupção de dado: você escreve a linha errada, roda o script 2 vezes, restaura o backup e perde uma manhã com isso.

Um disparo de mensagens não cabe nessa categoria. O efeito do teste não fica dentro do banco. Ele atravessa a fronteira do software e chega no celular de uma pessoa que não faz parte do seu teste e vai ler aquilo como comunicação de verdade. Não existe rollback de mensagem entregue. Dá para mandar outra pedindo desculpa, o que é uma segunda mensagem, e não a remoção da primeira.

O critério útil antes de rodar qualquer coisa é onde o efeito para. Escrita em banco, arquivo gerado, fila interna, cache quente: você desfaz tudo isso com backup e paciência. Mensagem, e-mail, cobrança no cartão, webhook para o sistema de um terceiro, notificação no aparelho de alguém: essa família não tem botão de voltar. As 2 chamadas de código podem ter a mesma cara no editor, e o custo do erro é de outra ordem de grandeza.

O servidor era do cliente, e essa é a segunda camada

A frase dele deixa claro qual servidor estava em jogo, e não era o dele. Aí entra o problema que se soma ao primeiro: além de ser produção, é produção de outra pessoa.

Quem recebe uma mensagem estranha de madrugada não vai descobrir que existia um desenvolvedor testando um fluxo. Vai reclamar com quem apareceu como remetente. Quem responde essa reclamação e quem gasta a reputação construída durante anos com aquela base é o cliente, e o estrago cai em cima de quem não estava na sala no momento em que a decisão de testar foi tomada. Você tem acesso ao servidor, mas não é dono do relacionamento que roda em cima dele.

Por que a tentação é maior no vibe coding

No vibe coding esse atalho fica mais tentador do que no desenvolvimento tradicional, e por um motivo mecânico. O agente entrega o fluxo pronto em minutos. Você descreve o envio, ele escreve o código, e a coisa parece pronta antes de você ter tempo de pensar em como conferir. O jeito mais rápido de saber se funcionou é rodar de verdade. Vale ver como isso terminou em vibe coding para nao misturar dois produtos no mesmo servidor. Isso aparece também em vibe coding para nao oferecer gpu local se precisa de instalador. Isso aparece também em wordpress local.

Montar um ambiente de teste é o único passo lento do processo inteiro e o único que não produz nada visível na tela. Todo o resto do dia gerou artefato: tela nova, integração respondendo. O ambiente de teste gera uma sensação de estar parado, e quando o ritmo do trabalho é medido em coisas que aparecem, o passo que não aparece é o primeiro a ser cortado.

Some a isso que o agente não tem como distinguir um envio de teste de um envio real. Para ele, as 2 chamadas são idênticas: mesma função, mesmos parâmetros, mesma credencial. A diferença mora inteira em quem está do outro lado do número, e essa informação não está no código que ele leu.

Existe um corte parecido com este, que separa por outra coisa. Em como separar ambiente de cliente e projeto pessoal, a divisão é pelo grau de estabilidade da ferramenta: o beta você experimenta nos projetos pessoais, o trabalho do cliente roda no que já provou ser estável. Aqui a divisão passa por onde o código executa e por quem sente o efeito colateral. São 2 cortes distintos na mesma preocupação de não fazer o cliente pagar a conta do seu experimento.

A partir daqui é análise minha

A live acaba na frase. O resto é o que eu faria com essa decisão, e vale para qualquer fluxo montado em vibe coding que termine em envio para gente de verdade.

Rodar local não protege por si só. Código rodando na sua máquina com credencial de produção manda mensagem de verdade igual, porque o provedor de envio não sabe nem se importa de qual IP saiu a chamada. Trocar de máquina sem trocar de destino não muda nada. O que protege é para onde as credenciais daquele ambiente apontam, e essa é a pergunta que precisa ser respondida antes de o script rodar. Vale ver como isso terminou em ambiente de homologacao.

O teste honesto desse tipo de fluxo precisa de um destino de mentira. Ou uma lista curta com números seus e de mais 1 ou 2 pessoas que aceitaram receber, ou um modo que registra o que teria sido enviado sem enviar nada, gravando destinatário e conteúdo num arquivo para você conferir depois. Se o seu fluxo não tem esse modo, ele ainda não está pronto para ser testado. Construir esse modo faz parte de construir o fluxo, e não é um extra que se resolve depois que tudo estiver funcionando.

O passo que quase todo mundo pula é o limite de segurança no primeiro envio real. Antes de soltar contra a base inteira, limite a quantidade, mesmo que tudo já tenha passado no teste com destino falso. Uns 5 ou 10 contatos escolhidos por você, e os números aqui são ilustração minha, não medida da live. Um erro que atinge 5 pessoas termina num pedido de desculpas por telefone. O mesmo erro atingindo a base inteira vira um problema entre o seu cliente e as pessoas dele, numa conversa em que você não vai estar presente. Da mesma forma, se a estrutura que você desenhou não consegue responder onde ela deixa de funcionar, ela ainda não está pronta para o cliente - vale validar isso antes.

O que fazer antes do próximo disparo

Antes de rodar qualquer fluxo que produza efeito fora do sistema, responda 2 perguntas por escrito. Para onde as credenciais deste ambiente apontam neste momento, e quantas pessoas o pior caso alcança se o fluxo executar 2 vezes ou disparar para a lista errada. Se você não conseguir responder as 2 com números, o ambiente ainda não está pronto para receber o teste, esteja ele na sua máquina ou não.

O momento inteiro está na live em que ele toma essa decisão, onde ele hesita, se corrige no meio da frase e decide em voz alta.