Problema “funcionou ontem”: por que apps gerados por IA quebram

O que o problema “funcionou ontem” realmente significa

O problema “funcionou ontem” parece injusto porque dá a impressão de que nada mudou. Mesmo app. Mesmo usuário. Mesmo botão. E então, de repente, aparece uma tela em branco, uma mensagem de erro ou um login que gira pra sempre.

Na maior parte das vezes, “ontem” não significa que o app quebrou aleatoriamente. Significa que algo mudou silenciosamente em segundo plano, e seu app dependia disso sem você perceber. Em apps gerados por IA, essas dependências ocultas tendem a ser maiores porque o código é produzido rápido, configurações acabam espalhadas e o app pode apoiar-se em defaults temporários que nunca foram pensados para usuários reais.

Algumas mudanças invisíveis causam isso com mais frequência do que se espera:

• Uma sessão ou permissão expirou, então o app não tem mais acesso ao que precisa.
• Uma chave, senha ou variável de ambiente foi rotacionada, renomeada ou removida.
• Um provedor mudou um limite, regra de segurança ou configuração e seu app agora falha numa verificação.
• O código foi regenerado ou recopiado, e uma correção que funcionava foi sobrescrita.

Por isso isso aparece tanto em protótipos e lançamentos iniciais. Um protótipo geralmente é construído para provar um fluxo, não para sobreviver a condições do mundo real como timeouts, novos usuários, limites de taxa ou um redeploy acidental. Ferramentas de IA geram uma demo funcional rápido, mas frequentemente pulam os guarda-corpos que tornam as falhas previsíveis e fáceis de diagnosticar.

Um exemplo simples: você demonstra um fluxo de cadastro na segunda-feira usando seu próprio navegador. Na terça, um usuário novo tenta e é bloqueado. Nada mudou na UI, mas o app dependia de um token temporário armazenado no seu navegador ou de uma configuração de backend que só funcionava para sua conta.

A boa notícia é que essas falhas são geralmente práticas, não misteriosas. Se você tratar “funcionou ontem” como uma pista de que algo mudou nos bastidores, vira uma investigação com fim claro — não um jogo de adivinhação.

Por que apps gerados por IA enfrentam isso com mais frequência

O padrão “funcionou ontem” pode acontecer em qualquer software, mas é extra comum em apps gerados por IA porque o objetivo costuma ser uma demo rápida, não estabilidade de longo prazo. Na superfície o app parece completo, enquanto o trabalho de confiabilidade por baixo está ausente.

Por que a velocidade cria fragilidade

Ferramentas de IA são ótimas em produzir algo que roda uma vez: uma tela de login, uma tabela no banco, uma chamada de API, um dashboard. Apps de produção precisam de guardrails ao redor dessas partes. Sem eles, mudanças normais podem quebrar fluxos principais.

Padrões comuns incluem tratamento frouxo de configuração e segredos, autenticação que só funciona no caminho feliz, testes ausentes, muitas integrações adicionadas rápido demais e uma estrutura bagunçada onde uma mudança afeta inesperadamente várias telas.

Pequenas mudanças têm efeito em cascata

Em uma base de código limpa, uma alteração de chave normalmente quebra um único ponto e o erro aponta para ele. Em uma base gerada às pressas, o mesmo valor pode estar duplicado em vários arquivos, ou uma função auxiliar pode existir em versões ligeiramente diferentes. Depurar começa a parecer aleatório.

Exemplo: um fundador atualiza uma chave de API para trocar de conta de teste para conta real. O app ainda compila, mas um endpoint usa a chave antiga de um arquivo de configuração esquecido. A autenticação falha e usuários ficam presos num loop de login.

Esse é o tipo de situação para o qual o FixMyMess foi feito: pegar protótipos gerados por IA e adicionar guardrails básicos (ambientes claros, tratamento seguro de segredos e uma estrutura mais sustentável) para que a demo de ontem não vire a pane de hoje.

Sessões e tokens expirados (autenticação que expira)

Muitas falhas "funcionou ontem" são só passes de login que expiraram.

