Pay as you go no vibe coding: consentimento por ação e teto da reserva

Pay as you go num SaaS de crédito só segura se o usuário autorizar o gasto por ação e o sistema reservar o ciclo inteiro. Thiago fechou esse desenho na live do Taurus Hub com um teto de 20 créditos. A geração começa, o custo administrativo sobe para 25, e aquela operação captura no máximo os 20 já reservados. Cobrar 25 depois da reserva quebraria o controle de saldo. Poderia deixar a carteira negativa.

O agente colocou o custo colado no botão. Ação manual: "Esta ação utilizará 18 créditos." Autopilot: "Este ciclo produzirá 30 carrosséis e reservará até 540 créditos." Thiago quis o sim antes dele apertar o botão para criar.

Antes do botão, a ação reserva 18 créditos

Na ação paga o usuário confirma, executa ou cancela. Os 18 créditos saem do saldo disponível e viram reserva antes da execução. Se a operação falha sem executar, a reserva volta. Só consome quando a operação de fato roda.

A proposta de texto foi "essa ação custará crédito. Você aceita?". Thiago concordou com ressalva no copy e fechou o ponto:

Não, dessa forma tem o consentimento sempre do usuário para coisas automáticas.

A frase que sobrou para o usuário: "Ação custará 18 créditos. Os créditos serão reservados antes da execução."

No vibe coding, o Autopilot reserva 540 créditos de uma vez

No Autopilot, 30 carrosséis rodariam com um único sim. Thiago autorizou o pacote inteiro. O aviso: "Este ciclo produzirá 30 carrosséis e reservará até 540 créditos." Dentro desse teto, o Autopilot produz, agenda e publica sem nova confirmação por conteúdo. Pausa e cancelamento continuam depois do sim.

O usuário configura o ciclo e o sistema calcula a reserva máxima. Com o consentimento, o sistema reserva o ciclo inteiro, executa, captura aos poucos e libera o que sobrou ao concluir ou cancelar. O resumo do ciclo traz quantidade, canais, período, frequência e formato, com o orçamento total reservado. Pede também autorização de publicação e as regras de pausa.

Thiago repetiu a regra do agente:

É reservar, não é consumir. Beleza, tá certo.

Texto para o ciclo: "Esse ciclo reservará até 540 créditos para executar as ações configuradas. O autopilot poderá produzir, agendar e publicar sem novas confirmações dentro desse limite. Você poderá pausar, cancelar quando quiser." No vibe coding de um SaaS de crédito, o teto entra na hora do sim. Os 30 carrosséis só saem depois da reserva. Thiago fechou o recorte:

Concordo com tudo.

Reserva de 20, custo sobe para 25, a carteira não fura

Reserva 20, a geração começa, o custo administrativo muda para 25. Aquela geração captura no máximo os 20 já reservados. As próximas operações usam a regra nova de 25. Mudança de custo vale para operação nova.

O risco, nas palavras do agente: "Cobrar 25 depois de reserva quebraria o controle de saldo. Poder deixar a carteira negativa." Thiago concordou e perguntou como o sistema ia fazer isso:

Ah, pode ser. Agora, como que ele vai fazer isso? Sei lá.

Telemetria com o time, recarga automática fora do beta

Thiago recusou tabela de consumo visível na homepage no beta. O agente queria a tabela mais um aviso. A resposta:

Não quero isso agora no início. Deixa a telemetria apenas com a gente. Quando tiver tudo redondo, a gente lança aí.

Quem usa o beta vê saldo atual e o histórico de créditos consumidos por operação concluída. A homepage não lista "carrossel custa X". Recarga automática com cartão vinculado ficou fora do beta:

Tá bom. Deixa fora do bet, então.

O "bet" da transcrição é o beta.

Amanhã, no vibe coding do seu SaaS de crédito, coloque o custo no botão e reserve o teto do ciclo antes de executar. Se o custo administrativo subir no meio, aquela geração captura no máximo o reservado.

O pente fino de testes da mesma live está em property based testing.

Dá para assistir à live e ouvir o aviso antes do botão e o teto de 20 contra 25.