Vibe coding para migrar dados sem perder histórico com cliente real dentro

A forma mais segura de reorganizar a estrutura de um produto que já tem cliente dentro é não mover dado nenhum. O registro fica onde está, com o mesmo identificador, e ganha um campo novo dizendo a que organização ele pertence. Thiago fechou esse desenho antes de rodar qualquer script, com 2 clientes reais já usando o produto e todo o histórico produzido por eles.

A cobrança dele veio antes de autorizar qualquer coisa:

"você tem certeza absoluta, você já checou isso, que nós não vamos perder nenhum dado desses dois clientes que já existem"

Vibe coding em produto que já tem cliente: vincular em vez de mover

O plano descartou levar os dados para a estrutura nova. Nas palavras do agente, o vínculo com a organização "é uma coluna a mais da marca, não uma cópia, nem um merge", e a operação "não tem delete de clientes". O registro do cliente não sai do lugar, ele passa a apontar para a organização. A escrita é aditiva: preenche o campo onde ele está vazio e não apaga nada.

Migração que copia e apaga tem um intervalo em que o dado existe em 2 lugares, ou em nenhum, e é dentro desse intervalo que ele some. O script morre no meio da cópia e o apagamento roda mesmo assim. Vínculo não abre essa janela, porque nada precisa se mover para o resultado ficar certo, e se a escrita falhar o pior caso é um campo vazio, que se preenche de novo.

O preço disso é uma estrutura que carrega a história de como ela cresceu. O produto nasceu com cliente solto, ganhou organização depois, e o banco vai mostrar isso, com a coluna colada no que já existia em vez de um desenho que parece feito de propósito. Em troca, o histórico dos 2 clientes não passa um segundo em trânsito. O mesmo problema aparece em vibe coding para separar formato visual da estrutura do conteudo, onde a arquitetura interna está certa mas a interface não reflete isso. E um problema relacionado, de armazenamentos múltiplos para a mesma coisa, está documentado em vibe coding para agente que diz que salvou mas não salvou no lugar certo. O mesmo problema apareceu em anonimização de dados. Foi o mesmo caminho de proteção de dados empresariais.

As 2 certezas que uma resposta de agente costuma misturar

O agente entrega a garantia e delimita o alcance dela na mesma frase:

"Se seguirmos o plano vincular, não migrar, copiar, apagar, os dois mantém os mesmos IDs e todo o histórico, roteiros, cofre, perfil, etc. Não é certeza mágica que nunca ninguém [...] erra. É certeza do contrato técnico."

E abre uma seção própria para o que fica de fora:

"Onde ainda pode dar errado? Honestidade. Mapa humano errado."

Os riscos que ele listou moram fora do código. A tabela de correspondência entre cliente e organização foi montada à mão, e uma linha trocada ali liga o cliente à organização errada sem que nada quebre. Alguém também pode rodar um apagamento manual depois, e script nenhum impede isso.

São 2 tipos de certeza. "O código não apaga" alguém verifica lendo o código, e a resposta é a mesma para quem quer que leia. "Nada vai dar errado" depende de quem preencheu o mapa à mão e de quem tem acesso ao painel amanhã. Um agente que responde só a primeira e deixa você ouvir a segunda entregou uma garantia que ele não tem. Quem faz vibe coding o dia inteiro ouve "sim" o tempo todo, e o que separa os úteis dos perigosos é a fronteira vir escrita junto.

O mesmo builder, 2 versões do mesmo sim

Ele já tinha cobrado garantia assim antes. Perguntou se a telemetria estava funcionando, ouviu que sim, e o painel estava vazio, porque a resposta tinha saído da leitura do código sem ninguém conferir o banco. Essa cena está contada em exigir evidência antes de confiar na IA. Aqui o sim também veio, só que com a fronteira dele escrita na mesma resposta.

A conversa aconteceu antes de qualquer coisa tocar o banco

O agente foi explícito: o mapeamento real seguia pendente, e nada daquilo tinha acontecido no banco. Cobrar garantia depois só serve para explicar o que já sumiu, e foi essa cobrança feita antes que trocou uma cópia por um vínculo, enquanto mudar o plano ainda custava uma conversa. Essa é a postura que também define vibe coding para usar ia como rascunho de contador e advogado: pedindo garantias antes da execução, não depois. E o cuidado reaparece em vibe coding para restringir modelo e conta de ia para o squad, onde definir restrição de orçamento antes de disparar agentes em paralelo protege a conta de surpresas.

Peça o verbo e a lista antes de liberar a mudança

Antes de deixar um agente encostar na estrutura de um banco em produção, peça 2 coisas escritas, ainda sem código na mesa.

A primeira é o verbo que a operação usa em cada registro: preenche, copia ou apaga. Se aparecer copiar ou apagar, peça a versão que só acrescenta e veja se ela resolve o mesmo problema. Na maioria das reorganizações de estrutura resolve, porque o que você quer é que o registro pertença a outro lugar, não que ele viaje até lá.

A segunda é a resposta para onde isso ainda pode dar errado sem que o código tenha culpa. Ela precisa citar gente: quem preencheu a tabela à mão, quem consegue apagar pelo painel. Um agente que não escreve essa parte está dando um sim sem fronteira, e no vibe coding é sempre você quem descobre onde ela estava, com cliente dentro. O mesmo problema apareceu em vibe coding para separar tela de aprovar e tela de publicar. A conversa inteira está na live em que ele fecha esse desenho.