Chiedere alternative e trade-off, non soluzioni uniche

Un modello AI presenta sempre una soluzione come “la” soluzione. È una distorsione strutturale: il prossimo token più probabile produce sempre una sola continuazione. Senza chiederlo esplicitamente, non vedi mai le altre due-tre opzioni che il modello aveva considerato. Quella visibilità è il vantaggio principale del vibe coding ben fatto: scelte motivate invece di scelte di default.

Perché questa lezione conta

Accettare la prima soluzione presentata significa delegare la decisione architetturale al modello. Va bene per task triviali, è disastro per scelte irreversibili. Le decisioni che rimpiangerai fra sei mesi sono quelle prese senza alternative considerate. Forzare il modello a rendere visibili 2-3 vie con trade-off non aumenta solo la qualità: ti rende decisore informato.

Obiettivo operativo

Alla fine devi saper:

1. richiedere esplicitamente alternative con trade-off;
2. valutare alternative su criteri rilevanti per il tuo caso;
3. riconoscere quando una “alternativa” è solo finta variante.

Nucleo della lezione

1. Quando chiedere alternative

Non sempre serve. Per ogni task valuta:

Vale la pena chiederle quando:

• la scelta è irreversibile o costosa (vedi lezione 27);
• c’è incertezza reale sul modo migliore;
• vuoi imparare/capire più che ottenere risultato;
• diversi vincoli del progetto suggeriscono compromessi diversi;
• la prima risposta del modello sembra “default” e non motivata.

Non serve quando:

• task piccolo e reversibile (rinomina, format, fix banale);
• solo una via ragionevole esiste;
• già hai deciso e vuoi solo l’esecuzione.

Sopra-richiedere alternative = analysis paralysis. Trovare il giusto livello dipende dalla criticità della scelta.

2. Categorie di alternative

Cinque dimensioni dove le alternative emergono:

Architettura: monolite vs servizi, server-rendered vs SPA, API REST vs GraphQL.

Dipendenze: libreria popolare (più feature, più peso) vs minimale (più codice tuo, meno peso) vs zero (più codice tuo, controllo totale).

Modellazione dati: relazionale vs documentale, normalizzato vs denormalizzato, soft delete vs hard delete.

UI: pattern A vs B (sidebar fissa vs collassabile, modal vs page, paginazione vs infinite scroll).

Test: unit vs integration vs E2E, mock vs real, copertura ampia vs critica.

Gestione errori: throw vs Result, fail-fast vs fallback, log puntuale vs structured.

Per ognuna di queste, una scelta arbitraria del modello può essere sbagliata per il tuo caso.

3. Trade-off rilevanti

Una “alternativa” senza trade-off è solo un’altra soluzione, non una scelta. I trade-off da chiedere sempre:

• Semplicità: quanto è facile capire il codice fra 6 mesi.
• Performance: latenza, throughput, memoria, bundle size.
• Manutenzione: chi e come lo manterrà.
• Sicurezza: superficie di attacco, complessità delle protezioni.
• Tempo di implementazione: ore-giorni-settimane.
• Familiarità del team: quanto già si sa, quanto bisogna imparare.
• Costo a regime: licenze, hosting, modello AI.
• Reversibilità: quanto costa cambiare in futuro.

Una buona presentazione di alternative include almeno 3-4 di questi assi per ogni opzione, con valori (alto/medio/basso) e motivazione.

Procedura pratica

Per decidere bene:

1. Decidi se richiedere alternative: criticità della scelta giustifica?
2. Prompt esplicito: 3 alternative, NO codice, trade-off su 4 assi rilevanti.
3. Leggi: cerca contraddizioni interne (“alternativa B è più semplice E più completa” — sospetto).
4. Valuta su criteri tuoi: quali assi contano per il tuo progetto? Spesso reversibilità + tempo + familiarità.
5. Decidi e motiva: scrivi la decisione con motivo nel decision log.
6. Solo dopo: implementa. Prompt successivo è “implementa l’alternativa B, motivo Y”.

Laboratorio guidato

Caso reale: devi aggiungere ricerca full-text su lista di articoli (1000-10000 articoli, single-server, app interna).

Senza alternative: chiedi “implementa ricerca”. Modello propone Postgres to_tsvector + GIN index. Implementi, vai avanti.

Con alternative (prompt sotto). Modello propone:

Opzione A — Postgres full-text search nativo:

