Quando fermarsi e scrivere a mano

L’AI non è sempre la scelta giusta. A volte 30 righe scritte a mano in 10 minuti sono meglio di 30 minuti di prompt-iterazione-rifiuto. Riconoscere quei momenti non è ammettere sconfitta: è scegliere lo strumento adatto. Il vibe coder maturo alterna AI e mano, con criterio, non per default.

Perché questa lezione conta

Chi inizia con AI tende a usarla per tutto. Risultato: anche task in cui scrivere a mano sarebbe più rapido vengono affrontati come prompt → fix → fix → fix. Sapere quando passare a editor tradizionale (anche solo per 20 minuti) recupera tempo, capisci meglio il codice, e produce risultati più solidi su parti delicate.

Obiettivo operativo

Alla fine devi saper:

1. riconoscere i 5 segnali che indicano “passa a manuale”;
2. usare scrivere a mano come forma di comprensione (non solo di esecuzione);
3. tornare all’AI dopo lavoro manuale, in modo costruttivo (review, edge case, refactor).

Nucleo della lezione

1. I cinque segnali

Dominio molto piccolo: 5-30 righe di codice. Tempo per scriverle: minuti. Tempo per fare prompt + iterare: spesso più. Sotto certa soglia, AI è overhead.

Logica critica: parte del codice dove un errore è costoso (sicurezza, calcolo finanziario, logica di business unica). Vale la lentezza per la consapevolezza.

Bug compreso: hai capito il problema. Sai esattamente cosa cambiare. Prompt per spiegarlo all’AI = più lento del fix diretto. Fai e basta.

Patch di poche righe: condizione invertita, off-by-one, validazione mancante. Cinque righe scritte a mano. Nessun prompt.

AI introduce rumore: dopo 2 tentativi, l’AI propone modifiche più grandi del necessario, refactor laterali, dipendenze nuove. Sintomo: lo strumento non è il giusto per quel task.

Combinazione: 2+ segnali → quasi sempre meglio scrivere a mano.

2. Scrivere a mano come comprensione

Scrivere a mano non è solo “produrre codice”. È processo di comprensione:

• Nominare variabili: scegliere nomi forza a definire cosa rappresentano. Esercizio mentale che AI salta.
• Isolare condizioni: if (x && y) o due if separati? Decisione di leggibilità che dipende dal contesto, fai tu.
• Costruire test mirati: per scrivere test devi capire i casi. AI propone test plausibili, tu costruisci test che riflettono come pensi al problema.
• Notare pattern strani: scrivendo, ti accorgi che la struttura “non torna”. Sintomo che il design ha problema, non solo l’implementazione.

Per parti delicate (auth, validazione critica, calcoli esatti, logica di stato complessa), scrivere a mano costruisce conoscenza che AI non ti dà.

3. Uso sano dell’AI dopo codice manuale

Aver scritto a mano non significa “AI esclusa”. Dopo:

Review: chiedi all’AI di leggere codice e segnalare: edge case mancanti, problemi di sicurezza, naming poco chiaro, alternative più semplici. Output: lista di osservazioni, non riscrittura.

Edge case: “ho coperto questi casi: [lista]. Mancano edge case rilevanti?”. L’AI è ottima a generare edge case.

Refactor mirato: “questa funzione fa X. È leggibile? Si può semplificare senza cambiare comportamento? Se sì, mostra come”. Output: proposte, da valutare.

Spiegazione a memoria futura: “scrivi commento di 3 righe che spieghi PERCHÉ questa funzione è scritta così”. Documentazione per il te del futuro.

Test aggiuntivi: “ecco la funzione + test che ho scritto. Aggiungi 5 test che coprono edge case che non ho considerato”.

Sequenza: scrivi a mano la parte critica → AI fa review → applichi suggerimenti utili (con giudizio). Doppio passaggio, ma codice solido.

Procedura pratica

Per ogni task:

1. Stima rapida: quanti minuti per scrivere a mano? Quanti per AI (prompt + diff + test)?
2. Verifica i 5 segnali: piccolo? critico? bug compreso? patch piccola? AI ha già introdotto rumore?
3. Se scrivi a mano: vai. 10-30 minuti.
4. Dopo che funziona: AI per review, edge case, doc.
5. Commit: stesso processo del workflow AI (branch, commit piccoli).

