← todos os posts
Dores 9 min de leitura

Funcionava. Pedi uma coisa nova. Quebrou outra.

Consertar uma coisa e quebrar outra tem nome, e a defesa não é técnica: é ter a foto do antes, tirada antes de pedir a mudança.

"Fix one thing, break another."

Traduzindo: conserta uma coisa, quebra outra. Essa frase é da comunidade de fora, mas eu poderia ter pegado ela em português em qualquer grupo brasileiro. É a reclamação mais persistente de todo esse movimento — apareceu forte em 2025 e continua forte em 2026, apesar de os modelos terem ficado muito melhores no meio do caminho.

Isso já devia te dizer uma coisa: não é problema de modelo. Modelo melhor gera código melhor. Não gera memória do que estava funcionando no seu app.

O nome disso em engenharia é regressão — quando uma mudança quebra algo que já funcionava. Guarde a palavra, porque ela serve pra pedir ajuda direito. "O app tá bugado" não é um pedido. "Isso é uma regressão: o cadastro funcionava antes desta mudança e parou depois" é.

O estrago não é o bug

Vou ser direto sobre onde o dano realmente acontece, porque quase todo mundo olha pro lugar errado.

O bug você conserta. Custa crédito, custa uma tarde, mas conserta.

O que não conserta é o que fica na sua cabeça depois da terceira vez: você começa a ter medo de pedir a próxima funcionalidade. Passa a tratar o estado atual do app como uma coisa frágil, que é melhor não tocar. Deixa de pedir a melhoria que o cliente pediu porque "tá funcionando, vai que quebra".

E aí acabou. Software de negócio precisa mudar — preço muda, regra muda, cliente pede coisa nova. Software que ninguém tem coragem de mexer já morreu, só não caiu ainda.

Então o objetivo deste post não é evitar toda regressão. Isso não existe, nem com programador humano. O objetivo é te devolver a coragem de pedir a próxima mudança — e a coragem vem de conseguir voltar atrás, não de acertar de primeira.

A causa que ninguém te explica

Aqui está o buraco de verdade, e ele não é técnico:

Você não sabe o que estava funcionando ANTES.

Pensa comigo. Você pediu a funcionalidade B. Agora o cadastro está estranho. A pergunta óbvia é "a mudança B quebrou o cadastro?". E você não consegue responder, porque não olhou o cadastro ontem. Talvez já estivesse assim há uma semana.

Sem essa resposta, você faz a única coisa que sobra: manda a IA "consertar o cadastro". Ela mexe. Mexe em coisas que você não pediu. E o ciclo recomeça, agora com dois problemas em vez de um — o original e o que a correção introduziu.

Um relato de usuário do Replit em 2026 batizou isso de "cascade problem", problema em cascata, e resumiu bem a assimetria: esses agentes são fortes em gerar código novo e bem mais fracos em depurar o próprio estrago colateral. É observação de quem usa, não medição — mas bate com tudo que eu vejo.

Tem um agravante específico pra quem não programa. Um programador, quando desconfia, abre a lista das linhas alteradas — o que a gente chama de diff, a comparação entre o antes e o depois do código — e faz uma pergunta de calibragem: "uma mudança dessas deveria ter tocado sete arquivos?". Ele não precisa entender cada linha. Ele reconhece o tamanho errado.

Você não tem esse instinto, e não vai ter em três meses. Então a sua defesa não pode ser técnica. Tem que ser comportamental. É o que vem agora.

1. Marque o ponto que funciona — e saiba o que a marca NÃO salva

Antes de pedir qualquer coisa, marque o estado atual. Toda plataforma séria tem isso, com nomes diferentes: versão, ponto de restauração, checkpoint, favorito.

A documentação da Lovable é explícita sobre pra que serve: "marque uma versão boa conhecida antes de começar uma mudança grande, como um redesenho ou uma reformulação do modelo de dados". É literalmente o conselho da fabricante, e quase ninguém segue.

Agora a parte que separa quem vai se dar mal de quem não vai. Voltar o código não volta os dados.

A Lovable escreve isso com todas as letras na documentação de histórico de versões: restaurar não desfaz alterações nos dados do banco — se as mensagens depois daquela versão adicionaram registros, mudaram informação ou rodaram migração, reverter o código não desfaz nada disso.

O Replit é ainda mais direto: "por padrão, restaurações não alteram o seu banco de dados". Pra incluir o banco, você precisa marcar a opção "Database" nas opções adicionais — ou seja, é uma caixinha que você tem que lembrar de marcar, e ninguém te avisa que ela existe.

Traduzindo pro que isso significa no seu app: você volta o código pra ontem e os cadastros dos clientes continuam no estado de hoje. Às vezes tudo bem. Às vezes o código de ontem não sabe lidar com a tabela que a IA alterou hoje, e aí o app quebra de um jeito novo, que não existia nem antes nem depois.

