Come l'AI equilibra prestazioni, leggibilità e semplicità nel codice

Cosa significa bilanciare prestazioni, leggibilità e semplicità nel codice

Prima di giudicare se l'AI ha “bilanciato” qualcosa, conviene chiarire di quale tipo di codice stiamo parlando.

La logica applicativa è il codice che esprime le regole e i flussi del prodotto: controlli di idoneità, decisioni sui prezzi, transizioni di stato degli ordini, permessi e i passaggi di “cosa succede dopo”. È la parte più legata al comportamento di business e quella più soggetta a cambiamenti.

Il codice di infrastruttura è l’impianto: connessioni al database, server HTTP, code di messaggi, configurazioni di deployment, pipeline di logging e integrazioni. Conta, ma di solito non è dove si codificano le regole core dell’app.

I tre obiettivi—e cosa significano davvero

Prestazioni significa che il codice fa il suo lavoro usando tempo e risorse ragionevoli (CPU, memoria, chiamate di rete, query al database). Nella logica applicativa i problemi di prestazioni spesso nascono da I/O extra (troppi interrogazioni, chiamate API ripetute) più che da loop lenti.

Leggibilità significa che un collega può capire accuratamente cosa fa il codice, perché lo fa e dove intervenire—senza “fare il debug a mente” per un’ora.

Semplicità significa meno parti mobili: meno astrazioni, meno casi speciali e meno effetti collaterali nascosti. Il codice semplice è di solito più facile da testare e più sicuro da modificare.

Perché questi obiettivi confliggono nei progetti reali

Migliorare un obiettivo spesso mette sotto stress gli altri.

La cache può accelerare le cose ma aggiunge regole di invalidamento. Un’eccessiva astrazione può rimuovere duplicazioni ma rendere il flusso più difficile da seguire. Le micro-ottimizzazioni possono ridurre i tempi di esecuzione rendendo però l’intento poco chiaro.

Anche l’AI può “risolvere troppo”: può proporre pattern generalizzati (factory, oggetti strategy, helper elaborati) quando una funzione semplice sarebbe più chiara.

Come appare il “sufficientemente buono”

Per la maggior parte dei team, “sufficientemente buono” è:

• Flusso di controllo e naming chiari, con astrazione minima
• Prestazioni che rispettano gli SLA attuali, evitando colli di bottiglia evidenti (soprattutto round trip DB/API)
• Punti di separazione semplici per i test, così le modifiche possono essere fatte in sicurezza

Bilanciare di solito significa rilasciare prima codice facile da manutenere, e complicarsi solo quando misurazioni (o incidenti reali) lo giustificano.

Come l'AI tipicamente sceglie la struttura del codice

L’AI non “decide” la struttura come farebbe un ingegnere. Predice i token più probabili in base al tuo prompt e ai pattern che ha visto. Questo significa che la forma del codice è fortemente influenzata da cosa chiedi e da cosa mostri.

Ottimizza per quello che richiedi (e per i tuoi esempi)

Se chiedi “la soluzione più veloce”, spesso otterrai cache aggiuntive, uscite anticipate e strutture dati che privilegiano la velocità—anche quando il guadagno è marginale. Se chiedi “pulito e leggibile”, di solito ottieni nomi più descrittivi, funzioni più piccole e un flusso di controllo più chiaro.

Fornire un esempio o uno stile di codice esistente è ancora più potente degli aggettivi. Un modello rispecchierà:

• Convenzioni di naming e confini delle funzioni
• Pattern di gestione errori (eccezioni vs valori di ritorno)
• Astrazioni preferite (helper, servizi, repository)

Modalità di fallimento comuni da tenere d'occhio

Poiché l’AI è brava ad assemblare pattern, può scivolare verso soluzioni “astute” che sembrano impressionanti ma sono più difficili da mantenere:

• Over-engineering: livelli non necessari, factory, interfacce o helper generici per una funzionalità semplice
• Codice “clever”: one-liner densi, comprensioni complicate o catene funzionali che nascondono l’intento
• Ottimizzazione prematura: micro-ottimizzazioni (cache manuali, ordinamenti custom) senza misurare

I dati di training plasmano stile e default

L’AI impara da un ampio mix di codice reale: librerie pulite, codice di applicazioni frettoloso, soluzioni da colloqui ed esempi di framework. Questa varietà spiega perché potresti vedere scelte strutturali incoerenti—a volte idiomatiche, a volte eccessivamente astratte, a volte verbose.

Gli umani restano proprietari del compromesso finale

Il modello può proporre opzioni, ma non può conoscere pienamente i tuoi vincoli: livello di competenza del team, convenzioni della codebase, traffico di produzione, scadenze e costi di manutenzione a lungo termine. Tratta l'output dell'AI come una bozza. Il tuo compito è scegliere quale compromesso vuoi realmente—e semplificare finché l’intento non è ovvio.

Il triangolo dei compromessi nella logica applicativa quotidiana

La logica applicativa quotidiana vive dentro un triangolo: prestazioni, leggibilità e semplicità. Il codice generato dall'AI spesso sembra “ragionevole” perché cerca di soddisfare tutti e tre—ma i progetti reali ti costringono a scegliere quale vertice conta di più per una parte specifica del sistema.

Compromessi che riconoscerai subito

Un classico esempio è cache vs chiarezza. Aggiungere una cache può rendere una richiesta lenta più veloce, ma introduce domande: quando scade la cache? Cosa succede dopo un aggiornamento? Se le regole della cache non sono ovvie, i futuri lettori la useranno male o la “sistemeranno” in modo errato.

Un’altra tensione comune è astrazioni vs codice diretto. L’AI può estrarre helper, introdurre utility generiche o aggiungere livelli (“service”, “repository”, “factory”) per apparire ordinato. A volte questo migliora la leggibilità. A volte nasconde la regola di business dietro indirezioni, rendendo più difficili cambiamenti semplici.

Quando le micro-ottimizzazioni danneggiano la comprensione

Piccoli ritocchi—preallocare array, one-liner astuti, evitare variabili temporanee—possono risparmiare millisecondi costando però minuti di attenzione umana. Se il codice non è in un percorso critico, queste micro-ottimizzazioni sono quasi sempre una perdita netta. Nomi chiari e flusso semplice vincono.

Quando il “semplice” diventa lento su scala

D’altro canto, l’approccio più semplice può collassare sotto carico: interrogazioni dentro un loop, ricalcolo dello stesso valore ripetutamente o fetch di più dati del necessario. Ciò che legge bene per 100 utenti può diventare costoso per 100.000.

Regola pratica

Inizia con la versione più leggibile che sia corretta. Poi ottimizza solo dove hai prove (log, profiling, metriche reali di latenza) che il codice è un collo di bottiglia. Questo mantiene l’output dell’AI comprensibile lasciandoti guadagnare prestazioni dove conta.

Promptare l'AI per generare il tipo giusto di logica

L’AI di solito fa esattamente ciò che chiedi—letteralmente. Se il tuo prompt è vago (“rendilo veloce”), può inventare complessità non necessarie o ottimizzare la cosa sbagliata. Il modo migliore per guidare l'output è descrivere come dovrebbe essere il buono e cosa non vuoi fare.

Inizia con criteri di accettazione (e non-obiettivi)

Scrivi 3–6 criteri concreti di accettazione facilmente verificabili. Poi aggiungi non-obiettivi per prevenire deviazioni “di aiuto”.

Esempio:

• Criteri di accettazione: “Deve restituire risultati in meno di 200ms per 10k record; gli errori devono essere user-friendly; mantenere le funzioni sotto ~40 righe.”
• Non-obiettivi: “Niente livello di caching; nessuna dipendenza nuova; nessuna modifica allo schema DB.”

Specifica vincoli che il modello non può indovinare

Prestazioni e semplicità dipendono dal contesto, quindi includi i vincoli che già conosci:

• obiettivi di latenza (p95, p99 se li hai)
• dimensione dei dati e aspettative di crescita
• concorrenza (singolo utente vs molte richieste parallele)
• limiti di memoria (cap serverless, dispositivi mobili, ecc.)

Anche numeri approssimativi sono meglio di niente.

Chiedi una “versione semplice” e una “versione ottimizzata”

Richiedi esplicitamente due versioni. La prima dovrebbe prioritizzare leggibilità e flusso diretto. La seconda può aggiungere ottimizzazioni attente—ma solo se resta spiegabile.

Write application logic for X.
Acceptance criteria: ...
Non-goals: ...
Constraints: latency ..., data size ..., concurrency ..., memory ...
Deliver:
1) Simple version (most readable)
2) Optimized version (explain the trade-offs)
Also: explain time/space complexity in plain English and note any edge cases.

Richiedi spiegazioni e complessità in linguaggio semplice

Chiedi al modello di giustificare le scelte principali (“perché questa struttura dati”, “perché questo ordine di branching”) e di stimare la complessità senza gergo. Questo rende più facile revisionare, testare e decidere se l’ottimizzazione vale il codice aggiunto.

Pattern che mantengono la logica generata dall'AI leggibile

La leggibilità della logica applicativa raramente riguarda la sintassi elegante. Riguarda rendere possibile alla persona successiva (spesso il te stesso futuro) capire cosa fa il codice in una sola lettura. Quando usi l’AI per generare logica, alcuni pattern producono costantemente output che resta chiaro anche dopo che la novità svanisce.

Mantieni le funzioni piccole e single-purpose

L’AI tende a raggruppare “utilemente” validazione, trasformazione, persistenza e logging in una grande funzione. Spingila verso unità più piccole: una funzione per validare l’input, una per calcolare il risultato, una per salvarlo.

Una regola pratica utile: se non riesci a descrivere il compito di una funzione in una frase breve senza usare “e”, probabilmente fa troppo.

Preferisci un flusso di controllo semplice

La logica leggibile favorisce branch ovvi rispetto a compressioni astute. Se una condizione è importante, scrivila come un chiaro blocco if invece che un ternario annidato o una catena di trucchi booleani.

Quando vedi output AI del tipo “fai tutto in un’espressione”, chiedi “early returns” e “guard clauses” invece. Ciò riduce spesso l’annidamento e rende facile individuare il percorso principale.

Assegna nomi che un collega manterrebbe

I nomi significativi battono i pattern di “helper generico”. Invece di processData() o handleThing(), preferisci nomi che codificano l’intento:

• calculateInvoiceTotal()
• isPaymentMethodSupported()
• buildCustomerSummary()

Fai attenzione anche alle utility troppo generiche (per esempio, mapAndFilterAndSort()): possono nascondere regole di business e rendere il debug più difficile.

Commenta l'intento, non i meccanismi

L’AI può produrre commenti verbosi che ripetono il codice. Conserva commenti solo dove l’intento non è ovvio: perché esiste una regola, quale caso limite si protegge o quale assunzione deve rimanere vera.

Se il codice richiede molti commenti per essere comprensibile, considera questo un segnale per semplificare la struttura o migliorare i nomi—non per aggiungere altre parole.

Scelte progettuali che preservano la semplicità

La semplicità raramente significa scrivere “meno codice” a tutti i costi. Significa scrivere codice che un collega può modificare con fiducia la settimana successiva. L’AI può aiutare—se la indirizzi verso scelte che mantengono la forma della soluzione semplice.

Parti dalla struttura dati più semplice che funziona

L’AI spesso salta a strutture intelligenti (mappe di mappe, classi custom, generici annidati) perché sembrano “organizzate”. Contrasta questa tendenza. Per la maggior parte della logica applicativa, array/list e oggetti semplici sono più facili da ragionare.

