modulo 02 / lezione 06
Strumenti del vibe coder
Chat generaliste: forza e limiti
Usare una chat AI come spazio di ragionamento senza confonderla con un ambiente di sviluppo completo.
Chat generaliste: forza e limiti
Una chat (ChatGPT, Claude.ai, Gemini, Mistral) è un’interfaccia conversazionale generica: scrivi testo, ricevi testo. Non legge il filesystem, non esegue comandi, non vede il tuo IDE. Sapere cosa è e cosa non è ti permette di sfruttarla nel suo punto di forza — il ragionamento — senza confonderla con un ambiente di sviluppo che non è.
Perché questa lezione conta
La chat generalista è lo strumento più diffuso, anche fra chi non programma. È potente per esplorare, chiarire, spiegare. Diventa fragile appena entra il contesto del progetto: copia-incolla di file, sincronizzazione fra sessioni, modifiche multi-file. Senza il limite chiaro fra “spazio di ragionamento” e “ambiente di lavoro”, finisci a usarla per task per cui altri strumenti (IDE AI, agenti CLI) sono nettamente migliori.
Obiettivo operativo
Alla fine devi saper:
- nominare 5 task in cui la chat è eccellente e 5 in cui è fragile;
- impostare un prompt da chat con contesto minimo ma sufficiente;
- riconoscere quando uscire dalla chat e passare a IDE AI o agente CLI.
Nucleo della lezione
1. Quando la chat è eccellente
Casi in cui una chat batte qualsiasi altro strumento:
- Chiarire requisiti: idea grezza → specifica strutturata. Conversazione iterativa per far emergere ambiguità.
- Produrre bozze isolate: snippet, query SQL, schema dati, regex, micro-funzione. Output autocontenuto che incolli e adatti.
- Spiegare errori: incollare uno stack trace, ricevere diagnosi e ipotesi di causa.
- Generare esempi pedagogici: codice didattico, varianti, controesempi. Non deve girare nel tuo progetto, deve farti capire un concetto.
- Brainstorming architetturale: tre alternative per modellare X, trade-off, domande aperte.
- Riformulare: trasformare appunti in commit message, README in docs strutturate, errore vago in bug report.
Punto comune: input piccolo, output piccolo, nessuna dipendenza dal filesystem reale.
2. Limiti strutturali
Limiti veri della chat, non risolvibili con prompt migliori:
- Contesto parziale della repo: la chat non vede file. Devi incollare ciò che serve. Se incolli troppo, costa e peggiora qualità; se incolli troppo poco, il modello inventa.
- Copia-incolla fragile: trascrivi codice avanti e indietro. Errori di sincronizzazione (tu modifichi file, chat ha versione vecchia, suggerisce diff inapplicabili).
- Nessuna esecuzione: la chat non esegue test né legge stack trace prodotti dal tuo runtime. Se il modello dice “ho testato” sta mentendo (semplicemente non può).
- Sessioni isolate: ogni nuova chat parte da zero. Memoria persistente esiste in alcuni prodotti ma è limitata e va gestita.
- Costo del contesto lungo: conversazioni di 50 turni perdono attenzione su dettagli iniziali. Il modello dimentica vincoli dichiarati 30 messaggi fa.
Conseguenza: la chat è ottima per blocchi di lavoro brevi, isolati, autocontenuti. È pessima per modifiche cross-file su una codebase reale.
3. Buone pratiche operative
Per sfruttare la chat senza i suoi limiti:
- Fornisci file mirati: non l’intera repo. Solo i 2-3 file rilevanti per la domanda specifica.
- Chiedi assunzioni: “prima di rispondere, lista cosa stai assumendo sul mio stack/versione/contesto”. Le assunzioni sbagliate emergono prima del codice.
- Imponi formato: “rispondi con sezioni: 1) diagnosi, 2) proposta, 3) rischi, 4) verifica”. Output strutturato è più verificabile.
- Separa analisi e codice: prima conversazione di analisi (no codice), poi prompt esplicito per il codice. Mescolare confonde il modello e te.
- Sessioni focali: una chat per task. Apri nuova sessione quando cambi argomento, per non trascinare contesto stale.
Procedura pratica
Workflow per debug di un errore via chat:
- Riproduci localmente. Annota comando, output, ambiente.
- Estrai contesto minimo: stack trace + funzione coinvolta + dipendenze rilevanti. Non l’intera codebase.
- Scrivi prompt strutturato: “comportamento atteso, comportamento osservato, log, ambiente, ultimo cambiamento”. Cinque sezioni.
- Chiedi diagnosi prima del fix: “non scrivere ancora la patch, dammi 3 ipotesi ordinate per probabilità, e cosa controllare per discriminarle”.
- Verifica ipotesi localmente. Ritorna in chat con dato osservato.
- Solo ora chiedi il fix.
Questa procedura sembra lunga; in pratica salva ore quando il bug non è banale.
Laboratorio guidato
Prendi un errore reale del tuo lavoro recente (o simulalo: introduci deliberatamente bug in piccolo progetto). Esegui workflow sopra in chat:
- step 1: riproduci, annota.
- step 2: prepara contesto minimo (no incollare cartelle intere).
- step 3: scrivi prompt strutturato.
- step 4: ricevi diagnosi, NON applicare niente.
- step 5: verifica un’ipotesi, riporta dato.
- step 6: chiedi fix.
Annota: quanto contesto hai incollato? Il modello ha chiesto chiarimenti? Quante iterazioni per arrivare al fix corretto?
Output atteso
Un prompt template per “diagnosi tecnica via chat” con sezioni: comportamento atteso, comportamento osservato, log esatto (quoted verbatim), ambiente (versioni), ultimo cambiamento, vincoli, formato risposta richiesto. Riusabile come blocco di partenza.
Studio passo passo
Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.
- Prima lettura: chiarisci l’obiettivo: usare una chat AI come spazio di ragionamento senza confonderla con un ambiente di sviluppo completo. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
- Seconda lettura: trasforma i contenuti in domande operative:
- Quando la chat è eccellente: chiarire requisiti, produrre bozze, spiegare errori, generare esempi isolati.
- Limiti strutturali: contesto parziale della repo, copia-incolla fragile, difficoltà nel verificare davvero ciò che propone.
- Buone pratiche: fornire file mirati, chiedere assunzioni, imporre formato di risposta, separare analisi e codice.
- Applicazione: svolgi il laboratorio: portare in chat un errore reale o simulato con contesto minimo e iterare fino a una diagnosi verificabile. L’output da ottenere è: un prompt modello per chiedere analisi tecnica a una chat senza farle inventare il contesto mancante.
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
- so quando la chat è la scelta giusta e quando no;
- ho un workflow concreto per debug via chat che non mescola analisi e fix;
- riconosco i sintomi di “contesto perso” (modello che contraddice vincoli iniziali) e so quando aprire nuova sessione;
- non incollo mai più dell’1% di una codebase in chat.
Errori comuni
Incollare l’intera repo. “Più contesto = risposta migliore” è falso oltre una certa soglia. Troppo contesto disperde l’attenzione del modello e costa di più.
Copia-incolla bidirezionale lungo. Modifico file, copio in chat, chat propone diff, incollo, ri-modifico, ri-copio… questo loop è dove gli errori si moltiplicano. Soglia: se sto facendo più di 3 round-trip, passo a IDE AI o agente CLI.
Trattare la chat come compilatore. Se chiedi “questo codice gira?”, la risposta non è una verifica, è una predizione. Solo l’esecuzione locale verifica.
Usare la chat per refactor multi-file. Non vede gli altri file, non sincronizza modifiche, perde vincoli. Per refactor cross-file servono strumenti che leggono e scrivono direttamente.
Conversazioni-fiume. 100 messaggi nella stessa chat su 5 argomenti diversi. Il modello dimentica e contraddice. Una chat per task.
Prompt di lavoro
Sto facendo diagnosi tecnica via chat. NON scrivere codice in questa risposta.
Comportamento atteso:
[cosa dovrebbe succedere]
Comportamento osservato:
[cosa succede realmente]
Log/errore (verbatim, incolla esatto, niente parafrasi):
[INCOLLA QUI IL LOG]
Ambiente:
- linguaggio + versione: [es. Node 20.11]
- framework + versione: [es. Next 14.2]
- OS: [es. macOS 15]
Ultimo cambiamento prima del bug:
[descrizione]
Vincoli (cosa non posso/voglio cambiare):
[es. struttura DB, libreria X]
Voglio:
1. 3 ipotesi di causa, ordinate per probabilità, con motivazione
2. per ogni ipotesi, un comando o controllo per discriminarla
3. NON il fix: prima conferme dei controlli
Formato: sezioni numerate, niente prosa lunga.
Esercizio finale
Riguarda 3 chat recenti che hai avuto con un modello. Per ciascuna: era il task giusto per una chat? Quanto contesto stale hai trascinato fra messaggi? Ci sono stati round-trip copia-incolla che un IDE AI avrebbe risparmiato? La risposta a queste domande ti dice quando stai usando lo strumento sbagliato per default.