Pattern “Non modificare” per iterazioni piccole e sicure

Perché piccole modifiche spesso rompono altre parti

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.

Cos'è il pattern “non modificare”

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:

• Flussi (percorsi utente): i passaggi che gli utenti fanno e quali schermate appaiono.
• Dettagli UI e UX: layout, spaziature, ordine dei campi, posizionamento dei pulsanti e interazioni.
• Regole di business e comportamento dei dati: regole di validazione, calcoli dei prezzi, permessi, scritture sul DB e risposte API.

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.

Il template base che puoi riutilizzare

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.

Come congelare i flussi critici senza essere vaghi

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:

• Flussi da congelare: Login, Signup, Checkout, Impostazioni (nessun nuovo step, nessuna riorganizzazione di schermate)
• Edge case da congelare: comportamenti del pulsante Indietro, messaggi di errore, stati vuoti, comportamento al refresh
• Comportamento dei dati da congelare: cosa viene salvato, quando viene salvato e dove appare dopo ricarica
• Sicurezza da congelare: permessi, controlli auth, rate limit, nessun nuovo endpoint pubblico
• Prestazioni da congelare: nessuna chiamata API extra in questi flussi, tempo di risposta non peggiore di ora

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.

Come congelare i dettagli UI e UX

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:

• Mantieni identici: routes/schermate, ordine di navigazione e comportamento del pulsante Indietro
• Mantieni identici: griglia di layout, spaziatura, font, colori e stati dei componenti
• Mantieni identici: tutto il testo e le etichette tranne: \u003cthe one string\u003e
• Regole mobile: mantieni comportamento corrente ai \u003cbreakpoints\u003e, non riorganizzare altre sezioni
• Output: descrivi ogni cambiamento UI effettuato e lista i file/componenti toccati

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.

Come congelare regole di business e comportamento dei dati

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.

Esplicita le regole che non devono cambiare

Invece di “mantieni i prezzi uguali”, definiscilo:

• Pricing: formula esatta, arrotondamento (su/giu), valuta, comportamento IVA, e quando si applicano sconti
• Permessi: quali ruoli possono creare, modificare, cancellare, approvare, rimborsare, esportare o vedere campi sensibili
• Stati: stati permessi e transizioni valide (e cosa le innesca)
• Calcoli: totali, commissioni, crediti, limiti e qualsiasi cap o minimo
• Scritture dati: quali tabelle/record vengono create o aggiornate, e cosa deve restare immutabile

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

Procedura passo-passo: fare una singola richiesta di modifica sicura

Tratta un piccolo aggiornamento come un mini-contratto. Il pattern funziona meglio quando la modifica è stretta e tutto il resto è esplicitamente congelato.

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

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

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

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

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

• Solo il comportamento richiesto è cambiato
• I flussi e le schermate congelate corrispondono ancora
• Regole di business e scritture dati sono invariate
• I test (o i passi manuali) passano come scritto
• Nessun commit di “pulizia” è passato inosservato

Questo funziona particolarmente bene in Koder.ai: incolla la lista di freeze in Planning Mode, falla rispecchiare, poi genera la patch minima.

Errori comuni che causano ancora deriva

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:

• Essere astratti: proteggi l'intento, ma non il flusso click-by-click e i risultati attesi.
• Dimenticare gli edge case: stati vuoti, stati di caricamento, errori di validazione, permessi negati, comportamento offline.
• Accorpare cambi: due o tre modifiche in una sola richiesta rendono i compromessi probabili e le regressioni più difficili da individuare.
• Non definire “identico”: stesso layout UI, stesse chiamate API, stesse scritture DB, stesse email/notifiche, stessi eventi analytics.
• Approvare a sentimento: “sembra a posto” senza verificare i percorsi chiave.

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:

• Esegui il flusso principale end-to-end (quello che hai congelato).
• Genera almeno uno stato di errore e uno stato vuoto.
• Controlla i permessi (admin vs utente normale) se rilevante.
• Conferma gli effetti collaterali: record creati/aggiornati, notifiche inviate e log/metriche invariate.

Se qualcosa differisce, la richiesta mancava di un dettaglio da congelare, non è “cattiva implementazione”.

Esempio: una piccola modifica UI senza cambiare il workflow

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:

• Freeze del flusso: l'invio crea ancora un account, mostra le stesse validazioni e porta l'utente alla stessa schermata successiva.
• Freeze UI: layout della pagina, spaziature, colori e posizione del pulsante rimangono gli stessi.
• Freeze dati: i campi del payload backend e i tipi non cambiano; il valore salvato per company size resta nello stesso formato di prima.
• Freeze regole di business: i campi richiesti restano obbligatori e il pulsante resta disabilitato finché il form non è valido.
• Freeze analytics: lo stesso evento di tracking viene inviato al submit e agli errori di validazione.

Controlli di accettazione che puoi eseguire in pochi minuti:

• Il testo del pulsante mostra “Continue” ovunque (default, loading, stato disabilitato).
• Company size è un dropdown con lo stesso valore di default di prima.
• L'invio raggiunge ancora la dashboard e l'account viene creato.
• Gli utenti esistenti che modificano il profilo vedono ancora correttamente la company size salvata.
• Nessun nuovo warning o test fallito nell'area di signup.

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

Checklist rapida prima di approvare l'aggiornamento

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.

5 controlli rapidi (10 minuti)

Esegui questi controlli sempre nello stesso ordine. Mantiene le revisioni calme e rende le regressioni più facili da individuare.

• Il flusso critico si completa end-to-end: Parti dallo stesso punto d'ingresso che usa un utente reale (login, landing, dashboard) e completa il task principale.
• La UI è identica tranne la modifica voluta: Apri le schermate chiave che hai congelato. Controlla layout, etichette, spaziature e navigazione.
• Le regole di business corrispondono alla realtà: Controlla 2-3 casi che spesso si rompono, come un calcolo di sconto, un permesso di ruolo o una transizione di stato.
• La shape dei dati è invariata: Conferma che non ci siano nuovi campi, campi rinominati, campi rimossi o migrazioni.
• Le integrazioni sono intatte: Conferma che non ci siano cambi di endpoint e nessuna modifica del payload (nomi campi, campi obbligatori, codici di stato).

Quando fare revert e ripetere il prompt

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.

Prossimi passi: applicarlo in Koder.ai per iterazioni più sicure

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.

Inizia con una breve fase di pianificazione

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

Proteggi ogni iterazione con snapshot

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:

• Fai uno snapshot: “Before - change button label only”
• Esegui la fase di pianificazione e conferma la lista di freeze
• Richiedi la singola modifica e chiedi un breve sommario in stile diff di cosa è cambiato
• Verifica con la checklist (UI, flussi, regole, dati)
• Fai uno snapshot: “After - verified”

Riusa lo stesso pattern in tutto lo stack

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.