Vibe coding para reverter código quebrado: quando parar de remendar

Quando a IA começa a quebrar coisas que já estavam funcionando, mandar mais um prompt de correção costuma ser a pior opção disponível. A saída é voltar o código inteiro para o último estado em que ele estava de pé. myosbad fez isso ao vivo, no meio de um projeto para um cliente, depois de ver a IA transformar uma tela pronta num site preto.

A ordem que ele deu foi curta:

Volta do jeito que tava no início. Volta o código todo, mano.

Ele descartou tudo o que a IA tinha produzido desde o ponto em que a tela funcionava, inclusive as partes que talvez estivessem certas.

A sessão avisa antes de quebrar de vez

O pedido dele era pequeno. Quadrados e textos do site estavam saindo transparentes, e ele queria que parassem de sair.

Só pedi para ele, ó, essas partes assim, ó, tipo assim, de quadrado em texto, não deixar transparente.

O que voltou foi o site inteiro escurecendo. "O site está preto", ele disse, olhando para o projeto que vinha elogiando desde cedo na mesma sessão: "O bagulho tava bonitinho, mano." Ele reformulou o pedido e mandou de novo, e continuou recebendo a mesma tela errada:

Eu já pedi para fazer daqui três, quatro vezes já, mano.

Esse é o sinal mais fácil de ignorar, porque cada tentativa parece estar a um detalhe de dar certo. Depois de 3 ou 4 idas sem sair do lugar, o que você está medindo já não é a qualidade da sua frase, é a da sessão. Ignorar aviso é um hábito que se treina em coisas pequenas e cobra caro nas grandes, e é por isso que vale vibe coding para nunca silenciar aviso do lint: quem se acostuma a apagar o sinal amarelo chega no site preto sem ter percebido o caminho. Vale ver como isso terminou em yolo mode.

Junto dele veio a comparação com o dia anterior:

ontem eu tava fazendo coisa esse tipo aqui, menos de 5 minutos tava pronto

O diagnóstico dele sobre a IA naquele dia foi direto: "Papo reto, mano. Tá muito burra." A ferramenta era a mesma e o projeto era o mesmo, e o que saía dali tinha mudado de qualidade de um dia para o outro. Quando um ajuste que ontem levava 5 minutos hoje não sai em 3 ou 4 tentativas, o problema deixou de ser a sua frase.

O momento de mandar voltar tudo

O estrago não parou no fundo preto. Logo depois ele foi pedir outra coisa, um comportamento de navegação no painel do cliente, para que clicar num contato dentro do funil levasse direto para a conversa daquela pessoa. Abriu a tela para conferir e não reconheceu o que estava vendo:

Ô Deus, que isso, velho? Não, não. Olha isso, velho. O que que ele fez aqui?

Foi aí que ele parou de corrigir e mandou voltar o código todo. A comparação que ele fez em seguida é a régua que ele usou para decidir:

Ontem tava perfeito, hoje tá uma porcaria, mano. Não é possível.

Ele pediu a reversão para a própria IA, em português, do mesmo jeito que pedia qualquer outra coisa. A live não mostra o resultado dessa volta. Mostra o que sobrou nele depois:

Agora eu tô com medo de quebrar meu projeto inteiro

Enquanto remendava, ele estava irritado. O medo chegou depois, junto com o tamanho do estrago, quando já não servia de aviso.

Por que reverter ganha de mais uma tentativa no vibe coding

Remendar em cima de código quebrado é uma aposta: a de que a próxima tentativa vai entender o que as anteriores não entenderam. Enquanto a aposta corre, o estrago se acumula, porque cada tentativa mexe nos arquivos em que a anterior já tinha mexido, e junto com ele some a referência do que estava certo. Você deixa de saber quais partes da tela vieram do código bom e quais vieram das tentativas frustradas.

Perder essa referência é o que impede você de testar. Qualquer erro que aparecer pode ser o problema original ou pode ser um dos remendos, e você acaba depurando um código que nem você nem a IA escreveram por inteiro. Boa parte desse código você nunca leu, o que é normal em vibe coding e é exatamente o que torna a depuração cara. Isso aparece também em refatorar codigo.

Reverter resolve por descarte. Você volta para um ponto conhecido, onde a tela fazia o que você viu ela fazer, e paga o preço de refazer o trabalho da última hora. Esse preço é fixo e você sabe qual é antes de pagar. O preço de continuar remendando só aparece depois, e cresce enquanto você tenta descobrir de quanto ele é. Decidir por descarte em vez de por insistência é uma das poucas manobras de vibe coding que funcionam melhor quanto pior está o dia. Vale ver como isso aparece também em como validar ideia de plataforma no vibe coding.

O gatilho para a próxima vez

Você já pediu a mesma correção mais de 2 vezes sem sair do lugar? Alguma coisa que funcionava ontem parou de funcionar hoje?

Se qualquer uma das duas for sim, pare de escrever prompt e volte o código para o último estado que você viu funcionando. Depois refaça o pedido a partir dali, uma coisa de cada vez.

Para isso ser barato, você precisa saber onde fica o último estado bom antes de precisar dele. Vale gravar um ponto de retorno sempre que a tela estiver do jeito que você quer, e não quando ela já estiver quebrada. Construir em público, como as leis do movimento cobram, ajuda nisso: com a gravação rodando, dá para voltar e achar o minuto em que a tela ainda estava boa.

Dá para assistir à live e ouvir a sequência inteira, das primeiras tentativas com os quadrados transparentes até a ordem de voltar o código todo. Vale prestar atenção também no outro momento daquela mesma sessão, quando ele concluiu que o problema estava na própria frase e parou para reescrever o pedido inteiro em voz alta. A parte difícil é separar um caso do outro antes de gastar a tarde no errado.