"O dia em que a IA me disse \"corrigido\" 4 vezes e o bug era um acento"
"Quatro consertos, um nome que continuava torto. O que resolveu foi abrir o banco e ler o que tinha entrado, e o teste de 10 minutos pra fazer hoje."
"Lovable says that it has fixed it but it doesn't."
"O Lovable diz que consertou, mas não consertou." É de um usuário na comunidade do Lovable, em 2025, e está na pesquisa deste blog. Relato, não estatística. Eu tenho o meu, e programo há 15 anos.
O nome da cliente
Eu estava montando com IA um sistema pequeno de cadastro, desses de fim de semana. Importei uma lista de clientes de uma planilha, salva como CSV (o arquivo de texto que a planilha exporta, uma linha por cliente, colunas separadas por vírgula). Na tela, "Conceição" apareceu como "Conceição".
Pedi pra consertar. Foram quatro rodadas:
1. "Corrigido: adicionei a declaração de UTF-8 na página." Tela igual.
2. "Corrigido: troquei a fonte, que não tinha os caracteres especiais." Tela igual.
3. "Corrigido: criei uma função que converte os caracteres antes de exibir." E a tela ficou certa. Ela me mandou o print, eu conferi com os meus olhos, aceitei.
4. Dois dias depois, o e-mail de confirmação saiu com o nome torto. E a busca por "Conceição" não achava a cliente. Pedi de novo. "Corrigido: apliquei a mesma conversão no e-mail." A busca continuou sem achar.
Aí eu fiz o que devia ter feito na primeira rodada: abri a tabela de clientes no banco de dados e li a linha. Estava gravado lá dentro: "Conceição".
O bug nunca esteve na tela
Toda letra, pro computador, é uma sequência de números. A tabela que diz qual sequência vira qual letra se chama codificação (em inglês, encoding). O padrão da internet hoje é o UTF-8, e o W3C, o consórcio que define os padrões da web, recomenda escolher sempre ele. A mesma página explica o que acontece quando um lado usa uma tabela e o outro lê com outra: "sem a chave, o dado parece lixo".
Foi isso. A planilha estava em UTF-8, e a rotina de importação que a IA escreveu lia o arquivo com outra tabela. O "ç" virou "ç" na entrada, e foi gravado assim. Daí pra frente, cada tela, e-mail e busca só mostrava fielmente o que estava errado no banco.
Repare no que as quatro rodadas fizeram. A primeira e a segunda mexeram na saída, sem efeito. A terceira e a quarta maquiaram a saída: desentortavam o nome na hora de mostrar. A tela ficou certa e o dado continuou quebrado, agora escondido. Parado ali, eu ia descobrir o resto uma saída por vez, com cliente vendo antes de mim.
O conserto de verdade foi um só: a importação passou a ler o arquivo como UTF-8, e os registros que já tinham entrado foram reparados uma vez, com backup antes e contagem de linhas antes e depois.
Não foi burrice, nem minha nem sua
O print da rodada 3 era evidência de verdade. Era sobre o que eu pedi, ficaria diferente se estivesse quebrado, e fui eu que vi. Passava nas três perguntas da evidência. O problema é que era evidência da camada errada: provava a tela, e o defeito morava no dado.
A IA conserta onde você aponta. Eu apontei pra tela, porque era onde eu via o sintoma. Ela não tinha motivo nenhum pra ir olhar o banco, e eu não pedi. Peça prova, não promessa, sim. Mas, quando o problema é de dado, a prova que vale é a linha no banco.
O teste do nome difícil, em 10 minutos
1. Escolha um nome de teste com tudo que costuma quebrar: Ação Conceição Müller 🎉. Til, cedilha, trema e um emoji.
2. Faça ele entrar por todas as portas do seu app: o formulário de cadastro, a importação de planilha (se existir), o celular. Cada porta lê de um jeito.
3. Abra o banco e leia a linha. No Lovable Cloud (o banco do próprio Lovable), fica em More → Cloud → Database, clicando na tabela. Num Supabase próprio (outro serviço de banco), no editor de tabelas do painel. Não confie na tela do app pra isso: a tela pode estar maquiando, como a minha estava.
4. Leia o resultado assim:
| No banco | Na tela, no e-mail | Onde está o problema |
|---|---|---|
| torto | torto | na entrada |
| torto | certo | na entrada, e alguém já maquiou a saída |
| certo | torto | na saída que está torta, uma por uma |
| certo | certo | passou |
A segunda linha é a mais perigosa, porque parece a última.
5. Se entrou torto, peça assim:
O nome "Ação Conceição Müller" está gravado no banco como [cole o que você viu].
Não mexa em como o nome é exibido.
Corrija a [importação / o formulário] pra ler e gravar em UTF-8.
Depois cadastre o nome de novo e me mostre a linha nova, como ela está no banco.
Não altere os registros antigos agora.
Os registros antigos ficam pra um segundo pedido, separado, com backup feito antes e a contagem de linhas conferida depois.
E se a planilha vem do Excel, salve no formato que diz o padrão no nome: Arquivo → Salvar como → CSV UTF-8 (Delimitado por vírgulas). A opção existe no Excel do computador; segundo a Microsoft, a versão do navegador não salva CSV.
O teste das seis entradas maldosas já pedia pra cadastrar um nome com acento e olhar a tela, o e-mail e o PDF. Este acrescenta o lugar que decide: o banco.
Era uma parede de várias
Ler o dado é uma habilidade. Saber em que camada cada tipo de defeito mora (a tela, a regra, o banco, o serviço de fora) é outra, e sem ela você aponta pra onde vê o sintoma, como eu apontei. São quatro camadas que se puxam, e a pergunta "onde eu confiro isso?" tem uma resposta diferente pra cada uma. Aprender essa ordem uma vez, no seu próprio app, é o que faz o quinto "corrigido" deixar de acontecer.
Fontes
- W3C Internationalization, "Character encodings for beginners" ("sem a chave, o dado parece lixo"; recomendação de sempre escolher UTF-8): https://www.w3.org/International/questions/qa-what-is-encoding
- Microsoft Support, "Save a workbook as a CSV file" (opção CSV UTF-8 (Comma delimited); Excel para a web não salva CSV): https://support.microsoft.com/en-us/office/save-a-worksheet-as-a-csv-file-8303b161-b926-4c01-acc5-c038a2a8958c
- Lovable Docs, "Database" (More → Cloud → Database, tabelas e registros): https://docs.lovable.dev/features/database