• Trade-off: semplicità alta (DB già esistente), performance buona fino a 100K articoli, reversibilità alta, costo zero, familiarità alta.
• Limiti: italiano richiede config dedicata, ranking meno fine di motori dedicati.

Opzione B — Meilisearch / Typesense self-hosted:

• Trade-off: performance ottima, ranking sofisticato, sintassi friendly. Costo: nuovo servizio da gestire (deploy, backup), dipendenza extra. Reversibilità media. Familiarità: bassa.

Opzione C — Postgres + extension pg_trgm + similarity:

• Trade-off: tollera errori di battitura, semplicità media. Performance media. Familiarità: bassa per la extension. Costo zero (Postgres).

Decisione (mio caso): A. Motivo: scala (1K-10K articoli) gestita bene, zero servizi nuovi, reversibilità alta. Considerare B se cresce sopra 100K e search diventa feature centrale.

Questa decisione è motivata. Fra sei mesi rileggendo decision log, capisco perché. Senza alternative, avrei avuto solo “ho usato Postgres FTS perché il modello l’ha proposto”.

Output atteso

Per le 3-5 prossime decisioni significative del tuo progetto, una scheda decisione con:

• decisione presa;
• 2-3 alternative considerate;
• trade-off su 4 assi rilevanti per ognuna;
• motivazione della scelta;
• condizione di “rivedere la scelta” (es. “se traffico > X”).

Salvate in decisions.md.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: costringere l’AI a rendere visibili le scelte tecniche invece di presentare una sola risposta come inevitabile. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Alternative per architettura, dipendenze, modellazione dati, UI, test e gestione errori.
• Trade-off reali: semplicità, performance, manutenzione, sicurezza, tempo, familiarità del team.
• Come valutare alternative: criteri espliciti, rischi, reversibilità, costo di migrazione.

3. Applicazione: svolgi il laboratorio: chiedere tre soluzioni per la stessa feature e scegliere una motivando il criterio principale. L’output da ottenere è: un template per richiedere alternative confrontabili e non solo codice.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• chiedo alternative per scelte non triviali (irreversibili, costose, incerte);
• so quali assi di trade-off contano per il mio progetto;
• non accetto la prima soluzione del modello senza domande, su scelte rilevanti;
• ho una scheda decisione per le ultime 3 scelte importanti.

Errori comuni

Chiedere alternative per ogni cosa. Paralisi. Per task piccoli, accetta e vai.

Alternative finte. Modello propone “REST vs REST con HATEOAS” come due opzioni distinte. Sono varianti dello stesso, non alternative. Chiedi opzioni davvero diverse.

Trade-off generici. “Più scalabile, più performante” senza numeri o contesto. Chiedi specifico per il tuo caso.

Decisione senza motivazione. Scegli e dimentichi perché. Sei mesi dopo non sai. Decision log con motivazione.

Non consider rivedere. Una decisione non è per sempre. Condizioni cambiano. Marca “quando rivedere”.

Chiedere 7-8 alternative. Troppo. 3 ben caratterizzate sono più utili di 8 superficiali.

Prompt di lavoro

Sto decidendo come implementare: [descrizione scelta]

Contesto del progetto:
- stack: [...]
- scala: [...]
- vincoli rigidi: [...]
- familiarità del team: [...]
- reversibilità desiderata: [alta / media / bassa]

Voglio 3 alternative tecniche genuinamente diverse (non varianti).

Per ognuna, fornisci:
1. Nome e descrizione in 2 righe.
2. Trade-off su 4 assi rilevanti per il mio caso (es. semplicità, performance, manutenzione, costo, tempo, familiarità, reversibilità — scegli i 4 più pertinenti). Valori: alto / medio / basso, con motivazione di 1 riga.
3. Caso ideale: in quali condizioni questa alternativa è chiaramente la migliore.
4. Caso peggiore: in quali condizioni va male.

NON scrivere codice in questa risposta.

Concludi con:
- raccomandazione esplicita per il MIO caso
- condizione che farebbe rivedere la scelta in futuro

Esercizio finale

Apri il decision log del tuo progetto (se non c’è, creane uno per le ultime 3 decisioni). Per ognuna delle ultime 3 decisioni significative, ricostruisci a posteriori: quali alternative avevi considerato? Se la risposta è “nessuna” o “quella che ha proposto il modello”, quella decisione era delegata, non presa. Dalla prossima volta in poi, rendila visibile prima di accettare.