Se gestisci un piccolo set di elementi, una lista con filtro/find chiaro è spesso più leggibile che costruire un indice prematuramente. Introduci una mappa/dizionario solo quando le lookup sono davvero centrali e ripetute.

Limita i livelli di astrazione finché non hai bisogni ripetuti

Le astrazioni sembrano pulite, ma troppe nascondono il comportamento reale. Quando chiedi all’AI codice, preferisci soluzioni con “un livello di indirezione”: una piccola funzione, un modulo chiaro e chiamate dirette.

Una regola utile: non creare un’interfaccia generica, una factory e un sistema di plugin per risolvere un singolo use case. Aspetta di vedere una seconda o terza variazione, poi refattorizza con fiducia.

Preferisci composizione a catene profonde di ereditarietà

Gli alberi di ereditarietà rendono difficile rispondere: “Da dove proviene realmente questo comportamento?” La composizione mantiene le dipendenze visibili. Invece di class A extends B extends C, favorisci piccoli componenti che combini esplicitamente.

Nel prompt all’AI puoi dire: “Evita l’ereditarietà a meno che non ci sia un contratto condiviso stabile; preferisci passare helper/servizi come parametri.”

Usa pattern familiari al tuo team

L’AI può suggerire pattern tecnicamente corretti ma culturalmente estranei alla tua codebase. La familiarità è una caratteristiche. Chiedi soluzioni che si adattino allo stack e alle convenzioni del team (naming, struttura cartelle, gestione errori), così il risultato si inserisce naturalmente nelle revisioni e nella manutenzione.

Prestazioni senza rendere il codice difficile da leggere

Il lavoro di prestazioni va storto quando ottimizzi la cosa sbagliata. Il miglior codice “veloce” è spesso solo l’algoritmo giusto applicato al problema reale.

Scegli l'algoritmo giusto prima di tunare

Prima di smanettare su loop o one-liner astuti, conferma che stai usando l’approccio sensato: una hash map invece di ricerche lineari ripetute, un set per i controlli di appartenenza, una singola passata invece di molte scansioni. Quando chiedi all’AI aiuto, sii esplicito sui vincoli: dimensione di input prevista, se i dati sono ordinati e cosa significa “abbastanza veloce”.

Una regola semplice: se la complessità è sbagliata (es. O(n²) su liste grandi), nessuna micro-ottimizzazione ti salverà.

Misura prima (con taglie di input reali)

Non indovinare. Usa un profiling di base, benchmark leggeri e—soprattutto—volumi di dati realistici. Il codice generato dall’AI può sembrare efficiente mentre nasconde lavoro costoso (come parsing ripetuto o query extra).

Documenta cosa hai misurato e perché conta. Un breve commento tipo “Ottimizzato per 50k elementi; la versione precedente andava in timeout a ~2s” aiuta il prossimo a non annullare il miglioramento.

Ottimizza solo i percorsi caldi

Mantieni la maggior parte del codice noioso e leggibile. Concentrati sulle parti dove il tempo viene effettivamente speso: loop stretti, serializzazione, chiamate DB, confini di rete. Altrove, preferisci chiarezza all’astuzia, anche se è qualche millisecondo più lenta.

Usa caching, batching e indicizzazione con attenzione

Queste tecniche possono offrire grandi vantaggi, ma aggiungono overhead mentale.

• Caching: annota regole di invalidamento e TTL nei commenti.
• Batching: spiega la dimensione del batch e la gestione dei fallimenti.
• Indicizzazione: segnala quali query traggono beneficio e quale costo aggiunge alle scritture.

Se l’AI propone una di queste, chiedile di includere il “perché”, i compromessi e una breve nota su quando rimuovere l’ottimizzazione.

Testing come rete di sicurezza per la logica generata dall'AI

L’AI può generare logica applicativa “ragionevole” rapidamente, ma non può percepire il costo di un bug sottile in produzione o la confusione di un requisito mal interpretato. I test sono l’ammortizzatore tra una bozza utile e codice affidabile—soprattutto quando poi modifichi per prestazioni o semplifichi una funzione affollata.

