Vibe coding para renomear entidade sem quebrar link no sistema

Trocar o nome de uma entidade dentro do seu sistema parece 1 campo de formulário e são 2 coisas. Tem o nome que as pessoas leem na tela, e tem tudo que foi derivado desse nome quando a entidade nasceu. O endereço da página é o caso mais comum disso. Você pede ao agente "muda o nome", ele muda o campo do nome, porque foi exatamente isso que você pediu, e o endereço segue com o nome velho.

Na live de Jhonatan em 3 de agosto, isso apareceu logo depois que ele renomeou uma escola dentro da plataforma dele. Na tela, o nome novo entrou. Ele olhou o endereço da página e falou o que tinha ficado para trás:

"É importante que ao mudar o nome também muda ali a barra. Então barra [nome da escola] mudar também o endereço."

A barra ali é a da URL. O trecho que vem depois dela, aquele pedaço final do endereço que foi gerado a partir do nome (o que muita gente chama de slug), continuava carregando o nome antigo.

O agente cumpriu o pedido, e o pedido estava incompleto

O agente não errou. Ele recebeu "trocar o nome" e trocou o nome. A relação entre o campo de texto e o endereço da página é uma coisa que existe no momento em que a entidade é criada, quando o sistema pega o nome, transforma em endereço e guarda os dois lados separados. Depois disso, os dois vivem vidas independentes, e nada obriga um a acompanhar o outro.

É por isso que renomear é um dos pedidos mais enganosos que você faz no dia a dia de vibe coding. Ele parece pequeno, o agente resolve em segundos, a tela confirma que deu certo, e o problema fica escondido num lugar que você só vê se olhar para a barra de endereço de propósito.

2 versões do mesmo nome no mesmo sistema

Depois do rename, o sistema passa a ter 2 respostas para a pergunta "como essa entidade se chama". A resposta nova está no título da página. A resposta velha está no endereço, e o endereço é público.

Quem recebe esse link vê o nome antigo antes de abrir a página. Quem copia o endereço para mandar no grupo está distribuindo uma informação que a sua própria plataforma já considera desatualizada. Não quebra nada, funciona, e mesmo assim entrega ao visitante uma versão da verdade que você trocou faz tempo.

Manter o endereço velho e trocar o endereço: as 2 opções cobram

A saída óbvia é fazer o endereço acompanhar o nome. Ela também tem preço. No instante em que o endereço muda, todo link que já foi compartilhado, salvo nos favoritos de alguém ou indexado no Google passa a apontar para um lugar que não existe mais. A pessoa clica e cai em nada, a não ser que o endereço antigo continue levando ao novo.

Então são 2 escolhas e as 2 cobram. Manter o endereço velho gera incoerência permanente entre o que a página diz e o que o link mostra. Trocar gera link quebrado para trás. A que importa é que essa decisão seja tomada antes, por você, e não descoberta semanas depois por um usuário que reclamou que o link parou de funcionar.

A live não mostra o desfecho. Ele apontou o que faltava e a conversa seguiu para a próxima coisa. Ficou registrado o momento em que o problema é visto, que já é a parte que quase ninguém filma.

Essa família de problema aparece sempre que uma coisa guarda dentro dela a referência a onde estava antes. Em contexto limpo no vibe coding, outro builder descobriu que o arquivo de contexto dele citava a pasta onde tinha nascido, e por isso deixou de se bastar assim que foi movido de lugar.

No vibe coding, quem não diz onde a coisa mora deixa o agente escolher

Antes do rename teve um segundo detalhe da mesma cena que vale por si. O pedido inicial foi "Preciso de um botão aqui para trocar o nome da escola". O agente criou o botão e colocou em algum lugar do sistema que ele não conseguiu achar. "Não achei", "Não encontrei", e aí veio o pedido corrigido: "Eu preciso que seja nessa página aqui que seja mais fácil".

Onde uma funcionalidade fica é decisão de produto, e quem constrói costuma ter uma opinião firme sobre ela. Quando o pedido descreve só o que o botão faz, essa opinião não chega ao agente, e ele escolhe um lugar razoável que pode não ser o seu. Custa 1 frase a mais no pedido e evita a ida e volta de procurar o que você mesmo mandou criar.

O que fazer antes de pedir o próximo rename

Quando for pedir uma renomeação ao agente, diga em qual página o controle deve ficar e pergunte, no mesmo pedido, o que mais no sistema foi gerado a partir daquele nome. Se o endereço estiver na lista, escolha ali mesmo entre deixar o endereço antigo como está ou trocar e garantir que quem chegar pelo link velho continue chegando na página. Essa decisão é sua, e o jeito do vibe coding é tomá-la enquanto a tela ainda está aberta, não depois que o link parou de abrir. Tome a decisão também no nível de estrutura: se o cliente é uma escola e pode mudar de nome, ou uma empresa com múltiplos cursos, os nomes devem ser atualizáveis sem quebrar links. O modelo comercial também impacta isso: em revenue share, o endereço precisa valer como referência entre você e o cliente, então mude com cuidado. Foi o mesmo caminho de vibe coding para mostrar o efeito lado a lado sem nomear. Vale ver como isso terminou em sistema de agendamento.

A cena inteira está em assistir à live.