Soglia di transizione: se sto pensando “lasciamo perdere, scrivo io”, probabilmente il pensiero è giusto. Spesso aspettare un altro messaggio AI è procrastinazione.

Laboratorio guidato

Tre piccoli task, decidi a quale approccio ognuno:

Task A: rinomina total_amount in totalAmount in 1 file. → Mano (refactor banale).

Task B: implementa funzione che dato un array di numeri ritorna media + mediana + deviazione standard. → Mano se conosci formule (10 min). AI se non le conosci (con verifica formule da fonte affidabile).

Task C: aggiungi internazionalizzazione (i18n) all’app, supporto IT/EN, switch user-driven, persistenza scelta. → AI con scope ben definito (task multi-file, codice ripetitivo, libreria standard).

Task D: bug noto: il calcolo del prezzo finale ignora lo sconto in caso di prodotti gratuiti. Hai capito la causa: condizione if (discount > 0) è il problema. → Mano. Cambia in 30 secondi: if (discount > 0 && price > 0) o ristruttura.

Task E: implementa hashing password con argon2 e gestione corretta dei salt. → Mano + verifica documentazione ufficiale + AI per review. Mai AI come unica fonte per crittografia.

Per ogni task tuo prossimo, fai questa domanda prima di aprire chat AI.

Output atteso

Una regola personale di “quando scrivere a mano”:

• task < 30 righe e logica chiara → mano;
• logica critica (sicurezza, calcoli esatti, stato complesso) → mano + AI per review;
• bug compreso, patch piccola → mano;
• AI in loop dopo 2 tentativi → reset + mano;
• altrimenti → AI con scope ristretto.

Studio passo passo

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

1. Prima lettura: chiarisci l’obiettivo: riconoscere i momenti in cui il codice diretto, anche lento, è più sicuro della generazione continua. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Segnali: dominio molto piccolo, logica critica, bug compreso, patch di poche righe, AI che introduce rumore.
• Scrivere a mano come forma di comprensione: nominare variabili, isolare condizioni, costruire test mirati.
• Uso sano dell’AI dopo il codice manuale: review, edge case, refactor, spiegazione a futura memoria.

3. Applicazione: svolgi il laboratorio: risolvere manualmente una funzione breve dopo due tentativi AI non soddisfacenti, poi farla revisionare. L’output da ottenere è: una regola personale per decidere quando passare da generazione a intervento diretto.

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

• ho un esempio recente di task in cui mano è stata più rapida di AI;
• uso AI per review dopo aver scritto a mano parti critiche;
• non riapro AI per task che ho già capito e che richiedono 5 minuti;
• ho scritto manualmente almeno una parte di sicurezza/auth del mio progetto principale.

Errori comuni

AI come default per tutto. Anche per task da 5 minuti scritti a mano. Tempo perso.

Mano per tutto. Opposto. AI è moltiplicatore reale per molte cose. Equilibrio.

Scrivere a mano e non far reviewere. Manca passaggio finale. AI per review è economico, prendilo.

Insistere con AI quando in loop. Già lezione 38. Reset + mano.

Crittografia/sicurezza solo con AI. Domini dove AI può sembrare giusta e essere sbagliata in modi sottili. Sempre verifica ufficiale + review.

Scrivere a mano senza test. Manuale ≠ trasandato. Stessi standard di test.

Prompt di lavoro

Per review post-mano:

Ho scritto a mano questo codice:

[INCOLLA CODICE QUI]

Contesto: [scopo della funzione, vincoli]

Voglio una review focalizzata. NON riscrivere. NON proporre alternativa intera.

Output:
1. Edge case che potrei aver perso (con esempi).
2. Problemi di sicurezza/correttezza (se ce ne sono).
3. Naming o struttura migliorabili (suggerimenti puntuali, max 3).
4. Test aggiuntivi che consiglieresti, con descrizione (no codice ancora).

Severità per ogni punto: blocking / consigliato / nit.

Esercizio finale

Per la prossima settimana, tieni un mini-diario. Per ogni task: hai usato AI, mano, o misto? Tempo stimato vs effettivo? Risultato qualità (1-5)? A fine settimana, identifica i task in cui un altro approccio sarebbe stato meglio. Quel pattern personale (es: “io scrivo a mano i bug che ho già capito; uso AI per i refactor cross-file”) è la tua regola operativa, tarata su come davvero lavori.