Vibe coding para trocar de modelo quando um trava sem perder o fio

Quando o crédito de uma ferramenta acaba no meio de uma tarefa, quem continua trabalhando é quem tem o estado do trabalho escrito fora da conversa. Thiago mostrou isso ao vivo enquanto executava a refatoração da plataforma que ele está construindo para fazer o trabalho de uma agência de marketing. No meio da execução, o crédito semanal da assinatura em que o Codex rodava acabou. Ele passou a tarefa para o Cursor no modo automático, para ver se dava conta de continuar.

Antes de mandar a tarefa, ele mandou outra coisa primeiro:

Beleza, vamos passar o relatório aqui.

E só depois veio o bastão:

Passei o bastão aqui pro cursor para que ele faça tudo

O bastão é a tarefa, e o relatório é o estado em que ela estava. Quem manda só a tarefa entrega uma ordem para uma ferramenta que não faz ideia de onde o trabalho parou.

O limite chega justamente no dia em que o trabalho rende

Limite de uso é uma falha que você não conserta e quase não prevé. Não existe correção do seu lado, e o horário em que ela chega depende de quanto você já produziu. Thiago passou a manhã disparando agentes em paralelo, viu o consumo subir e comentou que aquele ritmo "Torra uso semanal num dia".

Um bug aparece porque o código está errado, e dá para investigar. O limite aparece porque o uso foi grande, o que coloca o bloqueio bem no meio da tarefa mais longa da semana, com várias frentes abertas e nenhuma fechada.

Esperar o reset é a escolha que ninguém toma de propósito

A opção padrão, quando o limite bate, é fechar o notebook e voltar quando o contador zerar. Quase ninguém decide isso, acontece por inércia, porque a alternativa exige uma preparação que não existe naquele instante. O preço é a sessão inteira. E o custo não é só o tempo parado: quando você voltar, vai ter que reconstruir na cabeça onde cada frente estava.

Thiago não esperou. Trocou de ferramenta e seguiu na mesma missão, no mesmo ambiente, com o Overclock rodando os painéis onde os agentes trabalham.

O que atravessa a troca é o documento, e por isso o vibe coding precisa de um

A memória da conversa não muda de casa. O histórico ficou no Codex. Tudo que o Cursor recebeu foi o que estava escrito: o relatório do que já tinha sido feito, do que faltava e do que estava quebrado.

Quem trabalha só dentro do fio do chat não tem o que passar nessa hora. O contexto morre junto com o acesso à ferramenta, e a única saída vira esperar o reset. Por isso a preparação é anterior ao bloqueio. Manter o estado do trabalho num documento vivo é o que transforma a troca de modelo num repasse em vez de um recomeço.

Serve como regra de vibe coding para qualquer um: o que não estiver escrito fora do chat não sobrevive ao fim do acesso. O plano, as decisões tomadas, o que já passou nos testes e o que quebrou. Com isso registrado, qualquer ferramenta pega a partir dali; sem isso, você fica preso ao fornecedor que travou.

Isso é o que também sustenta a checagem de evidência real em vez de intenção, onde você não acredita na resposta sem verificar o banco. E é similar ao validar consentimento antes de publicar, onde o registro ativo é o que decide se a peça segue.

O substituto trabalha em outro ritmo, e a conta chega na máquina

O Cursor pegou o relatório e engatou num ritmo bem diferente. Thiago olhou a tela e disse que "Agora ele disparou penca aqui". Os bugs vieram um atrás do outro. A memória do computador foi para 80%, a CPU ficou no talo em 70% e 74%, e ele mandou fechar os painéis que continuavam abertos para liberar recurso.

Ele encerrou a transmissão ali:

eu vou ter que matar a live porque eu tô sem memória

O trabalho seguia rodando quando a live acabou. A troca destravou a execução e mudou o problema de lugar, do limite de crédito para a memória da própria máquina.

Um substituto não é peça de reposição idêntica. Ele tem outro apetite de recurso e outro modo de falhar. O mesmo relatório entregue a duas ferramentas diferentes vira dois comportamentos diferentes, e o que era confortável com uma pode saturar o computador com a outra.

O que fazer antes do seu limite acabar

Escreva o estado do trabalho num arquivo hoje, antes de precisar. Um documento com o plano, o que já entrou, o que está em teste e o que quebrou, atualizado durante a execução e não no fim do dia, porque o bloqueio não avisa.

E quando trocar, acompanhe de perto as primeiras tarefas da ferramenta nova. Olhe a memória e a CPU antes de sair da frente da máquina. O próximo limite que te para pode não ser o da assinatura. Vale também saber que um modelo pode fazer controle de qualidade automático enquanto você trabalha em outra coisa, conferindo se o que saiu estava dentro dos critérios. E antes de tudo isso, você precisa de um cliente pagante que valida se a operação que você automatizou funciona, como aparece em vibe coding para validar mvp com primeiro cliente pagante. O mesmo problema apareceu em vibe coding para quando a ferramenta nao suporta a tarefa. Vale ver como isso terminou em como continuar vibe coding quando acaba o limite.

Dá para ver a troca acontecendo e o desfecho na live inteira, e o resto de como esse jeito de construir funciona está no vibe coding.