Antes de contar com restauração, abra a documentação da SUA plataforma e descubra exatamente o que ela restaura. Cinco minutos. É a leitura de maior retorno da sua semana.

2. Tire a foto do antes

Esta é a etapa que quase não existe na vida de ninguém, e é o post inteiro.

Você já deveria ter uma lista curta de caminhos que não podem quebrar nunca — cadastro, login, criar o item principal, o cliente B não ver o dado do cliente A, pagamento liberar acesso. Se você ainda não montou a sua, ela está aqui, com os oito itens, e não vou repetir.

O que eu quero acrescentar hoje é quando rodar essa lista. E a resposta é a que ninguém dá:

Rode ANTES de pedir a mudança. E anote o resultado com a data.

Fica assim, num arquivo de texto que você guarda:

FOTO DO ANTES — 08/09, 14h20
antes de pedir: "adicionar filtro por data na lista de pedidos"

[ok]   cadastro de conta nova
[ok]   login
[ok]   criar pedido
[ok]   editar pedido
[FALHA] recuperação de senha — e-mail não chega
[ok]   conta B não vê pedido da conta A
[ok]   pagamento libera acesso

Olhe o que essa folha faz por você.

Primeiro: quando o app pifar depois, você sabe quem quebrou. Se a recuperação de senha continuar falhando, ela não é culpa da mudança de hoje — já estava assim, e você para de mandar a IA "consertar" uma coisa que ela não causou. Isso sozinho já economiza uma sessão inteira de crédito queimado.

Segundo, e mais importante: transforma "o app tá estranho" em uma linha específica que mudou de estado. É a diferença entre um pedido que a IA consegue atender e um que ela vai chutar.

Terceiro: você para de testar no escuro. Depois da mudança não precisa conferir o app inteiro — só os sete itens que estavam de pé.

Se você anotar isso e não fizer mais nada deste post, já valeu.

3. Cerque a mudança antes de autorizar

Uma frase, colada no fim do pedido, antes de qualquer construção:

"Antes de mexer em qualquer coisa: me diga o que você vai alterar, em quais arquivos, e liste o que você não vai tocar. Se precisar mexer em algo fora dessa lista, pare e me pergunte."

Você não precisa entender os nomes dos arquivos. Precisa da contagem. Pediu um filtro numa tela e a resposta menciona onze arquivos, o login e o banco de dados? Isso não é resposta detalhada. É aviso.

E repare no que essa frase faz de diferente de "faça com cuidado": ela cria uma fronteira declarada. Quando a IA sai dela, você tem como saber — porque a fronteira estava escrita antes, não foi inventada depois pra justificar o estrago.

Uma coisa por vez, sempre. Três funcionalidades no mesmo pedido produzem três problemas simultâneos, e aí não existe foto do antes que salve: você não consegue dizer qual mudança causou qual quebra.

4. Compare — e não conserte a regressão

Mudança feita, pegue a foto do antes e refaça só o que estava [ok]. Cinco minutos.

Achou uma quebra? Agora vem a inversão que mais importa deste post, e é onde quase todo mundo perde dinheiro:

Não peça pra consertar. Volte pro ponto marcado.

O instinto é dizer "quebrou o login, conserta". Esse instinto é caro por dois motivos. O primeiro é o óbvio: cada tentativa custa. O segundo é o que ninguém vê — consertar em cima do estrago soma uma mudança nova em cima de uma mudança que já saiu do controle. Você está construindo em terreno que já cedeu.

Voltar pro ponto marcado te devolve um app inteiro, comprovadamente funcionando, ao preço de perder o trabalho da última meia hora. Meia hora. E aí você pede de novo, menor, com a fronteira mais apertada.

A cabeça de quem não programa resiste a isso, porque parece desperdício jogar fora o que já foi feito. Não é. O que você joga fora é meia hora; o que você preserva é o app.

E se a mesma mudança quebrar a mesma coisa duas vezes seguidas, o problema não é a mudança — é o pedido. Reescreva do zero, sessão nova, pela regra das duas tentativas.

O resumo, em quatro linhas

  • Marque o ponto bom antes de pedir — e leia na documentação o que a restauração inclui, porque código voltar não é o banco voltar.
  • Fotografe o antes: rode a sua lista e anote com data, antes da mudança.
  • Cerque: peça a lista do que vai ser tocado e o que não vai. Estranhe o tamanho.
  • Compare, e volte em vez de consertar.

Nada disso é programar. É a mesma coisa que o dono de uma oficina faz quando pinta a silhueta de cada ferramenta na parede: ele não vira ferramenteiro, ele só passa a enxergar o que sumiu no segundo em que sumiu.

Regressão vai continuar acontecendo. O que muda é que ela deixa de ser um mistério que te paralisa e vira um evento chato de quinze minutos. E aí você volta a pedir a próxima funcionalidade sem prender a respiração — que é a coisa toda.

Fontes