Vibe coding para testar antes de lançar feature nova: parta a entrega em 2
Um colaborador precisava de uma coisa com urgência. Moretté partiu a entrega em 2: sobe o que já se sabe que funciona, confirma em produção, e só então soma o novo.
Quem está te apressando empurra você para o formato mais arriscado de entregar: tudo junto, de uma vez, porque parece o caminho mais curto. Moretté fez o contrário ao vivo, atendendo um colaborador que precisava de uma coisa com urgência. Ele partiu o pedido em 2 entregas. Sobe agora o que já se sabe que funciona, confirma em produção que aquilo atende, e só então soma o pedaço novo.
A decisão inverte a ordem que a pressa sugere. O problema mais grave era o que já tinha solução pronta e rodando. O pedaço novo, que ninguém tinha visto funcionando ainda, era o que podia esperar.
Ele concordou com a pressa e recusou o pacote fechado
O pedido chegou com prazo curto, e Moretté começou concordando com a parte fácil: dava para usar ali mesmo o que estava à mão. O que ele recusou foi mandar as 2 coisas de uma vez.
"dá para pôr a mensagem, mas primeiro você resolve um problema mais grave. Você usa o que a gente já sabe que tá funcionando, você coloca em produção o que a gente já sabe que funciona, testa. Funcionou? Perfeito. Então a gente sabe que ali daquele jeito que funciona e te atende."
A entrega de hoje continua no lugar, e só um pedaço dela vai para depois. Quem estava apressado recebe agora a solução do problema que mais dói, feita com a peça que já tem histórico de funcionar. O que fica para o segundo momento é a peça sem histórico.
Testar em produção é a metade que o vibe coding costuma pular
Subir a parte provada só fecha quando alguém confirma, no ambiente real, que ela atende o que foi pedido. É o passo do meio da frase dele, o "testa. Funcionou? Perfeito." Só depois dessa confirmação o assunto vira a feature nova.
Confirmar de verdade também é entrar pela porta de quem vai usar. Vale testar como usuário comum, sem ser admin: a sua conta atravessa permissões que o usuário final esbarra, e o que passa no seu login pode travar no dele.
Quem faz vibe coding com pressa costuma acertar a primeira metade e abandonar a segunda. Sobe o pedaço seguro, fecha o terminal, vai cuidar do próximo pedido. A parte nova acaba chegando em cima de uma base que ninguém conferiu, e aí a divisão perdeu a razão de existir.
Adiar a parte nova sai barato porque ela era separável
Logo depois, Moretté descreve o pedaço novo como um acréscimo. É uma integração, e nas palavras dele, "não é uma atualização pesada". Essa característica é o que torna a regra aplicável sob pressão. Quando o pedaço novo é somável, e não uma reescrita que atravessa o que já existe, partir a entrega em 2 momentos custa quase nada: você paga uma segunda subida e ganha a confirmação de que a base atende.
A pergunta que decide, antes de aceitar o pedido inteiro de uma vez, é se o pedaço novo soma depois ou se ele obriga a mexer no que já funciona. Quando ele soma depois, a pressa para de ser argumento para mandar tudo junto, porque dividir não gasta prazo, gasta uma segunda ida ao ar.
Onde cada pedaço roda e em que ordem ele é entregue
Na mesma conversa, Moretté já tinha decidido proteger lógica sensível no servidor. Aquela decisão responde onde cada pedaço do sistema roda; esta responde em que ordem cada pedaço é entregue. As duas cabem no mesmo pedido e nenhuma substitui a outra. Foi o mesmo caminho de vibe coding para testar em ambiente local antes do servidor do cliente.
O que fazer no próximo pedido urgente
Da próxima vez que alguém te apressar, separe o pedido em 2 listas antes de escrever qualquer coisa. Na primeira, o que já rodou em produção antes. Na segunda, o que nunca rodou. Suba a primeira hoje, com o problema mais grave resolvido dentro dela, e confirme no ambiente real que aquilo atende quem pediu. A segunda vira uma entrega própria, sem prazo emprestado da urgência da primeira.
Esse é o tipo de decisão que o vibe coding torna mais frequente: com o código saindo rápido, a ordem em que as coisas vão ao ar passa a valer mais do que a velocidade de escrevê-las. E quem pediu com urgência não sai perdendo. Recebe no mesmo dia a parte que resolve o problema mais grave, com a confirmação de que ela atende, em vez de um pacote inteiro no ar que ninguém olhou.
A decisão inteira, com o pedido urgente do outro lado, está em assistir à live.