Em linguagem simples, uma sessão ou token é um passe temporário que prova que você já se autenticou. Apps usam isso para que você não precise digitar a senha a cada clique. O problema é que esses passes são pensados para expirar, às vezes em minutos ou horas.

Prototipos gerados por IA frequentemente deixam de lado as partes pouco glamorosas da auth: renovar o passe, lidar com timeouts e evitar que usuários fiquem presos. Então tudo parece bem logo após o sign-in, e depois quebra.

Gatilhos típicos incluem tokens que expiram sem fluxo de refresh, refresh implementado mas não ligado à UI, relógios do servidor e do cliente discordando, ou tokens armazenados no lugar errado (então o app “esquece” você ao atualizar a página).

Sintomas que você pode notar sem ler o código: usuários sendo deslogados aleatoriamente, a mesma ação funcionando logo após o login mas falhando depois, ou o app começando a mostrar erros “Unauthorized”. Nos logs, pode aparecer 401 ou 403, que geralmente significa “você não tem permissão” ou “seu passe não é mais válido”.

Perguntas rápidas que reduzem o escopo:

• Falha apenas depois de algum tempo?
• Atualizar a página piora a situação?
• Fazer logout e login conserta temporariamente?

Exemplo: um usuário demonstra um checkout na demo e funciona. Duas horas depois, usuários reais apertam “Salvar” e voltam para a tela de login. Esse padrão sugere fortemente expiração de token.

Times como o FixMyMess costumam consertar isso tornando o refresh de token confiável, tratando timeouts com elegância e verificando o comportamento com tempos reais de espera, não apenas um teste rápido do caminho feliz.

Chaves de API, variáveis de ambiente e configurações de provedores alteradas

Outra causa comum não é um bug no seu código. É uma conexão quebrada com algo de que o app depende, como e-mail, pagamentos, mapas, armazenamento ou login.

Apps conversam com esses serviços usando segredos: chaves de API, client IDs, webhooks e URLs de callback. Esses valores podem viver em variáveis de ambiente no host, no painel do provedor (Stripe, SendGrid, Google, etc.), em um arquivo de configuração no repo ou num secret manager. Quando qualquer um deles muda, tudo pode parecer certo localmente, mas falhar em produção.

O que pode mudar de uma noite para outra? Provedores rotacionam chaves, revogam chaves após atividade suspeita ou desabilitam uma chave exposta num repo público. Trials acabam. Limites de uso são atingidos. Alguém edita configurações no dashboard e esquece. Até pequenas trocas como mudar uma URL de redirect ou alternar um modo podem bloquear usuários reais.

Os sintomas são confusos porque o app ainda carrega, mas funcionalidades específicas param de funcionar: pagamentos falham, mapas não renderizam, e-mails não são enviados, uploads retornam 403 ou login volta para a página de sign-in.

Checagens rápidas que normalmente economizam tempo:

• Confirme se você está no ambiente correto (prod vs dev) e se as chaves certas estão setadas lá.
• Procure por mudanças recentes no provedor: chaves revogadas, trials expirados, cotas excedidas.
• Verifique logs de deploy por variáveis ausentes, erros de permissão ou mensagens como “invalid API key”.
• Verifique se os webhooks e URLs de redirect/callback correspondem ao domínio atual.
• Certifique-se de que ninguém hard-codificou uma chave em um arquivo que é sobrescrito no deploy.

Se você herdou um app gerado por IA, é comum encontrar placeholders, chaves duplicadas entre ambientes ou segredos hard-codados no lugar errado. O FixMyMess geralmente começa com uma auditoria rápida para localizar todo segredo e confirmar qual configuração do provedor está quebrando a produção.

Dependências e atualizações de plataforma que quebram o build

Às vezes nada no seu repo mudou, e o app ainda quebra. Isso acontece porque o código não é a única parte que se move. Seu app depende de pacotes, runtimes, configurações de hospedagem e serviços de terceiros que podem mudar sem você notar.

Projetos gerados por IA são especialmente vulneráveis porque frequentemente não travam versões adequadamente (ou nem têm). Você pode ver um package.json sem um lockfile, ranges vagos como ^1.2.0, ou instruções que puxam o “latest” sempre. A próxima instalação ou deploy busca uma dependência ligeiramente mais nova que se comporta diferente, e agora uma feature que funcionava falha.