Chiedi test contemporaneamente al codice

Quando richiedi l’implementazione, chiedi anche i test. Otterrai assunzioni più chiare e interfacce meglio definite perché il modello deve dimostrare il comportamento, non solo descriverlo.

Una divisione pratica:

• Unit test per regole pure di business (regole di prezzo, controlli di idoneità, validazioni)
• Integration test per la logica di “colla” (query DB, code, client HTTP), usando fake o test container dove appropriato

Copri i casi limite che l'AI spesso manca

L’AI tende a scrivere prima il “happy path”. Rendi espliciti i casi limite nel piano di test così non ti affidi alla memoria o alla conoscenza tribale in seguito. Casi comuni:

• Input vuoti, campi mancanti, null / undefined
• Tipi inaspettati o dati malformati
• Timeout, retry, fallimenti parziali (soprattutto attorno a chiamate di rete)
• Idempotenza (esecuzioni sicure multiple) e eventi duplicati

Usa test table-driven o property-based per regole di business

La logica di business spesso ha molte piccole variazioni (“se l'utente è X e l’ordine è Y, allora fai Z”). I test table-driven mantengono questo leggibile elencando input e output attesi in una matrice compatta.

Se la regola ha invarianti (“il totale non può essere negativo”, “lo sconto non supera il subtotale”), i test property-based possono esplorare più casi di quanti ne scriveresti a mano.

I test proteggono refactor e ottimizzazioni

Una volta che hai buona copertura, puoi con sicurezza:

• Sostituire conditionals annidati con strutture più chiare
• Cacheare o batchare chiamate per le prestazioni
• Estrarre helper senza cambiare comportamento

Considera i test passanti come il tuo contratto: se migliori leggibilità o velocità e i test passano ancora, molto probabilmente la correttezza è preservata.

Checklist di code review per logica applicativa scritta dall'AI

L’AI può generare codice “plausibile” che appare pulito a prima vista. Una buona revisione si concentra meno su se avresti potuto scriverlo e più su se è la logica giusta per la tua app.

La checklist veloce

Usala come primo pass veloce prima di discutere stile o micro-ottimizzazioni:

• Correttezza: corrisponde al requisito e ai casi limite (input vuoti, null, duplicati, fusi orari, arrotondamenti)? Gli errori sono gestiti intenzionalmente?
• Chiarezza: un collega può spiegare il flusso dopo una lettura? I nomi sono specifici (es. isEligibleForDiscount vs flag)?
• Complessità: la logica è più complessa del necessario (condizionali annidati, one-liner astuti, astrazioni premature)?
• Duplicazione: l’AI ha ripetuto logica in rami diversi che andrebbe centralizzata?

Fai attenzione alla complessità nascosta

L’AI spesso “risolve” problemi occultando complessità nei dettagli facili da perdere di vista:

• Numeri e stringhe magiche: sostituisci con costanti o enum e aggiungi commenti solo se la ragione non è ovvia.
• Stato poco chiaro: diffida del codice che muta oggetti condivisi, aggiorna variabili attraverso rami o si affida a default impliciti.
• Effetti collaterali: controlla logging, chiamate di rete, scritture DB o cambi di configurazione globale dentro helper che dovrebbero essere puri.

La coerenza conta più dell’astuzia

Assicurati che l’output segua le convenzioni del progetto (lint, struttura file, tipi di errori). Se non è così, sistemalo ora—inconsistenze di stile rallentano i refactor futuri e le revisioni.

Decidi cosa tenere vs riscrivere a mano

Conserva il codice generato dall’AI quando è semplice, testabile e conforme alle convenzioni del team. Riscrivi quando trovi:

• intento poco chiaro (servirebbero commenti per capirlo)
• flusso di controllo complicato (flag, troppe early return, annidamenti profondi)
• astrazioni “generiche” che non si adattano al dominio

Se applichi questa revisione regolarmente, imparerai quali prompt producono codice già revisionabile—poi affinerai i prompt prima della generazione successiva.

Considerazioni su sicurezza e affidabilità

Quando l’AI genera logica applicativa, spesso ottimizza per la chiarezza del “percorso felice”. Questo può lasciare buchi dove vivono sicurezza e affidabilità: casi limite, modalità di fallimento e default comodi ma insicuri.

Non esporre segreti (nei prompt o nei log)

Tratta i prompt come commenti di codice in un repo pubblico. Non incollare mai chiavi API, token di produzione, dati clienti o URL interni. Attenzione anche all’output: l’AI può suggerire di loggare richieste complete, header o oggetti di eccezione che contengono credenziali.

Una regola semplice: logga identificatori, non payload. Se devi loggare payload per debug, redigi per default e proteggilo dietro una flag d’ambiente.

Valida gli input e fallisci in modo prevedibile

Il codice generato dall’AI a volte assume input ben formati. Rendi esplicita la validazione ai confini (handler HTTP, consumer di messaggi, CLI). Converte input inattesi in errori coerenti (es. 400 vs 500) e rendi i retry sicuri progettando operazioni idempotenti.

L’affidabilità riguarda anche il tempo: aggiungi timeout, gestisci i null e restituisci errori strutturati piuttosto che stringhe vaghe.

Attenzione ai default insicuri

Il codice generato può includere scorciatoie comode:

• Permessi troppo ampi (es. ruoli wildcard, scope “admin”)
• Cripto debole (hashing casalingo, algoritmi obsoleti, mancanza di salt)
• Controlli auth mancanti (fidarsi di user ID inviati dal client)

Richiedi configurazioni least-privilege e posiziona i controlli di autorizzazione vicino all’accesso ai dati che proteggono.

Richiedi assunzioni di sicurezza e modalità di fallimento

Un pattern pratico di prompt: “Spiega le tue assunzioni di sicurezza, il modello di minaccia e cosa succede quando le dipendenze falliscono.” Vuoi che l’AI dica cose tipo: “Questo endpoint richiede utenti autenticati,” “i token vengono ruotati,” “i timeout DB ritornano 503,” ecc.

Se quelle assunzioni non corrispondono alla realtà, il codice è sbagliato—anche se è veloce e leggibile.

Manutenibilità nel tempo: quando refattorizzare e quando fermarsi

L’AI può generare logica applicativa pulita rapidamente, ma la manutenibilità si guadagna nel tempo: requisiti che cambiano, nuovi membri nel team e traffico che cresce in modo non uniforme. L’obiettivo non è perfezionare il codice all’infinito—è mantenerlo comprensibile mentre continua a soddisfare bisogni reali.

Refattorizza quando l'attrito è misurabile

Refactor è giustificato quando puoi indicare un costo concreto:

• Una feature richiede significativamente più tempo perché la logica è aggrovigliata o duplicata.
• I bug si concentrano attorno allo stesso modulo perché le responsabilità non sono chiare.
• Il lavoro sulle prestazioni è bloccato perché il codice nasconde dove si spende il tempo.

Se nulla di tutto questo accade, resisti alla tentazione del “cleanup fine a sé stesso.” Un po’ di duplicazione è spesso più economica che introdurre astrazioni che hanno senso solo nella tua testa.

Documenta il “perché”, non solo il “cosa”

Il codice generato dall’AI spesso sembra ragionevole, ma il te futuro ha bisogno di contesto. Aggiungi brevi note che spieghino decisioni chiave:

• perché una sezione è stata ottimizzata (cosa era lenta)
• perché qualcosa è stato astratto (cosa si è ripetuto)
• perché è stata mantenuta un’approccio più semplice (la complessità non valeva)

Tieni queste note vicino al codice (docstring, README o una breve nota in /docs) e collega ai ticket se pertinenti.

Aggiungi diagrammi leggeri per flussi critici

Per pochi percorsi core, un piccolo diagramma evita fraintendimenti e riduce riscritture accidentali:

Request → Validation → Rules/Policy → Storage → Response
                 ↘ Audit/Events ↗

Sono rapidi da mantenere e aiutano i reviewer a vedere dove inserire nuova logica.

Registra “limiti noti” e piani di refactor

Annota aspettative operative: soglie di scala, colli attesi e cosa farai dopo. Esempio: “Funziona fino a ~50 richieste/sec su una singola istanza; il collo è la valutazione delle regole; passo successivo la cache.”

Questo trasforma il refactor in una risposta pianificata all’uso invece che in congetture, ed evita ottimizzazioni premature che danneggiano leggibilità e semplicità.

Un workflow pratico per mantenere l'output AI veloce e comprensibile

Un buon workflow tratta l’output AI come una prima bozza, non una feature finita. L’obiettivo è ottenere rapidamente qualcosa di corretto e leggibile, poi stringere le prestazioni solo dove conta.

Questo è anche il punto dove gli strumenti importano. Se usi una piattaforma di vibe-coding come Koder.ai (chat-to-app con planning mode, export del sorgente e snapshot/rollback), gli stessi principi si applicano: ottieni prima una versione semplice e leggibile della logica applicativa, poi iteri con piccoli cambi revisionabili. La piattaforma può accelerare bozza e scaffolding, ma il team rimane proprietario dei compromessi.

Standard di team (stabilisci prima di promptare)

Scrivi pochi default così ogni cambiamento generato dall’AI parte dalle stesse aspettative:

• Limiti di complessità: preferire funzioni sotto ~40–60 righe; evitare annidamenti profondi; tenere bassa la complessità ciclomatica (per esempio, “nessuna funzione sopra 10 senza giustificazione”).
• Regole di naming: termini di dominio sopra quelli tecnici (es. invoiceTotal, non calcX); nessuna variabile a lettera singola fuori da loop brevi.
• Obiettivi di coverage: aspettative minime (per esempio, “la nuova logica deve includere unit test per happy path + casi chiave”).
• Confini di prestazione: ottimizza solo quando ci sono prove (endpoint lento, loop caldo o regressione misurata).

Genera → revisiona → misura → affina

1. Descrivi la feature e i vincoli (input, output, invarianti, casi d’errore).

2. Chiedi all’AI un’implementazione semplice prima più i test.

3. Revisiona per chiarezza prima che per astuzia. Se è difficile spiegare in poche frasi, probabilmente è troppo complesso.

4. Misura solo le parti rilevanti. Esegui un benchmark rapido o aggiungi tempi leggeri attorno al presunto collo.

5. Affina con prompt mirati. Invece di “rendilo più veloce”, chiedi “riduci le allocazioni in questo loop mantenendo la struttura della funzione”.

Cosa fare e cosa evitare

• Fai chiedere funzioni piccole e componibili con nomi chiari.
• Fai richiedere input/outputs di esempio e test nella stessa risposta.
• Fai richiedere commenti solo dove il “perché” non è ovvio.
• Non fare accettare micro-ottimizzazioni senza misurazione.
• Non fare permettere helper “magici” o astrazioni non usate altrove.
• Non fare mergiare codice AI che nessuno nel team sa modificare comodamente.

Template di prompt riutilizzabile (copia/incolla)

You are generating application logic for our codebase.

Feature:
- Goal:
- Inputs:
- Outputs:
- Business rules / invariants:
- Error cases:
- Expected scale (typical and worst-case):

Constraints:
- Keep functions small and readable; avoid deep nesting.
- Naming: use domain terms; no abbreviations.
- Performance: prioritize clarity; optimize only if you can justify with a measurable reason.
- Tests: include unit tests for happy path + edge cases.

Deliverables:
1) Implementation code
2) Tests
3) Brief explanation of trade-offs and any performance notes

Se mantieni questo ciclo—genera, revisiona, misura, affina—otterrai codice che resta comprensibile pur soddisfacendo le aspettative di prestazione.