← todos os posts
Manutenção 5 min de leitura

"Login, cadastro e cálculo têm a ver: o mapa das peças que se puxam dentro do seu app"

"Mexer numa coisa quebra outra porque as peças do app estão ligadas. As quatro camadas, o que cada uma puxa e como montar o mapa do seu app hoje."

"Ela conserta uma coisa e quebra outra. Você não entende o que está acontecendo porque não sabe ler o código. É como dirigir um carro sem saber abrir o capô."

É de um dev brasileiro, no TabNews, em fevereiro de 2026, descrevendo quem constrói com IA sem programar. Você mexe no cadastro e o login para. Ajusta o cálculo e o relatório sai errado. Parece sorteio.

Não é. As peças do seu app estão amarradas umas nas outras, e você só não viu o desenho. Este post é o capô aberto, sem diagrama de programador: quatro camadas, o que cada uma puxa, e como desenhar o mapa do seu app em meia hora.

Por que ninguém te mostrou isso

Porque na tela não aparece. Você vê uma página de cadastro e uma página de pedidos, e elas parecem duas coisas separadas, como duas abas do navegador. Por baixo, as duas leem a mesma ficha do cliente, usam a mesma regra de quem pode ver o quê e dependem do mesmo login.

Quem programa aprende esse desenho no primeiro ano e esquece que um dia não sabia. Por isso o tutorial pula.

As quatro camadas, de cima pra baixo

Se alguma palavra travar, o vocabulário mínimo está aqui.

1. Tela. O que você vê e clica: o formulário, a lista, o botão. Trocar a cor de um botão ou o texto de um título quase nunca quebra nada fora dali.

2. Regra. O que o app decide: quanto dá o total, se o cupom vale, se o horário está livre, quem recebe o e-mail. Uma regra costuma ser usada por várias telas ao mesmo tempo. O cálculo do total aparece no orçamento, no pedido, no PDF que vai pro cliente e no relatório do mês. Mexeu no cálculo, mexeu nos quatro.

3. Banco. Onde o app guarda o que precisa lembrar: as fichas de cliente, de pedido, de agendamento. Cada ficha tem campos, e várias fichas apontam pra outras (o pedido aponta pro cliente). Mudar o nome ou o formato de um campo puxa toda tela e toda regra que lê aquele campo. É aqui que "coloca um campo" vira "quebrou o relatório".

4. Login. Quem é a pessoa e o que ela pode ver. Quase tudo no app pergunta isso antes de mostrar alguma coisa: "esse pedido é desse usuário?". Por isso mexer no login, até numa coisa que parece inocente como "deixa entrar com o Google também", pode puxar a regra de acesso de todas as telas e deixar dado antigo sem dono.

A regra geral cabe numa linha: quanto mais pra baixo a camada, mais coisa ela puxa. Tela puxa pouco. Login e banco puxam quase tudo.

Um exemplo, do jeito que acontece

Você pede: "separa o nome do cliente em nome e sobrenome". Parece coisa de tela. Não é: é um campo do banco mudando de formato.

Esse campo é lido pela tela de cadastro, pela lista de clientes, pela busca, pelo orçamento, pelo PDF e pelo e-mail de confirmação. Seis lugares. Se a IA ajusta quatro e esquece dois, o e-mail sai "Olá, undefined" (o jeito do código dizer "não achei nada aqui") e a busca para de achar gente. O pedido parecia pequeno porque ninguém contou as linhas.

Faça hoje: o mapa do seu app, em três passos

Passo 1. Peça o mapa à IA, sem deixar ela mexer em nada. No Lovable, use o modo de planejar (Plan): pela documentação, nele a IA investiga o projeto e escreve um plano, e o código só muda depois que você aprova. Custa um crédito por mensagem, às vezes um pouco mais. Cole isto:

Não altere nada. Quero entender como meu app está ligado.
Monte uma tabela com uma linha por tela, e estas colunas:
- Tela
- Dados que ela lê (quais fichas/tabelas e campos)
- Dados que ela grava
- Regras que ela usa (cálculos, validações, e-mails)
- Precisa de login? Quem pode ver?
Depois, liste os campos e regras que aparecem em 3 telas ou mais.
Use palavras simples, sem jargão.

Passo 2. Confira com o que existe de verdade. A IA pode inventar uma tabela que não existe, então olhe você mesmo. No Lovable Cloud, abra More → Cloud → Database: a documentação diz que ali aparecem as tabelas do projeto com a quantidade de registros de cada uma. Se o seu banco é um Supabase na sua conta, o painel tem o Schema Visualizer, que desenha as tabelas e as linhas que ligam uma à outra. Toda tabela da resposta da IA precisa estar ali; se não estiver, peça pra refazer.

Passo 3. Guarde a última lista, a dos campos e regras que aparecem em três telas ou mais. São as peças que puxam muita coisa. Imprima, ou guarde num arquivo que você abre antes de cada pedido.

Como usar o mapa antes de cada pedido

Duas perguntas, dez segundos:

  1. O que eu vou mexer está em qual camada? Tela, pode ir. Regra, banco ou login, vá devagar.
  2. Isso está na lista das peças que puxam muito? Se estiver, o pedido começa no modo de planejar, e o plano precisa citar todas as telas que o mapa diz que usam aquela peça. Faltou alguma? Não aprove. Depois da mudança, você confere essas telas, uma por uma.

O mapa não impede a quebra. Ele diz onde olhar antes do cliente dizer.

Era um pedaço do desenho

Saber o que puxa o quê é o D do jeito que eu trabalho: definir antes de mandar construir. Mas o mapa sozinho não te devolve o app quando a quebra passa mesmo assim. Pra isso tem o ponto de retorno, o pedido em fatia pequena e a conferência depois. E o banco tem uma vizinha que o mapa só aponta: mudar o formato de uma ficha que já tem cliente dentro pede cuidado próprio.

Essas peças também se puxam, e têm ordem. A de hoje é só uma tabela: pede o mapa antes do próximo pedido.

Fontes