Plataformas também mudam. Um host pode atualizar a versão padrão do Node, um banco gerenciado pode atualizar seu engine, um provedor serverless pode apertar limites de requisição, ou uma atualização do navegador pode expor um caso limite de CSS/JS. Não parece “uma mudança sua”, mas ainda é uma mudança que o app precisa suportar.

Sinais que apontam para dependências ou atualizações de plataforma:

• Novos warnings ou erros de build que não existiam antes
• Deploys falhando de repente no provedor de hospedagem
• Uma feature funciona localmente mas falha em produção após uma instalação limpa
• A UI parece levemente diferente sem edições de design
• Erros mencionam o nome de um pacote, versão do Node/Python ou um driver de banco

Cenário: sua demo funcionou na sexta. Na segunda, um deploy fresco puxa uma versão nova de uma biblioteca de datas e um formulário de checkout começa a rejeitar datas válidas. Ninguém mexeu no código, mas o comportamento mudou.

Para reduzir quebras recorrentes, foque em builds reproduzíveis: commite lockfiles, evite ranges vagos de versão, fixe versões de runtime (Node, Python) nas configurações do projeto e leia os logs de deploy antes de confiar no que a UI mostra.

Se você herdou uma base gerada por IA com builds instáveis, o FixMyMess pode auditar e identificar qual dependência ou mudança de plataforma está realmente causando a quebra antes que você perca horas adivinhando.

Regeneração de código sobrescrevendo suas correções

Uma causa sorrateira é a regeneração de código. Muitos apps gerados por IA não são tratados como bases de código normais. São vistos como saída que pode ser refeita a qualquer momento. Isso é conveniente até que silenciosamente apague as mudanças que fizeram o app funcionar.

A regeneração pode acontecer quando alguém re-pede o prompt à ferramenta, clica num botão de auto-fix, re-sincroniza um projeto ou solicita um rebuild limpo depois de um pequeno erro. Algumas ferramentas também reescrevem arquivos quando você altera uma configuração de alto nível ou adiciona uma feature.

Correções desaparecem porque a mudança foi feita em um lugar que o gerador “possui”. Por exemplo, você corrige um bug direto num arquivo de componente, então na próxima execução esse arquivo é substituído por um template. Sem uma regra clara de “este arquivo é seguro para editar”, você não passa a realmente possuir o código que tocou.

Sintomas geralmente parecem com:

• O mesmo bug retorna logo após uma pequena mudança
• Um arquivo que você editou está mais novo, mas suas linhas sumiram
• As falhas parecem viagem no tempo: “por que voltou?”
• Histórico Git (se houver) mostra grandes reescritas em vez de pequenos commits

Exemplo: você conserta um redirect de login alterando duas linhas. No dia seguinte pede ao AI para adicionar uma página de configurações. Ele regenera o arquivo de rotas e sua correção some.

Para evitar isso, proteja as correções: marque arquivos-chave como de propriedade humana, documente o que mudou e por quê, mantenha lógica crítica em um único lugar quando possível e use controle de versão para comparar e restaurar.

Times como o FixMyMess veem esse padrão em projetos criados com Lovable, Bolt, v0, Cursor ou Replit. Um bom primeiro passo é identificar quais arquivos estão sendo sobrescritos e mover a lógica crítica para fora da zona de risco.

Passo a passo: como estreitar o que mudou

Quando você encontra “funcionou ontem”, não chute. Encontre a menor mudança que explica a quebra.

Comece com uma timeline curta desde a última vez que funcionou. Inclua qualquer coisa que pareça pequena: um deploy, um ajuste no dashboard do provedor de autenticação, alguém limpando variáveis de ambiente ou uma ferramenta de IA regenerando parte do app.

Em seguida, confirme onde você está testando. Muitos apps feitos por IA se comportam diferente em dev, staging e produção porque usam chaves diferentes, bancos diferentes ou URLs de callback diferentes. Não compare “local funcionou” com “produção quebrou” sem checar.

