Padrão “não alterar” para iterações pequenas e seguras

Por que mudanças pequenas frequentemente quebram outras partes

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 que é o padrão de prompt “não alterar”

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:

• Fluxos (jornadas do usuário): os passos que os usuários fazem e quais telas aparecem.
• Detalhes de UI e UX: layout, espaçamento, ordem dos campos, posição dos botões e interações.
• Regras de negócio e comportamento de dados: regras de validação, cálculo de preços, permissões, gravações no banco e respostas de API.

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.

O template básico que você pode reutilizar

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.

Como congelar fluxos críticos sem ser vago

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:

• Fluxos a congelar: Login, Cadastro, Checkout, Configurações (sem novos passos, sem reordenação de telas)
• Bordas a congelar: comportamento do voltar, mensagens de erro, estados vazios, comportamento ao atualizar a página
• Comportamento de dados a congelar: o que é salvo, quando é salvo e onde aparece após reload
• Segurança a congelar: permissões, checagens de auth, limites de taxa, sem novos endpoints públicos
• Performance a congelar: sem chamadas API extras nesses fluxos, tempo de resposta não pior que o atual

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.

Como congelar detalhes de UI e UX

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:

• Manter idênticos: rotas/telas, ordem de navegação e comportamento do botão voltar
• Manter idênticos: grid de layout, espaçamento, fontes, cores e estados de componentes
• Manter idênticos: todo texto e rótulos exceto: <a única string>
• Regras mobile: manter comportamento atual nos breakpoints <x>, não reflow de outras seções
• Saída: descreva cada mudança de UI feita e liste arquivos/componentes tocados

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.

Como congelar regras de negócio e comportamento de dados

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ê.

Especifique as regras que não podem mudar

Em vez de “mantenha preços iguais”, detalhe:

• Preços: fórmula exata, arredondamento (pra cima/baixo), moeda, comportamento de imposto/VAT e quando descontos se aplicam
• Permissões: quais papéis podem criar, editar, excluir, aprovar, reembolsar, exportar ou ver campos sensíveis
• Status: estados permitidos e transições válidas (e o que as dispara)
• Cálculos: totais, comissões, créditos, limites e quaisquer tetos ou mínimos
• Gravações: quais tabelas/records são criadas ou atualizadas, e o que deve permanecer imutável

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).

Passo a passo: fazendo uma solicitação de mudança segura

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

• Apenas o comportamento solicitado mudou
• Fluxos e telas congelados continuam iguais
• Regras de negócio e gravações de dados permanecem inalteradas
• Testes (ou passos manuais) passam conforme descrito
• Nenhum commit de “limpeza” entrou escondido

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.

Erros comuns que ainda causam drift

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:

• Ser abstrato: protege a intenção, mas não o fluxo passo a passo e os resultados esperados.
• Esquecer bordas: estados vazios, loading, erros, permissão negada, comportamento offline.
• Agrupar mudanças: duas ou três alterações em um único pedido incentivam trade-offs e tornam regressões mais prováveis.
• Não definir “idêntico”: mesmo UI, mesmas chamadas API, mesmas gravações no banco, mesmos emails/notifications, mesmos eventos de analytics.
• Aprovar por sensação: “parece ok” sem verificar caminhos-chave.

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:

• Execute o fluxo principal ponta a ponta (o que você congelou).
• Dispare pelo menos um estado de erro e um estado vazio.
• Verifique permissões (admin vs usuário regular) se relevante.
• Confirme efeitos colaterais: registros criados/atualizados, notificações enviadas e logs/metrics inalterados.

Se algo diferir, o pedido estava faltando um detalhe congelado, não “mau código”.

Exemplo: um pequeno polimento de UI sem mudar o fluxo

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:

• Congelamento de fluxo: o envio ainda cria uma conta, mostra as mesmas mensagens de validação e leva o usuário para a mesma tela seguinte.
• Congelamento de UI: layout da página, espaçamento, cores e posição do botão permanecem os mesmos.
• Congelamento de dados: chaves e tipos do payload de backend não mudam; o valor armazenado para tamanho da empresa continua no mesmo formato.
• Congelamento de regras: campos obrigatórios continuam obrigatórios e o botão fica desabilitado até o formulário ser válido.
• Congelamento de analytics: os mesmos eventos de tracking são disparados no submit e nos erros de validação.

Checagens de aceitação que você pode rodar em minutos:

• O texto do botão mostra “Continue” em todos os estados (padrão, loading, desabilitado).
• Company size é um dropdown com o mesmo valor padrão de antes.
• Ao submeter, ainda vai para o dashboard e a conta é criada.
• Usuários existentes editando o perfil ainda veem o tamanho da empresa salvo corretamente.
• Sem novos warnings ou testes falhando na área de signup.

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).

Checklist rápido antes de aprovar a atualização

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.

5 checagens rápidas (10 minutos)

Execute estas checagens sempre na mesma ordem. Isso mantém as revisões calmas e facilita achar regressões.

• Fluxo crítico completa ponta a ponta: Inicie pelo mesmo ponto que um usuário real (login, landing, dashboard) e finalize a tarefa principal.
• UI idêntica exceto pela mudança: Abra as telas-chave congeladas. Escaneie layout, rótulos de botões, espaçamento e navegação.
• Regras de negócio ainda batem: Verifique 2 a 3 casos que costumam quebrar, como cálculo de desconto, permissão de um papel ou transição de status.
• Formato de dados inalterado: Confirme que não há novos campos, campos renomeados, campos removidos ou migrations inesperadas.
• Integrações intocadas: Confirme que não houve mudanças de endpoint e que payloads (nomes de campos, campos obrigatórios, códigos de status) seguem iguais.

Quando reverter e reemitir o prompt

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.

Próximos passos: aplicar no Koder.ai para iterações mais seguras

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.

Comece com um planejamento rápido

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.”

Proteja cada iteração com snapshots

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:

• Fazer um snapshot: “Antes - mudar só o rótulo do botão”
• Rodar o planejamento e confirmar a lista de congelamento
• Pedir a mudança única e requisitar um breve resumo estilo diff do que mudou
• Verificar com o checklist (UI, fluxos, regras, dados)
• Fazer um snapshot: “Depois - verificado”

Reuse o padrão em toda a stack

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.