Da codice scritto a codice generato: cosa cambia davvero

Questa lezione apre il modulo Che cos’è davvero il Vibe Coding. Prima di parlare di strumenti, prompt o framework, serve riconoscere che cambia il rapporto fra programmatore e codice. Non sparisce il lavoro: si sposta. Da scrivere righe a dirigere un sistema che le scrive al posto tuo, e che ha bisogno di intenzione, contesto e verifica per produrre qualcosa di utile.

Perché questa lezione conta

Quando un modello generativo entra nel tuo flusso, la velocità di produzione aumenta di un ordine di grandezza. Ma la velocità non è qualità: è soltanto velocità. Senza una griglia di lettura, finisci con una codebase ampia che nessuno (te incluso) capisce davvero. Questa lezione costruisce la griglia minima: cosa cambia, dove resta la responsabilità umana, perché serve un metodo prima di un prompt.

Obiettivo operativo

Alla fine devi saper:

1. distinguere fra “scrivere codice” e “ottenere codice” come due attività diverse, con costi e rischi diversi;
2. nominare almeno tre responsabilità che restano umane anche quando l’AI scrive il 90% delle righe;
3. spiegare perché la velocità di generazione, senza verifica, accelera il debito tecnico invece di ridurlo.

Nucleo della lezione

1. Scrivere istruzioni vs descrivere un risultato atteso

Scrivere codice è imperativo: indichi al computer ogni passo. Descrivere un risultato a un modello generativo è dichiarativo: dichiari cosa vuoi e lasci che il modello scelga il come. La differenza pratica è il livello di controllo. Nel codice scritto, ogni riga è una decisione esplicita; nel codice generato, la decisione è nascosta dietro una richiesta in linguaggio naturale, e il modello riempie i vuoti con assunzioni proprie.

Conseguenza concreta: una richiesta vaga (“fai un form di login”) produce un risultato plausibile ma non controllato. Validazione lato client invece che server, password salvate in chiaro, sessioni gestite con localStorage: tutte scelte che il modello prende per te se non le esplicite. Il vibe coding richiede di essere precisi proprio dove l’imperativo non lo richiedeva, perché lì il compilatore avrebbe protetto te dalle ambiguità.

2. Nuove responsabilità del programmatore

Cinque responsabilità si spostano in primo piano:

• Intenzione: cosa stai costruendo, per chi, con quale criterio di successo. Senza intenzione esplicita, il modello produce qualcosa di generico.
• Contesto: quali file, quali vincoli, quale stack, quali convenzioni esistono già. Il modello non legge la tua mente né ricorda la conversazione di ieri.
• Vincoli: ciò che NON deve cambiare (sicurezza, dipendenze, file fuori scope, performance minima). I vincoli proteggono dalle modifiche laterali.
• Revisione del diff: leggere riga per riga la modifica concreta. Non la spiegazione del modello, non l’output testuale: il diff sul filesystem.
• Accettazione consapevole: scegliere se accettare, modificare o rifiutare. Premere “applica” senza aver letto è delega cieca, non collaborazione.

Le prime tre si fanno prima della generazione, le ultime due dopo. Nessuna è automatizzabile.

3. Velocità di generazione e debito tecnico

Un modello produce 200 righe in 10 secondi. Le leggi davvero in 10 secondi? No: ti servono 5 minuti. Il rapporto generazione/comprensione è asimmetrico, e diventa peggio man mano che la codebase cresce. Codice non compreso = decisioni opache. Decisioni opache = bug futuri costosi e refactor difficili.

Il rischio non è il singolo errore: è l’accumulo. Dieci file generati in un’ora, ognuno “funzionante”, possono contenere venti scelte architetturali contraddittorie. Quando arriva il primo bug serio, scoprire perché il sistema fa quello che fa diventa un’archeologia. Antidoto: limitare la dimensione delle generazioni (un comportamento per volta), commit piccoli, lettura del diff prima del prossimo passo.

Procedura pratica

Sequenza riutilizzabile per ogni task:

1. Scrivi il problema in una frase prima di aprire la chat. Cosa, per chi, vincolo principale.
2. Chiedi un piano, non codice. Lista di passi + assunzioni del modello. Correggi assunzioni sbagliate.
3. Autorizza il primo passo, non l’intera implementazione. Stop alla fine del passo per leggere il diff.
4. Verifica concreta: esegui, testa, leggi log. Non fidarti della frase “ho aggiornato il file”.
5. Commit + decisione: se il passo regge, salva e procedi. Se no, ripristina e riformula.

Laboratorio guidato

Prendi una funzionalità piccola (es: contatore con pulsante incrementa/decrementa, o validatore di email). Implementala due volte:

Round 1 — manuale. Scrivi tu il codice. Cronometra. Annota: quante decisioni hai preso (struttura file, nomi, gestione edge case, stile)?

Round 2 — generato. Apri chat, scrivi una richiesta breve, accetta il primo output. Cronometra. Conta: quante decisioni ha preso il modello al posto tuo? Quante avresti preso diversamente?

Confronta i due risultati su tre assi: tempo, controllo, comprensione del risultato.

Output atteso

Una scheda di confronto a tre colonne:

• Cosa l’AI ha accelerato: parti meccaniche, boilerplate, casi noti.
• Cosa ha reso ambiguo: scelte implicite, dipendenze non chieste, convenzioni inventate.
• Cosa richiede lettura umana: sicurezza, edge case, integrazione con resto del sistema.

Una pagina, riusabile come punto di riferimento durante il corso.

Studio passo passo

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

1. Prima lettura: chiarisci l’obiettivo: capire che il lavoro non scompare: si sposta dalla digitazione alla direzione tecnica, alla verifica e alla qualità delle decisioni. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Differenza tra scrivere istruzioni direttamente e descrivere un risultato atteso a un modello generativo.
• Nuove responsabilità del programmatore: intenzione, contesto, vincoli, revisione del diff e accettazione consapevole.
• Perché la velocità di generazione aumenta anche il rischio di accumulare codice non compreso.

3. Applicazione: svolgi il laboratorio: prendere una piccola funzionalità, descriverla prima a parole e poi confrontare il risultato generato con una soluzione scritta manualmente. L’output da ottenere è: una scheda di confronto con cosa l’AI ha accelerato, cosa ha reso ambiguo e quali parti richiedono lettura umana.

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 spiegare cosa significa “il lavoro si sposta” senza usare slogan;
• so nominare almeno tre cose che il modello NON fa al posto mio;
• ho un esempio concreto in cui un output plausibile conteneva un errore reale;
• ho deciso, per il prossimo task, dove fermare la generazione per leggere.

Errori comuni

Confondere fluidità con correttezza. Una risposta scritta bene non è un codice giusto. Un modello scrive sempre con sicurezza, anche quando inventa.

Saltare il piano. Andare direttamente al codice fa risparmiare 30 secondi e fa perdere 2 ore di debug. Il piano è dove correggi il modello a costo zero.

Accettare modifiche fuori scope. “Già che c’ero ho rinominato anche X” è il modo in cui un task da 10 minuti diventa un refactor non richiesto.

Trattare l’AI come un junior. Un junior impara fra una richiesta e l’altra. Il modello no: dimentica appena chiudi la chat. Devi essere tu la memoria del progetto.

Prompt di lavoro

Sto iniziando una piccola feature: [descrizione in una frase].
Stack: [linguaggio/framework]. Vincoli: [cosa non toccare].

Prima di scrivere codice, dammi:
1. assunzioni che stai facendo (almeno 3);
2. piano in passi numerati, ognuno verificabile;
3. cosa NON farai senza che te lo chieda esplicitamente;
4. criterio di "fatto" per ogni passo.

Non produrre codice in questa risposta.

Esercizio finale

Riguarda i tuoi ultimi tre task fatti con AI (o, se non ne hai, tre prompt che useresti domani). Per ciascuno rispondi: qual era l’intenzione esplicita? Quali vincoli avevo dichiarato? Ho letto il diff o solo l’output testuale? Se la risposta è “non ricordo” o “no”, quella è la lezione che ti serve interiorizzare prima di passare al modulo 2.