Um fluxo simples:

• Trave seu teste: mesma conta, mesmo dispositivo/navegador, mesmos passos cada vez.
• Capture o primeiro erro que aparece. Anote o horário e onde ocorre (mensagem na tela, logs do servidor, console do navegador).
• Escolha uma área suspeita: auth/sessão, chaves de API e vars de ambiente, banco de dados ou uma mudança recente de deploy/build.
• Tente uma única mudança controlada: reverta ou faça rollback de uma mudança recente (ou teste o deploy anterior) e reteste.
• Anote o que aconteceu após cada teste para não ficar girando nas mesmas suposições.

Exemplo: usuários de repente não conseguem logar. Se começou logo após um deploy, desconfie de callbacks de auth ou variáveis de ambiente. Se começou depois de “esperar durante a noite”, suspeite de tokens expirados ou configurações de sessão. Se foi logo após regenerar código, suspeite de uma correção sobrescrita.

Se você herdou um protótipo gerado por IA e a pane parece aleatória, o FixMyMess costuma começar com um diagnóstico rápido que coloca a falha em um desses buckets e depois verifica a correção com testes reproduzíveis.

Armadilhas comuns que fazem perder horas

A forma mais rápida de perder um dia é perseguir o que você vê (um botão quebrado, uma página em branco) em vez do que mudou nos bastidores. Apps gerados por IA frequentemente falham onde a UI não explica: sessões expiram, um valor de config falta ou o app está falando com o serviço errado.

Uma armadilha comum é debugar no ambiente errado. Você conserta localmente e tudo parece OK, mas a produção continua quebrada porque o app deployado tem variáveis de ambiente, segredos ou banco diferentes. Se o problema só acontece para usuários reais, assuma que o bug vive em produção até provar o contrário.

Outra perda de tempo é compartilhar apenas screenshots. Uma captura esconde o texto exato do erro, o timestamp e a requisição que o disparou. Copie a mensagem de erro, anote quando ocorreu e salve a linha completa do log se puder. Uma linha muitas vezes aponta direto para um token expirado, uma chave de API ausente ou uma mudança de permissão.

Erros que mais causam retrabalho:

• Consertar a página visível enquanto a causa real é auth, permissões ou config
• Editar settings de dev quando a quebra só existe em staging ou produção
• Colar erros parciais (ou screenshots) em vez da mensagem completa e do horário
• Mudar várias configurações ao mesmo tempo e não saber qual importou
• Clicar em regenerar para resetar e então sobrescrever a correção de ontem

Exemplo: você atualiza um prompt para limpar o fluxo de login, regenera o código e o app compila novamente. Mas a regeneração substituiu sua lógica de refresh de sessão, então usuários começam a ser deslogados após alguns minutos.

Se esse padrão se repete, um changelog simples e uma auditoria rápida de auth, segredos e deploys podem salvar você. Times trazem esses casos ao FixMyMess quando precisam que alguém rastreie a mudança real e garanta que a correção sobreviva à próxima regeneração.

Checklist rápido antes de entrar em pânico

O objetivo não é adivinhar a causa. É saber se a quebra está ligada a um usuário, uma sessão do navegador, um deploy ou um serviço de terceiros.

Faça estes testes rápidos primeiro:

• Tente a mesma ação em uma janela privada/incógnita. Se funcionar lá, provavelmente é sessão expirada, cookie travado ou front-end em cache.
• Pergunte se alguma chave de API, senha ou segredo mudou nas últimas 24–72 horas (pagamentos, e-mail, apps OAuth, senhas de banco).
• Lembre-se: você redeployou, mudou configurações de hospedagem ou atualizou um pacote? Pequenas mudanças de config podem quebrar produção.
• Verifique logs no exato momento em que quebrou. Procure por timestamps e mensagens como “invalid token”, “unauthorized”, “missing env” ou “cannot connect”.
• Confirme quem é afetado. Todos, ou apenas certas contas/roles/novos cadastros? Isso aponta para permissões, checagens de role ou diferenças de dados.

