Uma falha é o melhor bug que você pode ter. Ela acontece na sua frente, para o app, e você a corrige naquela mesma tarde. Todo mundo que constrói com geradores de IA tem uma história sobre um deploy quebrado ou uma tela em branco, e quase sempre é uma história com final feliz: encontrei, corrigi, publiquei.
A corrupção de dados não funciona assim. Ela não trava. Ela não gera um erro. Ela grava um número errado em uma coluna do banco de dados e segue adiante, e o app continua funcionando exatamente como antes. O bug que você realmente deveria temer é aquele que nunca avisa que aconteceu.
Por que falhas são o resultado de sorte
Quando algo quebra visivelmente, você tem um retorno imediato e uma lista curta de suspeitos: o último prompt, o último deploy, a última mudança de código. Lovable, Bolt e geradores parecidos falham assim constantemente, e é irritante, mas gerenciável, porque a falha faz barulho.
A corrupção silenciosa inverte todo o problema. O bug e a descoberta do bug podem estar separados por meses, e nesse intervalo os dados corrompidos continuam se acumulando: são copiados para relatórios, somados em totais, usados para calcular uma fatura. Quando alguém percebe que os números estão errados, você não está mais depurando um único erro. Você está tentando descobrir quais, entre milhares de registros criados desde que o bug foi publicado, são confiáveis e quais não são, sem nenhum log que sinalize a diferença.
Os casos extremos que ninguém descreve em um prompt
Os modelos de IA constroem para o cenário que você descreveu. Um prompt como “deixe os usuários atualizarem a quantidade do pedido” gera um botão de atualização funcional, testado para exatamente uma coisa: um único usuário, em uma conexão estável, clicando uma vez. O uso real não fica dentro dessa caixa, e as brechas aparecem em um punhado de padrões que se repetem:
- Edições simultâneas. Duas pessoas abrem o mesmo registro e salvam alterações com segundos de diferença. Sem uma estratégia de bloqueio ou resolução de conflitos, quem salva por último sobrescreve silenciosamente as alterações da outra pessoa, sem nenhum aviso para nenhuma das duas.
- Uma queda de rede no meio de um formulário. Um envio é feito, a conexão falha, e o cliente não consegue confirmar se o servidor o recebeu. O usuário vê um indicador de carregamento, supõe que falhou, e reenvia. Sem deduplicação, agora existem dois registros onde deveria haver um.
- O botão de envio clicado duas vezes. A versão mais banal do mesmo problema. Uma resposta lenta somada a um clique impaciente e você criou um pagamento duplicado, uma reserva duplicada ou uma linha duplicada que infla todas as contagens seguintes.
- Entradas inesperadas. Um campo de quantidade que aceita um número negativo, um campo de data que aceita um valor no passado, um campo de desconto que aceita mais de 100%. Nada disso faz o app travar. Isso apenas produz um registro matematicamente absurdo no momento em que alguém o compara com a realidade.
Nenhum desses é um modo de falha exótico. São o atrito comum de pessoas reais usando um app em redes reais, e um único prompt quase nunca pede que a IA se proteja contra eles, porque se proteger contra eles não agrega nenhum progresso visível a uma demonstração.
Quando a conta está errada em todas as transações
A segunda variante desse problema é ainda mais silenciosa: um erro de arredondamento ou de cálculo que erra por uma fração de centavo, sempre, em todas as transações. Ele roda sem problemas. Nunca lança uma exceção. O teste unitário, se é que existe algum, verifica se o cálculo retorna um número, não que esse número esteja correto até a última casa decimal em dez mil execuções.
É aqui que o teste “funcionou”, no qual o vibe coding treina você a confiar, se torna realmente perigoso. Um cálculo de preço que erra por 0,3% não falha na demonstração. Ele falha na reunião de reconciliação seis meses depois, quando o financeiro aponta que a soma de todas as transações individuais não corresponde ao valor total de receita, e ninguém consegue explicar o porquê sem revisar registro por registro.
Essa diferença entre “a funcionalidade funciona” e “a funcionalidade está correta” é exatamente o que os testes automatizados deveriam detectar no desenvolvimento profissional de software, e exatamente o que falta quando um criador não técnico é o único a verificar o que a IA produz. Você pode confirmar visualmente que uma página carrega. Você não pode confirmar visualmente que um cálculo cumulativo está correto até o centavo ao longo de um ano de transações.
Por que “parece certo” é o teste errado para a integridade dos dados
| O que você pode testar manualmente | O que realmente causa corrupção |
|---|---|
| O formulário é enviado com sucesso? | Ele é enviado exatamente uma vez, mesmo em uma conexão instável? |
| O painel mostra um total? | Esse total ainda está correto depois de 10.000 linhas, ou um erro de arredondamento se acumula? |
| Um usuário consegue editar um registro? | O que acontece quando dois usuários o editam ao mesmo tempo? |
| A calculadora retorna um número? | Esse número é o número certo, verificado em comparação com uma fonte independente? |
A coluna da esquerda é o que uma demonstração, e a maioria dos testes manuais de qualidade, realmente verifica. A coluna da direita é o que determina se o seu faturamento, suas reservas ou seus relatórios serão confiáveis no sexto mês. O vibe coding se otimiza fortemente para a coluna da esquerda e não tem nenhum mecanismo natural para a da direita, porque a coluna da direita exige tentar deliberadamente quebrar o caminho ideal, não apenas confirmar que ele funciona.
O que torna isso pior que um bug: você não consegue saber quais registros estão errados
Uma falha tem um raio de impacto que você pode ver. Dados corrompidos têm um raio de impacto que você só pode adivinhar. Depois que um bug de envio duplicado ou um erro de arredondamento está em produção por meses, não há nenhuma marca nas linhas afetadas. Você ou confia em todo o conjunto de dados, que agora sabe ser pouco confiável, ou audita registro por registro, o que, além de algumas centenas de linhas, não é realista para uma equipe pequena sem tempo de engenharia dedicado.
Esse é o custo real da “lacuna de confiança” que vem com o código gerado: você nunca esteve em posição de verificar se a lógica era realmente sólida desde o início, então, quando descobre que não era, você não tem nenhum ponto de partida para a limpeza. Descobrir o bug não é o fim do problema. É o começo de um problema muito mais difícil: descobrir até onde o dano vai.
Construindo para que o dano não se acumule
Você não pode eliminar todos os casos extremos sendo mais cuidadoso com os prompts. O que você pode fazer é escolher onde as partes do seu app que lidam com dinheiro, quantidades ou reservas realmente rodam.
Para projetos pessoais, prototipagens internas, ou qualquer coisa em que um número errado seja um inconveniente e não um risco, código gerado e testes manuais são uma troca razoável por velocidade. O cálculo muda no momento em que os números alimentam uma fatura de cliente, um calendário de reservas ou um relatório que alguém assina oficialmente. Nesse ponto, a pergunta não é mais “isso parecia certo quando testei”, e sim “quem está verificando se ainda está certo depois de dez mil transações”.
Para essa categoria de app empresarial, estruture o caminho de gravação para que ele não dependa de a IA acertar a concorrência e o arredondamento na primeira (ou na quinta) tentativa:
- Leve as gravações principais para uma infraestrutura testada, não para código recém-gerado. O Softr trata a criação de registros, atualizações e cálculos de rollup (somas, médias, contagens entre registros vinculados) por meio do seu próprio mecanismo de banco de dados, em vez de lógica gerada por IA específica de cada app. Um rollup que soma itens de linha de uma fatura executa o mesmo cálculo testado sempre, em vez de uma função personalizada que uma IA escreveu uma vez e nunca testou sob estresse para desvios de arredondamento.
- Use permissões visuais em vez de lógica de concorrência escrita à mão. Os User Groups e as Data Restrictions em nível de registro do Softr determinam quem pode editar o quê, o que reduz (embora não elimine) o problema de edições simultâneas ao controlar o acesso no nível da plataforma, em vez de depender de um bloqueio codificado sob medida que uma IA pode ou não ter pensado em adicionar.
- Faça a reconciliação de forma independente, em um cronograma fixo. Nenhuma plataforma, no-code ou não, substitui o hábito de verificar periodicamente os totais em comparação com uma fonte externa: um extrato bancário, o painel de um processador de pagamentos, uma contagem manual. Isso vale tanto se você construiu com código gerado por IA quanto se não, e é a única forma de detectar um erro cumulativo antes que ele tenha um ano de profundidade.
- Se você continuar programando, reserve tempo real para testes adversariais. Se você é desenvolvedor e usa o Cursor ou o Replit para construir ou estender um app personalizado, escreva explicitamente testes para gravações simultâneas, envios duplicados e valores-limite (números negativos, zero, datas extremas), porque a IA não vai gerá-los a menos que você peça, e “compilou” não diz nada sobre se está correto sob carga.
Nada disso faz o problema de fundo desaparecer. Software que envolve dinheiro ou reservas sempre vai precisar de alguém verificando as contas em comparação com a realidade. Mas há uma diferença real entre um app cuja lógica de gravação foi gerada sob medida para cada projeto e nunca testada sob estresse, e outro cujas operações principais de banco de dados seguem o mesmo caminho de código testado no qual todo negócio da plataforma confia. O primeiro te dá uma nova chance de errar a concorrência e o arredondamento em cada funcionalidade. O segundo não remove a sua responsabilidade de reconciliar, mas remove a loteria diária sobre se essa função de gravação específica, gerada por IA, trata corretamente um clique duplo.
A conclusão honesta é que falhas são irritantes, mas tolerantes. A corrupção silenciosa é paciente. Ela espera até que o volume de dados seja alto o suficiente, e o tempo passado seja longo o suficiente, para que corrigi-la custe muito mais do que teria custado preveni-la.