--- title: "O Imposto do Loop de Correção: Onde os Orçamentos de Vibe Coding Realmente Vão" description: "As contas de vibe coding não vêm da geração, mas das correções. Como os modelos de créditos e tokens no Lovable, Bolt e Replit precificam o loop de debugging." date: 2026-06-10 language: pt canonical: https://vibecodingcompare.com/pt/field-notes/the-fix-loop-tax source: "Vibe Coding Compare field notes" --- Toda ferramenta de vibe coding vende a mesma ilusão: que o custo de um app é o custo de gerá-lo. O primeiro prompt é barato e espetacular. O orçamento morre depois, no **loop de correção**, e o loop de correção não é um caso isolado. É o modo de operação normal de toda ferramenta de geração de código neste site assim que um app ultrapassa um tamanho trivial. ## Por que o 20º prompt custa mais que o 1º O primeiro prompt escreve em uma tela em branco; o modelo é bom nisso, e uma rodada geralmente traz um progresso visível. O 20º prompt precisa modificar um sistema existente que o modelo lembra apenas parcialmente. À medida que as bases de código crescem, elas excedem o contexto de trabalho da IA, e o modelo começa a contradizer suas próprias decisões anteriores. As correções tratam sintomas em vez de causas raiz, então um remendo em um lugar quebra outro, um padrão que os desenvolvedores chamam de **prompt whack-a-mole**. A iteração também infla o artefato: o contexto limitado faz com que a IA reescreva funções utilitárias que ela não consegue ver, deixando lógica duplicada e uma colcha de retalhos de estilos que torna cada correção subsequente mais difícil de implementar. Assim, a economia unitária se inverte. Prompts iniciais compram funcionalidades; prompts tardios compram tentativas. E cada tentativa é cobrada. A economia unitária se inverte: prompts iniciais compram funcionalidades, prompts tardios compram tentativas, e cada tentativa é cobrada. ## O que os medidores dizem Os números da pesquisa, por ferramenta, todos vindos de relatos documentados de usuários. Lovable vende créditos, o plano Pro base custa 25 euros por 100 ao mês. Usuários relatam que o consumo por prompt sobe de cerca de 1,2 créditos para 3-4, uma **inflação de custo de quase dez vezes** ao longo do tempo, com até perguntas sobre o código consumindo frações de um crédito. Avaliadores descrevem o loop canônico: créditos gastos em chats de depuração onde o agente introduz novos erros enquanto resolve o primeiro, e relatos de que ele afirma que uma correção foi feita quando não foi. A 3-4 créditos por prompt, um mês de 100 créditos rende menos de 30 tentativas. Bolt vende tokens, 10 milhões no nível Pro de $25. A reclamação principal é pagar por falta de progresso: a edição de diff que é imediatamente reescrita sem a alteração, "apenas queimando tokens sem mudanças", e um limite mensal consumido por um erro gerado, deixando o desenvolvedor esperando o próximo mês para corrigir o erro da própria ferramenta. Avaliadores também descrevem um esgotamento opaco durante loops complexos, sem detalhamento de quais edições consumiram os tokens. Replit tem a curva mais íngreme porque o preço é baseado no esforço: a conta acompanha o quão duro o agente trabalha, e nada faz um agente trabalhar mais do que depurar a si mesmo. Casos documentados: $25 de créditos em menos de um dia, $350 em um único dia, $700 em um mês e $1.500 em cobranças surpresa de banco de dados, impulsionadas em parte por backups por checkpoint. A leitura mais sombria da comunidade é estrutural: mais erros significam mais correções, que significam mais execuções cobradas. Medidores diferentes, mesma forma. A unidade de preço é a tentativa, e a depuração é a atividade que maximiza as tentativas. Cada tentativa de depuração pode consumir mais créditos, tokens e dinheiro que a anterior. ## O imposto, nomeado Chame-o de **imposto do loop de correção**: a diferença entre o que você pagaria se a geração funcionasse de primeira e o que você realmente paga. Ele tem três propriedades relevantes. É invisível no momento da compra, já que o preço de tabela descreve o caminho ideal. É regressivo, atingindo mais fortemente os desenvolvedores menos capazes de diagnosticar causas raiz, porque eles fazem mais rodadas. E está correlacionado com a importância: os apps que geram os loops mais profundos são os apps de negócios ricos em casos isolados e pesados em autenticação que você mais precisa que funcionem, o tipo examinado em [Lovable vs Bolt](/pt/matchups/lovable-vs-bolt). O imposto também não fica apenas na coluna de custos. Cada rodada cobrada em uma funcionalidade próxima à autenticação relança os dados de segurança de [o que '45% do código de IA é vulnerável' realmente significa](/pt/field-notes/what-45-percent-vulnerable-means), e o loop em si é a forma cotidiana do [problema do Dia Dois](/pt/field-notes/the-day-two-problem): a fase de manutenção onde cada mudança corre o risco de quebrar a anterior. O medidor é apenas a parte que você consegue ver na fatura. ## Pagando menos, ou nada Em ferramentas de geração de código, as mitigações são artesanais: limite o escopo dos prompts, faça commit de cada estado funcional, leia os diffs antes de aceitar e reconheça o desvio cedo o suficiente para parar. Uma ferramenta de assinatura fixa como [Cursor](/pt/matchups/cursor) ao menos limita o pior caso a um valor mensal conhecido. A resposta estrutural é notar quais apps não precisam de um loop. Um portal ou ferramenta interna é composto principalmente por autenticação, permissões e CRUD, e em uma plataforma como Softr isso é configuração: altere uma configuração, a mudança é feita, sem rodada de regeneração e sem tentativa cobrada. Softr tem créditos de IA para seu Co-Builder, mas como tudo o que a IA faz também pode ser feito manualmente, um **saldo vazio nunca bloqueia uma correção**. Para apps de negócios, o loop de correção mais barato é aquele que não existe. Quebre o ciclo com técnica e assinatura limitada, ou evite o ciclo em uma plataforma de config.