Exemplo: o fundador ainda consegue logar, mas novos usuários não. Isso frequentemente significa que o fluxo de cadastro está falhando (chave do provedor de e-mail mudou, limites atingidos ou bug de atribuição de role), não que o app inteiro quebrou.

Se você responder essas cinco checagens em 10 minutos, costuma economizar horas de adivinhação. Se herdou código gerado por IA e os sinais estão confusos, o FixMyMess pode rodar uma auditoria de código gratuita e dizer o que mudou e o que consertar primeiro.

Um cenário simples: a demo funcionou e depois usuários foram bloqueados

Um fundador demonstra um app novo, construído por IA, para um investidor na terça. O login funciona, o dashboard carrega e o teste de pagamento passa. Na quarta de manhã, usuários reais começam a se cadastrar e todas as tentativas de login falham. O fundador não mudou código, então parece aleatório.

Uma causa provável é o tratamento de tokens e sessões. Muitos protótipos usam tokens de vida curta ou um setup de auth apenas para desenvolvimento que parece ok num demo rápido. Durante a noite, a vida do token acaba, o fluxo de refresh está ausente ou o app não consegue renovar a sessão. Usuários são mandados de volta ao login ou veem um erro genérico “unauthorized”.

Outra causa comum é uma chave de API rotacionada. Uma chave de pagamento, e-mail ou auth pode ter sido trocada, desabilitada ou substituída. O app continua usando a chave antiga guardada numa variável de ambiente, então requisições começam a falhar.

Uma forma rápida de estreitar:

• Reteste o login em uma janela incógnita para excluir sessões em cache.
• Veja nos logs se aparece “token expired” vs “invalid API key”.
• Verifique os valores atuais das chaves no ambiente de deploy.
• Confirme configurações do provedor (domínios permitidos, callback URLs, limites de taxa).
• Depois de consertar, rode o mesmo fluxo duas vezes: agora e novamente amanhã.

Para evitar a surpresa na semana seguinte, trave onde os segredos vivem (nada de hardcoding), adicione monitoramento básico para falhas de auth e de chaves, e evite regenerar código sobre correções em produção. Se a base for gerada por IA e difícil de desembaraçar, uma auditoria focalizada do FixMyMess pode apontar se o problema é token, segredos ou uma sobrescrita por regeneração.

Próximos passos para fazer isso parar de acontecer

Para reduzir o padrão “funcionou ontem”, trate seu app feito por IA como um produto real, não uma demo única. A maior parte das quebras misteriosas são pequenas mudanças sem registro, sem checagens e sem alarmes.

Estabilize o que mais muda

Comece congelando as partes móveis. Se seu app depende de bibliotecas, defaults de hospedagem ou configurações de provedores, pequenas atualizações podem mudar o comportamento silenciosamente.

• Trave versões de dependências para que instalações sejam reproduzíveis.
• Centralize variáveis de ambiente e segredos (quem pode alterá-los e onde eles ficam).
• Adicione monitoramento básico: uma checagem de uptime e alertas para erros de login e chamadas de API falhas.
• Mantenha os releases tediosos: um método de deploy, um lugar para ver logs.
• Faça a regeneração opcional: não deixe uma ferramenta reescrever arquivos sem revisão.

Se uma configuração pode quebrar pagamentos, login ou dados críticos, não deveria ser editável ao acaso.

Torne mudanças visíveis e teste os caminhos de risco

Mantenha um change log leve: mudanças de prompt, rotações de chave, horários de deploy e atualizações de provedores. Quando algo quebra, você consegue comparar “último que funcionou” com “primeiro que quebrou” em minutos.

Adicione alguns testes guardrail para fluxos que costumam falhar: login, cadastro, reset de senha e tudo que dependa de uma chave de API. Mesmo checagens simples antes do deploy pegam variáveis ausentes, redirects quebrados e falhas óbvias de auth.

Se as quebras persistem, ou você vê problemas de segurança como segredos expostos e risco de SQL injection, vale chamar alguém para desembaraçar e endurecer a base. FixMyMess (fixmymess.ai) oferece uma auditoria de código gratuita para identificar as causas reais, então repara e prepara apps gerados por IA para produção com verificação humana para que as correções não desapareçam no próximo deploy.