Aprenda o padrão “não alterar” para fazer uma pequena atualização enquanto congela fluxos de UI, regras de negócio e comportamentos críticos, evitando derivações indesejadas.
Uma mudança “pequena” raramente permanece pequena. Você pede para ajustar o rótulo de um botão e, de repente, o layout da página muda, um formulário para de validar ou uma etapa de checkout passa a se comportar de forma diferente. Aplicativos são sistemas conectados. UI, lógica, dados e integrações dependem uns dos outros.
Uma causa frequente é a falta de fronteiras claras. Se uma solicitação diz “simplificar o cadastro”, o responsável (humano ou IA) precisa adivinhar o que “simplificar” significa. Adivinhar gera edições extras: remover campos, alterar etapas, ajustar textos ou reescrever validações. Outra causa são dependências escondidas: uma pequena mudança de UI pode reutilizar um componente que aparece em cinco outras telas.
Uma iteração segura significa obter a melhoria pretendida enquanto todo o resto permanece efetivamente idêntico. Para uma equipe não técnica, isso quer dizer que o fluxo ainda parece o mesmo para usuários, scripts de suporte continuam a corresponder ao produto e os relatórios continuam consistentes. Para uma equipe técnica, significa sem mudanças inesperadas em rotas, formatos de dados, contratos de API ou comportamentos de casos de borda.
Para tornar isso possível, você precisa congelar o que não pode se mover. Na prática, isso costuma incluir fluxos críticos (os passos exatos que os usuários seguem), detalhes de UI/UX (layout, espaçamento, comportamento de interação), regras de negócio (preços, permissões, validação), comportamento de dados (o que é armazenado e quando) e integrações (eventos de analytics, emails, pagamentos, APIs externas).
Esse padrão “não alterar” reduz riscos ao eliminar suposições e manter a mudança limitada. Não é uma garantia. Ainda pode ocorrer drift se o comportamento original estiver mal definido, se a mudança tocar componentes compartilhados ou se você não verificar o resultado. O objetivo é menos surpresas e aprovações mais rápidas.
O padrão “não alterar” é uma forma simples de pedir uma atualização específica enquanto bloqueia claramente todo o resto. Você nomeia a única mudança desejada e depois escreve uma curta lista de congelamento das partes que devem permanecer idênticas após a atualização.
Isso importa porque modelos tendem a “ajudar” refatorando, renomeando, reorganizando arquivos ou “limpando” lógica enquanto tocam o código. Mesmo que o resultado continue funcionando, essas mudanças extras podem introduzir bugs, alterar comportamento ou dificultar revisões.
Compare estes dois pedidos:
“Melhore a página de configurações.” Isso convida mudanças de design, novo texto, deslocamentos de layout e ajustes de lógica.
“Mude apenas o texto do rótulo de ‘Phone’ para ‘Mobile phone’. Não mude layout, validação ou comportamento de salvar.” Isso é estreito, testável e mais seguro.
Uma lista de congelamento sólida geralmente cobre três áreas:
Ao usar esse padrão em uma ferramenta de build baseada em chat como o Koder.ai, iterações tendem a ser mais rápidas porque o modelo foca na única edição em vez de fazer “melhorias” amplas que você não solicitou.
Esse padrão funciona melhor quando sua solicitação lê como um pequeno contrato: um objetivo claro, uma lista de congelamento e algumas checagens para confirmar o resultado.
Copie este template e preencha os colchetes. Mantenha curto, mas específico.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
Um exemplo concreto: se você quer mudar a cor do botão de checkout, seu objetivo é “Atualizar a cor primária do botão de checkout para #1A73E8.” Seus itens DO NOT CHANGE devem congelar todo o fluxo de checkout, o texto do botão e o cálculo de preços.
Se estiver usando Koder.ai, esse formato também torna as revisões mais rápidas porque você pode comparar as checagens de aceitação com a pré-visualização e o resumo de mudanças antes de aprovar.
Quando você pede uma mudança pequena, não diga apenas “não quebre nada.” Nomeie as jornadas exatas que devem se comportar da mesma maneira, do primeiro clique ao resultado final. Você não está congelando todo o app, está congelando as partes onde regressões doem.
Comece listando os fluxos críticos em linguagem simples: login (incluindo recuperação de senha), onboarding, checkout, configurações. Para cada fluxo, declare como é o “pronto”. Exemplo: “Usuário consegue fazer login com email + senha, vai para o Dashboard e continua logado após refresh.”
Então trave os casos de borda que as pessoas esquecem. O comportamento do botão voltar é uma fonte clássica de drift: “Voltar do Checkout retorna ao Carrinho (não para a Home), e os itens do carrinho permanecem.” Aponte estados de erro (“senha errada mostra a mesma mensagem”), estados vazios (“sem projetos mostra o mesmo texto”), e estados de carregamento (“spinner aparece em até 200ms, sem salto de layout”).
Se expectativas de performance e segurança importam, congele-as também. Se você não mencionar, o modelo pode “melhorar” adicionando requisições extras, novo logging ou alterando checagens de auth.
Uma forma compacta de especificar sem escrever um romance:
Seja específico sobre fluxo de dados em uma frase por item. Exemplo: “Endereço só é salvo após apertar Salvar, armazenado no registro de perfil do usuário, e deve persistir após logout/login.” Esse nível de detalhe evita autosave acidental, novos campos ou mudanças de timing que quebram usuários reais.
Drift de UI costuma acontecer porque o modelo “ajuda” limpando estilos, espaçamentos ou estrutura de componentes. A solução é igual à das regras de negócio: nomeie o que deve permanecer idêntico e diga explicitamente o que pode mudar.
Prenda a estrutura visível. Aponte layout (colunas/linhas, posição de header e footer), regras de espaçamento (padding, gaps, alinhamento) e comportamento de componentes (hover, estado desabilitado, spinners, mensagens de erro). Se um componente tem um feeling específico, diga claramente: “Tamanho, raio e cor do botão devem permanecer exatamente os mesmos.”
Comportamento responsivo precisa de regras explícitas. Se você não mencionar mobile, ferramentas podem “melhorar” isso. Declare os breakpoints que importam e o que deve acontecer em cada um: ordem de empilhamento, elementos escondidos, barras fixas e alvos de toque.
Também congele palavras. Diga ao modelo que todo o copy, rótulos, placeholders e textos auxiliares devem permanecer inalterados, exceto a única string que você está editando. Isso evita reescritas silenciosas que mudam o sentido.
Um prompt compacto para colar em uma solicitação de mudança:
Se puder, peça screenshots antes/depois. Se screenshots não estiverem disponíveis, solicite uma breve “diff de UI” (o que se moveu, o que redimensionou, que cor mudou) para aprovar com confiança.
Regras de negócio são um dos lugares onde uma pequena mudança de UI pode criar uma regressão silenciosa. Um rótulo atualizado pode acidentalmente alterar um cálculo, uma transição de status ou quem pode ver um registro. Trate regras e comportamento de dados como contratos congelados.
Comece nomeando as poucas regras que mais doeriam se mudassem. Escreva-as como testes: entradas, saídas e quem pode fazer o quê.
Em vez de “mantenha preços iguais”, detalhe:
Adicione um exemplo numérico para remover interpretação. Por exemplo: “Subtotal do pedido $120, desconto 10% (aplica antes do imposto), imposto 8.25% sobre o valor com desconto. Total esperado = (120 - 12) * 1.0825 = $116.91. Arredondar para 2 decimais apenas no total final.”
Aponte visibilidade por papel, não só ações. Exemplo: “Agentes de suporte podem ver status do pedido e email do cliente, mas não devem ver dados completos do cartão. Somente admins podem emitir reembolsos.”
Se validações importam, congele-as explicitamente. Mencione gatilho exato e mensagem para o usuário: “Se data de início for posterior à data de término, bloqueie o salvamento e mostre: ‘End date must be after start date.’ Não altere essa frase.”
Não esqueça efeitos colaterais fora do app. Se você envia emails, webhooks ou chama APIs de terceiros, congele o que deve permanecer igual: nomes de eventos, campos do payload, timing (imediato vs. atrasado) e comportamento idempotente (sem envios duplicados em retries).
Trate uma atualização pequena como um mini-contrato. O padrão funciona melhor quando a mudança é estreita e tudo o mais está explicitamente congelado.
Escreva a mudança como uma frase testável. “Na página de configurações, adicionar um toggle para ativar modo escuro” é testável. “Melhorar a UI de configurações” não é. Se não dá para testar em 30 segundos, ainda é amplo demais.
Escreva uma lista de congelamento para as partes que doem se mudarem: fluxo do usuário, elementos-chave de UI, regras de negócio, comportamento de dados e quaisquer APIs ou tabelas que devam ficar iguais.
Adicione checagens de aceitação + um plano de teste rápido. Isso previne “funciona no meu lado” depois. Inclua checagens como: o novo toggle aparece, configurações existentes ainda salvam e nada mais na página se move.
Antes de iniciar a edição, peça ao assistente para repetir suas restrições. Faça com que confirme o que vai mudar e o que deve permanecer idêntico. Se o resumo estiver errado, corrija o prompt antes de permitir as mudanças.
Solicite a menor implementação possível: sem refactors, sem renomeações, sem reorganização, sem formatação além das linhas tocadas. Você está comprando uma mudança, não um makeover.
Uma lista curta de revisão:
Isso funciona especialmente bem no Koder.ai: cole a lista de congelamento no Modo Planning, peça para ecoar as restrições e então gere o menor patch.
A maioria das edições “pequenas” dá errado pela mesma razão: o pedido protege o objetivo, mas não o comportamento. Um modelo pode atingir seu objetivo de uma nova maneira que muda telas, lógica ou dados silenciosamente.
Uma armadilha comum é congelar o resultado (“deixar o onboarding mais suave”) em vez dos passos exatos que os usuários fazem. Outra é escrever “manter tudo igual” e supor que o sistema sabe o que isso significa.
Erros que mais causam drift:
Um exemplo pequeno: você pede para “tornar o botão mais visível” e congela a cor, mas esquece o estado desabilitado. A atualização pode acabar sempre habilitando o botão, mudando o comportamento de forma que só se nota depois.
O que ajuda é especificar o que não pode se mover. Antes de aceitar, faça um rápido passe de regressão:
Se algo diferir, o pedido estava faltando um detalhe congelado, não “mau código”.
Uma iteração segura comum é um pequeno polimento de UI onde o fluxo não pode mudar.
Cenário: um fundador tem uma tela simples de cadastro com um formulário curto (Nome, Email, Tamanho da empresa) e um botão primário que envia o formulário e então roteia o usuário para o dashboard.
Pedido exato de mudança (uma frase): “Renomear o botão primário de 'Create account' para 'Continue' e trocar o campo 'Company size' de input livre para um dropdown.”
Agora aplique o padrão travando o que não pode mudar:
Checagens de aceitação que você pode rodar em minutos:
Um bom assistente deve reiterar os itens congelados, confirmar ambiguidades (por exemplo: opções exatas do dropdown e qual valor será salvo) e então produzir apenas a mudança mínima necessária. Deve também indicar o que deliberadamente não tocou (routing, lógica de validação, formato do payload).
Antes de aceitar uma “pequena mudança”, faça uma verificação rápida que procura drift silencioso. O objetivo não é QA completo. É confirmar que o app continua se comportando igual em tudo o que você disse “não alterar”, exceto pela única edição.
Execute estas checagens sempre na mesma ordem. Isso mantém as revisões calmas e facilita achar regressões.
Reverta se qualquer item congelado mudou, mesmo que o app “ainda funcione”. Um rótulo alterado, um campo novo ou uma regra ligeiramente diferente é sinal de que o modelo tomou liberdade demais.
Reemita o pedido com restrições mais apertadas: reescreva a mudança em uma frase, liste fluxos e telas congeladas pelo nome e acrescente “sem mudanças de schema, sem mudanças de endpoint, sem mudanças de comportamento fora de X.” No Koder.ai, tirar um snapshot antes de testar torna o rollback um clique quando algo diverge.
Se você está construindo no Koder.ai, o padrão “não alterar” funciona melhor como hábito: uma mudança pequena, todo o resto travado, e um caminho claro de volta se algo divergir.
Antes de pedir a mudança, entre no Modo Planning e peça ao assistente para reiterar seu escopo em palavras simples. Peça que repita duas coisas: (1) a mudança exata e (2) uma lista de congelamento clara (fluxos, detalhes de UI e regras de negócio que não podem se mover).
Um prompt de planejamento que funciona bem: “Reitere meu pedido. Depois liste o que não deve mudar. Se algo estiver incerto, pergunte antes de editar.”
Trate cada solicitação como um checkpoint. Crie um snapshot antes de aplicar a alteração e outro snapshot depois de verificar. Se algo quebrar, reverter é mais rápido do que tentar consertar por cima.
Por exemplo, você pode ajustar o rótulo de um botão numa tela React. A mudança parece pequena, mas ainda pode deslocar espaçamento, causar um rerender inesperado ou quebrar um teste automatizado. Um snapshot permite comparar comportamento e reverter rápido.
Um fluxo simples:
O Koder.ai pode gerar web (React), backend (Go + PostgreSQL) e mobile (Flutter). O padrão permanece o mesmo mesmo com código diferente. Congele as partes que definem comportamento, não apenas os arquivos.
Se alterar um endpoint backend, congele formato de request/response, regras de validação e gravações. Se alterar uma tela móvel, congele ordem de navegação, defaults de campos e mensagens de erro. Se alterar lógica de banco, congele o significado das linhas existentes e faça migrations seguras.
Copie seu template, faça uma mudança pequena hoje e verifique com o checklist antes de aceitar. Guarde o texto do template e troque apenas os detalhes na próxima solicitação, uma por vez.
Use quando você quer uma mudança específica e se importa que tudo o mais permaneça igual. É especialmente útil em fluxos como checkout, autenticação, cobrança ou qualquer caminho em que pequenas mudanças gerem impacto real nos usuários.
Porque partes do app compartilham componentes, dados e regras. Uma pequena edição de UI pode tocar um componente reutilizado, deslocar layouts em outros lugares, alterar validações ou modificar payloads de API sem você perceber até mais tarde.
Escreva um objetivo claro e depois liste o que deve permanecer idêntico após a mudança. A ideia é congelar o comportamento (fluxos, regras, dados, integrações) e os detalhes visíveis da UI — não apenas dizer “não quebre nada”.
Seja curto, mas específico: fluxos críticos, detalhes de UI/UX que não podem mudar, regras de negócio, comportamento de dados e integrações. Se você não consegue nomear o que deve permanecer igual, o modelo terá de adivinhar — e adivinhação causa drift.
Limite ao menor escopo que ainda te protege. Por exemplo, congele o fluxo de checkout e seus componentes compartilhados, mas não congele o app inteiro se você está apenas mudando um rótulo em uma tela.
Descreva as jornadas passo a passo e defina o que significa “concluído”. Adicione bordas comuns como comportamento do botão voltar, mensagens de erro, estados vazios e comportamento de atualização para que o fluxo se mantenha idêntico nos pontos que usuários percebem.
Congele a estrutura visível, regras de espaçamento, estados de componentes (hover/disabled/loading) e todo o texto exceto a única string que você está alterando. Sem isso, modelos podem “limpar” estilos ou reescrever textos de forma a alterar significado ou layout.
Congele contratos: formatos de request/response, regras de validação, permissões, cálculos e o que é salvo e quando. Para regras sensíveis como precificação, inclua um exemplo numérico para evitar interpretação ambígua durante a implementação.
Peça checagens de aceitação executáveis e um breve resumo estilo diff do que mudou. Verifique os fluxos congelados ponta a ponta, acione pelo menos um estado de erro e confirme que dados/integrations não mudaram.
Faça um snapshot antes da alteração, rode um planejamento que repita escopo e lista de congelamento, aplique o menor patch possível e depois tire outro snapshot após a verificação — assim o rollback vira um passo simples se algo divergente aparecer.