Impara il pattern “Non modificare” per effettuare una singola piccola modifica bloccando i flussi UI principali, le regole di business e i comportamenti critici, evitando che il resto cambi.
Una “piccola” modifica raramente resta piccola. Chiedi di sistemare l'etichetta di un pulsante e all'improvviso il layout di una pagina si sposta, un form smette di validare o una fase di checkout si comporta diversamente. Le app sono sistemi connessi. UI, logica, dati e integrazioni si influenzano a vicenda.
Una causa frequente sono i confini poco chiari. Se una richiesta dice “rendere la registrazione più semplice”, chi costruisce (umano o IA) deve indovinare cosa significa “più semplice”. Indovinare porta a modifiche extra: rimozione di campi, cambi di step, adattamenti del copy o riscritture della validazione. Un'altra causa sono le dipendenze nascoste. Una piccola modifica UI può riutilizzare un componente presente in cinque schermate diverse.
Un'iterazione sicura significa ottenere il miglioramento voluto mentre tutto il resto resta effettivamente identico. Per un team non tecnico, significa che il workflow continua a sembrare lo stesso agli utenti, gli script di supporto corrispondono ancora al prodotto e i report hanno senso. Per un team tecnico, significa nessuna modifica inaspettata a route, shape dei dati, contratti API o comportamenti in edge-case.
Per rendere possibile tutto ciò, devi congelare ciò che non deve cambiare. In pratica, questo di solito include i flussi critici (i passaggi esatti che gli utenti percorrono), i dettagli UI/UX (layout, spaziature, comportamento di interazione), le regole di business (prezzi, permessi, validazioni), il comportamento dei dati (cosa viene salvato e quando) e le integrazioni (eventi analytics, email, pagamenti, API esterne).
Questo pattern “non modificare” riduce il rischio eliminando l'indovinare e mantenendo la modifica entro uno scope ristretto. Non è una garanzia. Puoi comunque avere derive se il comportamento originale è definito male, se la modifica tocca componenti condivisi o se non verifichi il risultato. L'obiettivo è meno sorprese e approvazioni più rapide.
Il pattern “non modificare” è un modo semplice per chiedere un singolo aggiornamento specifico bloccando chiaramente tutto il resto. Nomini la modifica che vuoi, poi scrivi una breve lista di freeze delle parti che devono restare identiche dopo l'aggiornamento.
Questo è importante perché i modelli spesso cercano di essere utili rifattorizzando, rinominando, riorganizzando file o “ripulendo” la logica mentre toccano il codice. Anche se l'output funziona ancora, quei cambi extra possono introdurre bug, cambiare comportamento o rendere le revisioni più difficili.
Confronta queste due richieste:
“Rendi migliore la pagina delle impostazioni.” Questo invita cambi di design, nuovo copy, spostamenti di layout e modifiche logiche.
“Cambia solo il testo dell'etichetta da 'Phone' a 'Mobile phone'. Non cambiare layout, validazione o comportamento di salvataggio.” Questa è stretta, testabile e più sicura.
Una solida lista di freeze di solito copre tre aree:
Quando usi questo pattern in uno strumento di build via chat come Koder.ai, le iterazioni tendono a procedere più velocemente perché il modello si concentra sulla singola modifica invece di apportare ampie “migliorie” che non hai chiesto.
Questo pattern funziona meglio quando la tua richiesta assomiglia a un piccolo contratto: un obiettivo chiaro, una lista di freeze e alcuni controlli per confermare il risultato.
Copia questo template e riempi le parentesi. Mantienilo corto ma specifico.
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 -\u003e checkout -\u003e 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
Un esempio concreto: se vuoi cambiare il colore del pulsante di checkout, il tuo obiettivo è “Aggiorna il colore del pulsante primario di checkout a #1A73E8.” Gli elementi nella sezione DO NOT CHANGE devono congelare l'intero flusso di checkout, il testo del pulsante e il calcolo dei prezzi.
Se usi Koder.ai, questo formato rende anche le revisioni più rapide perché puoi confrontare i controlli di accettazione con l'anteprima e il sommario della modifica prima di approvare.
Quando chiedi una piccola modifica, non limitarti a dire “non rompere nulla.” Nomina i percorsi utente esatti che devono comportarsi allo stesso modo, dal primo clic al risultato finale. Non stai congelando l'intera app, stai congelando le parti dove le regressioni fanno male.
Inizia elencando i flussi critici in linguaggio semplice: login (incluso reset password), onboarding, checkout, impostazioni. Per ogni flusso, dichiara cosa significa “fatto”. Esempio: “L'utente può autenticarsi con email + password, atterra sulla Dashboard e rimane loggato dopo un refresh.”
Poi blocca gli edge case che si dimenticano: il comportamento del pulsante Indietro è una fonte classica di deriva: “Indietro da Checkout ritorna al Carrello (non alla Home), e gli articoli rimangono.” Indica stati di errore (“password sbagliata mostra lo stesso messaggio”), stati vuoti (“nessun progetto mostra lo stesso testo dello schermo vuoto”) e stati di caricamento (“lo spinner appare entro 200ms, nessun salto di layout”).
Se prestazioni e sicurezza sono importanti, congelale anche. Se non le menzioni, il modello potrebbe “migliorare” le cose aggiungendo richieste extra, nuovo logging o cambiando i controlli auth.
Un modo compatto per specificarlo senza scrivere un romanzo:
Sii specifico sul flusso dei dati in una frase per ciascun elemento. Per esempio: “L'indirizzo viene salvato solo dopo aver premuto Salva, memorizzato nel record profilo utente e deve persistere dopo logout/login.” Quel livello di dettaglio evita salvataggi automatici, nuovi campi o cambi di tempistica che rompono gli utenti reali.
La deriva della UI succede spesso perché il modello “aiuta” ripulendo stili, spaziature o struttura dei componenti. La soluzione è la stessa delle regole di business: nomina cosa deve restare identico e nomina la singola cosa che è permessa cambiare.
Blocca la struttura visibile. Indica layout (colonne/righe, header e footer), regole di spaziatura (padding, gap, allineamento) e comportamento dei componenti (hover, stato disabilitato, spinner di caricamento, messaggi di errore). Se un componente ha una sensazione specifica, dillo chiaramente: “Dimensione, raggio e colore del pulsante devono rimanere esattamente gli stessi.”
Il comportamento responsive richiede regole esplicite. Se non menzioni il mobile, gli strumenti potrebbero “migliorarlo”. Indica i breakpoint di cui ti importa e cosa deve accadere a ciascuno: ordine di stacking, elementi nascosti, barre fisse e target di tap.
Congela anche le parole. Dichiara che tutto il testo, le etichette, i placeholder e i testi di aiuto devono restare invariati, eccetto la singola etichetta che stai modificando. Questo impedisce riscritture silenziose che cambiano significato.
Un prompt compatto che puoi incollare in una richiesta di modifica:
Se puoi, chiedi screenshot prima/dopo. Se non sono disponibili, richiedi una breve “UI diff” (cosa si è mosso, cosa è stato ridimensionato, cosa ha cambiato colore) così puoi approvare con fiducia.
Le regole di business sono uno degli spazi dove una piccola modifica UI può creare una regressione silenziosa. Un cambio di etichetta può accidentalmente alterare un calcolo, una transizione di stato o chi può vedere un record. Considera regole e comportamento dei dati come contratti da congelare.
Inizia nominando le poche regole che causerebbero i maggiori danni se dovessero deviare. Scrivile come test: input, output e chi può fare cosa.
Invece di “mantieni i prezzi uguali”, definiscilo:
Aggiungi un esempio numerico per rimuovere interpretazioni. Per esempio: “Subtotale ordine $120, sconto 10% (applica prima delle tasse), imposta 8.25% sull'importo scontato. Totale atteso = (120 - 12) * 1.0825 = $116.91. Arrotondamento a 2 decimali solo sul totale finale.”
Specifica la visibilità basata sui ruoli, non solo le azioni. Esempio: “Gli agenti di supporto possono vedere stato ordine e email cliente, ma non i dettagli completi della carta. Solo gli admin possono emettere rimborsi.”
Se le validazioni sono importanti, congelale esplicitamente. Menziona il trigger esatto e il messaggio rivolto all'utente: “Se la data di inizio è dopo la data di fine, blocca il salvataggio e mostra: ‘End date must be after start date.’ Non cambiare questa formulazione.”
Non dimenticare gli effetti collaterali fuori dall'app. Se invii email, webhook o chiami API terze, congela cosa deve restare uguale: nomi degli eventi, campi del payload, tempistiche (immediato vs ritardato) e comportamento di idempotenza (nessun invio duplicato al retry).
Tratta un piccolo aggiornamento come un mini-contratto. Il pattern funziona meglio quando la modifica è stretta e tutto il resto è esplicitamente congelato.
Scrivi la modifica come una frase testabile. "Nella pagina impostazioni, aggiungi un toggle per abilitare la dark mode" è testabile. "Migliora la UI delle impostazioni" non lo è. Se non puoi testarlo in 30 secondi, è ancora troppo ampio.
Scrivi una lista di freeze per le parti che farebbero più male se deviassero: il flusso utente, gli elementi UI chiave, le regole di business, il comportamento dei dati e le API o tabelle DB che devono restare le stesse.
Aggiungi controlli di accettazione più un piano di test rapido. Qui previeni i “funziona sul mio ambiente” imprevisti. Includi controlli come: il nuovo toggle appare, le impostazioni esistenti continuano a salvare e nulla altro nella pagina si muove.
Prima che inizi qualsiasi modifica, chiedi all'assistente di ripetere i vincoli. Fai confermare cosa cambierà e cosa deve rimanere identico. Se il riassunto è sbagliato, correggi il prompt prima di permettere modifiche.
Richiedi l'implementazione più piccola possibile: niente refactor, nessuna rinominazione, nessuna riorganizzazione, nessuna formattazione oltre le linee toccate. Stai comprando una modifica, non un restyling.
Una breve checklist di revisione:
Questo funziona particolarmente bene in Koder.ai: incolla la lista di freeze in Planning Mode, falla rispecchiare, poi genera la patch minima.
La maggior parte delle modifiche “piccole” fallisce per la stessa ragione: la richiesta protegge l'obiettivo, ma non il comportamento. Un modello può raggiungere il tuo obiettivo in un modo nuovo che cambia di nascosto schermate, logica o dati.
Una trappola comune è congelare il risultato (“rendi l'onboarding più fluido”) invece dei passi esatti che l'utente compie. Un'altra è scrivere “mantieni tutto uguale” e presumere che il sistema sappia cosa significa.
Errori che più spesso causano deriva:
Un piccolo esempio: chiedi di “rendere il pulsante più visibile” e congeli il colore, ma dimentichi di congelare lo stato disabilitato. L'aggiornamento potrebbe rendere il pulsante sempre abilitato, cambiando il comportamento in modo che noti solo dopo.
Ciò che aiuta è essere specifici su ciò che non può muoversi. Prima di accettare l'aggiornamento, fai un rapido passaggio di regressione:
Se qualcosa differisce, la richiesta mancava di un dettaglio da congelare, non è “cattiva implementazione”.
Un'iterazione sicura comune è una piccola lucidatura UI dove il workflow non può cambiare.
Scenario: un founder ha una semplice schermata di signup con un form breve (Nome, Email, Dimensione azienda) e un pulsante primario che invia il form e poi indirizza l'utente alla dashboard.
Modifica esatta richiesta (una frase): “Rinomina il pulsante primario da 'Create account' in 'Continue' e trasforma il campo 'Company size' da input a testo libero a un dropdown.”
Ora applica il pattern congelando ciò che non deve muoversi:
Controlli di accettazione che puoi eseguire in pochi minuti:
Una buona risposta dell'assistente dovrebbe ripetere gli elementi congelati, confermare eventuali ambiguità (esempio: opzioni esatte del dropdown e quale valore viene salvato) e poi produrre solo il cambiamento UI/codice minimo necessario. Dovrebbe anche indicare cosa non ha toccato deliberatamente (routing, logica di validazione, shape del payload).
Prima di accettare una “piccola modifica”, fai un rapido controllo che cerchi derive silenziose. L'obiettivo non è una QA completa, è confermare che l'app si comporti ancora come hai detto “non modificare”, eccetto per la singola modifica voluta.
Esegui questi controlli sempre nello stesso ordine. Mantiene le revisioni calme e rende le regressioni più facili da individuare.
Fai revert se qualsiasi elemento congelato è cambiato, anche se l'app “funziona ancora”. Un'etichetta cambiata, un nuovo campo o una regola leggermente diversa è segno che il modello ha preso libertà.
Riformula la richiesta con vincoli più stretti: ripeti la singola modifica in una frase, elenca i flussi e le schermate da congelare per nome e aggiungi “no change di schema, no change di endpoint, nessun comportamento esterno a X.” Se usi Koder.ai, uno snapshot prima del test rende il rollback un'operazione istantanea quando qualcosa devia.
Se costruisci in Koder.ai, il pattern “non modificare” funziona meglio come abitudine: una piccola modifica, tutto il resto bloccato e un modo chiaro per tornare indietro se qualcosa devia.
Prima di chiedere la modifica, passa in Planning Mode e fai ripetere all'assistente il tuo ambito in parole semplici. Chiedigli di ripetere due cose: (1) la modifica esatta, e (2) una chiara lista di freeze (flussi, dettagli UI e regole di business che non devono muoversi).
Un prompt di pianificazione che funziona bene: “Ripeti la mia richiesta. Poi elenca cosa non deve cambiare. Se qualcosa è poco chiaro, fai domande prima di modificare.”
Tratta ogni richiesta di modifica come un checkpoint. Crea uno snapshot prima di applicare l'aggiornamento e un altro snapshot dopo la verifica. Se qualcosa si rompe, il rollback è più veloce che cercare di correggere una modifica sbagliata.
Ad esempio, potresti modificare l'etichetta di un pulsante in una schermata React. La modifica sembra piccola, ma può comunque spostare spaziature, innescare un rerender o rompere un test automatico. Uno snapshot ti permette di confrontare comportamento e tornare indietro rapidamente.
Un workflow semplice:
Koder.ai può generare web (React), backend (Go + PostgreSQL) e mobile (Flutter). Il pattern resta lo stesso anche se il codice cambia. Congela le parti che definiscono il comportamento, non solo i file.
Se stai cambiando un endpoint backend, congela la shape della request/response, le regole di validazione e le scritture sui dati. Se stai cambiando una schermata mobile, congela l'ordine di navigazione, i default dei campi e i messaggi di errore. Se modifichi logica DB, congela cosa significano le righe esistenti e rendi sicure le migrazioni.
Copia il template, fai una piccola modifica oggi e verificane il risultato con la checklist prima di accettare. Tieni il testo del template e sostituisci la prossima richiesta di modifica, una alla volta.
Usalo ogni volta che vuoi una sola modifica specifica e ti interessa che tutto il resto rimanga identico. È particolarmente utile per checkout, autenticazione, fatturazione o qualsiasi flusso dove piccole deviazioni creano problemi reali agli utenti.
Perché le parti di un'app condividono componenti, dati e regole. Una piccola modifica UI può toccare un componente riutilizzato, spostare layout altrove, alterare la validazione o modificare payload API senza che tu te ne accorga fino a dopo.
Scrivi un obiettivo chiaro e poi elenca cosa deve rimanere identico dopo la modifica. L'importante è congelare il comportamento (flussi, regole, dati, integrazioni) e i dettagli visibili della UI, non solo dire “non rompere nulla”.
Sii breve ma specifico: flussi critici, dettagli UI/UX che non devono muoversi, regole di business, comportamento dei dati e integrazioni. Se non riesci a nominare cosa deve restare uguale, il modello dovrà indovinare e l'indovinare causa deviazioni.
Limitane l'ambito alla porzione più piccola che ti protegge. Per esempio congela il flusso di checkout e i componenti condivisi, ma non congelare l'intera app se stai solo cambiando un'etichetta in una singola schermata.
Nomina i percorsi passo-passo e definisci cosa significa “completato”. Aggiungi i casi limite comuni come comportamento del pulsante Indietro, messaggi di errore, stati vuoti e refresh così il flusso resta identico nei punti che maggiormente contano per gli utenti.
Congela esplicitamente struttura del layout, spaziatura, stati dei componenti (hover/disabilitato/caricamento) e tutto il testo eccetto la singola stringa che stai cambiando. Senza questo, i modelli potrebbero “ripulire” stili o riscrivere testi in modi che cambiano significato o layout.
Congela i contratti: shape delle request/response, regole di validazione, permessi, calcoli e cosa viene salvato e quando. Aggiungi un esempio numerico per le regole sensibili come il pricing così non ci siano interpretazioni nell'implementazione.
Chiedi controlli di accettazione eseguibili rapidamente e un breve sommario tipo diff di cosa è cambiato e dove. Poi verifica i flussi congelati end-to-end, genera almeno uno stato di errore e conferma che dati e integrazioni non siano cambiati.
Fai uno snapshot prima della modifica, esegui una fase di pianificazione che ripeta ambito e lista di freeze, poi applica la patch minima. Dopo la verifica, scatta un altro snapshot così il rollback è un singolo passo in caso di deriva.