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

"Uma mudança por vez: a regra que faz a IA parar de quebrar o login quando você pede um campo"

"Pediu um campo de observação e a IA mexeu no total. O checklist da fatia pequena: o que pedir, o que cercar no pedido e o que conferir depois."

A cena é sempre a mesma.

Alguém pede: "coloca um campo de observação no orçamento". Você repassa pra IA. Ela coloca o campo e, no mesmo pedido, altera o cálculo do total. Você só descobre quando o cliente reclama do valor. Pede pra consertar o total, ela conserta e quebra o login.

Um comentário no TabNews explicou o porquê melhor do que eu explicaria, olhando um app feito por IA:

"Toda a lógica, os componentes e os estilos de cada tela estão misturados dentro de um único arquivo. [...] Um simples ajuste pode virar um pesadelo porque você não sabe onde mexer sem correr o risco de quebrar algo."

Não foi você que pediu errado

"Um campo" parece pequeno. Pra você, é uma linha a mais na tela. Pro código, o campo de observação e o cálculo do total costumam morar no mesmo arquivo, às vezes no mesmo bloco. A IA não edita uma linha: ela reescreve o pedaço inteiro onde o campo vai entrar, e aproveita pra "melhorar" o que estava por perto. Ninguém pediu isso. Ninguém proibiu também.

Então o problema não é o seu pedido ser burro. É ele ser maior do que parece, e sem cerca. Já contei aqui o que fazer quando a quebra já aconteceu e como voltar pra ontem com o git. Este post é o de antes: como encolher o pedido pra quebra quase não acontecer. Três momentos.

Antes de pedir: o pedido é mesmo uma mudança só?

Quatro testes. Falhou em um, o pedido ainda é grande.

  • Cabe numa frase sem "e". "Adicionar um campo de observação no orçamento" passa. "Adicionar observação e mostrar no PDF e na lista" são três pedidos.
  • Mexe numa tela só. Se você precisa dizer o nome de duas telas, são duas mudanças.
  • Você sabe dizer como vai conferir. Uma frase: "vou saber que está pronto quando, fazendo X, eu vir Y". Se não consegue escrever, o pedido ainda está vago.
  • Se der errado, você perde no máximo meia hora. Pedido que você não teria coragem de jogar fora é pedido grande demais.

O campo de observação, partido do jeito certo, vira três fatias, uma por rodada:

  1. O campo aparece no formulário do orçamento e fica salvo (fecha, abre de novo, o texto continua lá).
  2. A observação aparece no orçamento que vai pro cliente.
  3. A observação aparece na lista de orçamentos, cortada se for longa.

Parece mais lento. Não é: cada fatia se confere em dois minutos, e se uma quebrar algo, você sabe qual foi.

No pedido: o que cercar

Três parágrafos que eu colo em todo pedido de fatia pequena, sem uma palavra de programação:

Adicione um campo de texto "Observação" no formulário de orçamento,
salvo junto com o orçamento.

Mantenha exatamente como estão: o cálculo do total, o login e as
outras telas. Não mude o nome de nada que já existe.

Antes de construir, me diga quais arquivos vai alterar. Se precisar
tocar em algo fora disso, pare e me pergunte.

O parágrafo do meio é o que salva o total. Repare que ela diz o que manter, e cita pelo nome a coisa mais cara do seu app, a que dá prejuízo se mudar. Quando a IA sai dessa cerca, você tem como saber, porque ela estava escrita antes. (O molde completo, de seis linhas, está neste post.)

E tem uma coisa nova que ajuda muito: o modo de planejar. Lovable e Replit têm hoje um modo em que a IA lê o projeto e devolve um plano sem mexer em nada. No Lovable ele se chama Plan (antes era "Chat"), e a documentação é direta: mudança no código só acontece depois que você aprova o plano. No Replit também se chama Plan, e a documentação diz que ele não altera nem o código nem os dados do projeto. Nos dois, planejar gasta crédito, mas ler um plano que cita o total sai bem mais barato que descobrir pelo cliente.

Então: mande o pedido no modo de planejar. Se o plano menciona o total, o login ou uma tela que você não citou, não aprove. Peça de novo, mais estreito.

Depois: o que conferir, nesta ordem

  • Conte o que foi mexido. Peça "liste os arquivos que você alterou" ou, se o código está na sua máquina, rode git status. Um campo de texto não deveria mexer em arquivo com "auth" (login) ou "migration" (mudança na estrutura do banco) no nome.
  • Confira a fatia. A frase que você escreveu antes: abriu o orçamento, escreveu a observação, fechou, abriu de novo, o texto está lá.
  • Confira a coisa cara. Um orçamento com números que você sabe de cabeça: três itens de R$ 10 e R$ 15 de frete tem que dar R$ 45. Se der outra coisa, a cerca foi pulada.
  • Confira o login. Sair e entrar de novo. Dez segundos.
  • Marque o ponto. Passou tudo, salve a versão com um nome do que funciona ("funciona: observação salva"). Só então peça a fatia 2.

Quebrou alguma coisa? Não peça "conserta". Volte pro ponto marcado e peça de novo, menor.

Era uma parede, e ela tem vizinhas

Fatia pequena é o segundo passo do jeito que eu trabalho: definir, ordenar a construção em fatia pequena, não aceitar sem prova, operar. Ela reduz a quebra, mas não substitui as vizinhas: sem ponto de retorno, a fatia que quebrou não tem pra onde voltar; e voltar o código não desfaz a coluna que a IA criou no banco.

Cada uma dessas é uma parede, e elas têm ordem. Mas a de hoje custa só três parágrafos colados no próximo pedido. Pega a próxima coisa que você ia pedir, passa pelos quatro testes e vê em quantas fatias ela se divide.

Fontes