3 Cose che (Quasi) Nessuno Fa

Siamo a febbraio 2026. Il termine "vibe coding" è stato coniato un anno fa. L'agent coding esiste da poco più di un anno.

Un anno.

Questo significa una cosa importante: quasi nessuno sa ancora usarlo bene. Non perché sia difficile — ma perché è nuovo. Non c'è una generazione di developer esperti da cui imparare. Non ci sono best practice consolidate. Siamo tutti pionieri che scoprono strada facendo.

L'agent coding non è un bottone che premi e funziona. È una skill. Va masterata. Richiede mesi di pratica, errori, aggiustamenti. E la maggior parte dei developer è ancora all'inizio di questo percorso.

Questo blog esiste per accelerare quel percorso. Per condividere quello che funziona e quello che no.

Queste tre abitudini? Sono tra le prime cose che ho scoperto fare la differenza. Semplici. Controintuitive. Che quasi nessuno fa.

1. Parla. Non Scrivere.

Questa è la cosa più ovvia e meno praticata.

Gli agenti non hanno bisogno che tu scriva. Hanno bisogno di testo. E il testo può arrivare dalla tua voce.

Perché nessuno lo fa

C'è un bias strano contro il parlare. Siamo developer. Scriviamo codice. Scriviamo prompt. Parlare sembra... sbagliato? Poco professionale? Strano se sei in ufficio?

Ma pensa a cosa succede quando scrivi: editi, cancelli, riformuli, cerchi la parola giusta, ti autocensuri prima ancora di finire il pensiero.

Ogni prompt scritto è una versione compressa e filtrata di quello che volevi dire.

Quando parli, pensi ad alta voce. Il flusso è diverso. Più naturale. Più completo.

I miei prompt vocali sono sempre più lunghi e più dettagliati di quelli scritti. Non perché mi sforzi — anzi, è il contrario. Parlare richiede meno sforzo che scrivere. E il contesto extra che aggiungo "senza pensarci" spesso è esattamente quello che serve all'agente per capire cosa voglio.

L'esempio pratico

Guarda la differenza. Stesso task, due approcci.

Prompt scritto tipico:

Aggiungi validazione al form di login

Risultato: l'agente fa assunzioni. Magari usa una libreria che non hai. Magari valida in modo diverso da come vuoi. Devi correggere, iterare, perdere tempo.

Prompt parlato (trascritto):

Ok allora, ho questo form di login che funziona ma non ha validazione.
L'email deve essere una email valida, la password almeno 8 caratteri
con un numero. Ah, e mostra gli errori sotto ogni campo, in rosso,
solo dopo che l'utente ha provato a submittare. Usiamo già Zod nel
progetto quindi usa quello.

Risultato: l'agente ha tutto. Fa il lavoro giusto al primo colpo.

La differenza? Il secondo prompt ha contesto, specifiche, UX, stack tecnico. Tutto questo esce naturalmente quando parli. Quando scrivi, ti sembra "troppo lungo" e tagli.

Prova tu stesso

Sentiti libero di sperimentare la differenza.

Prendi lo stesso task e fallo due volte: una scritta, una parlata. Puoi farlo su due branch diverse così non rovini quello che stai facendo. Poi confronta i risultati.

Il trucco per parlare bene all'agente? Immaginati il tuo nuovo collega junior, appena entrato. Devi spiegargli cosa fare, ma non hai voglia di tornare lì a rispiegarglielo tre volte. Quindi gli dai tutto: il contesto, i dettagli, le eccezioni, lo stack che usate.

Ecco. Parla all'agente così.

Non perché l'agente sia più intelligente quando parli. Perché tu gli dai più contesto, più velocemente, con meno sforzo. E non devi tornare a rispiegare.

I tool per farlo

Non hai bisogno di nulla di speciale. Hai già tutto.

Su Windows: Premi Win + H e inizia a parlare. È la dettatura integrata nel sistema, gratuita, funziona ovunque. Non è perfetta, ma è più che sufficiente per i prompt.

Su Mac: Premi due volte il tasto Fn (o Ctrl + Cmd + D nelle versioni precedenti). Stessa cosa: dettatura di sistema, gratuita, integrata.

Questi tool di accessibilità esistono da anni. Quasi nessuno li usa per programmare.

Se vuoi qualcosa di più potente, ci sono tool dedicati. Io uso Wispr Flow — è a pagamento, ma la qualità di trascrizione è superiore e funziona ovunque sul sistema. Ci sono alternative gratuite e open source, ma per l'uso quotidiano intensivo, un buon tool a pagamento si ripaga in tempo risparmiato.

Il punto non è quale tool usi. Il punto è che inizi a parlare invece di scrivere.

Non stai dettando una lettera. Stai scaricando un'architettura mentale. Non preoccuparti della grammatica — l'agente pulirà il rumore. Preoccupati del segnale.

I primi giorni ti sembrerà strano. Poi non tornerai più indietro.

2. Non È un Essere Umano. Smettila di Trattarlo Come Tale.

Questa è sottile ma importante. E ha due facce.

Gli insulti

Ho visto di tutto. Developer che scrivono cose che non ripeterei neanche censurate. "Sei un co di ia", "Ma quanto c*o sei stupido", "F*****o te e chi ti ha programmato".

L'agente non si offende. Non può offendersi. Ma tu stai sprecando token di contesto con contenuto emotivo che non aggiunge nulla. Quel prompt pieno di rabbia occupa spazio che potresti usare per spiegare cosa è sbagliato e come vuoi che venga corretto.

E c'è un effetto collaterale: quando sei frustrato, i tuoi prompt diventano vaghi. "Rifallo bene questa volta" non dice nulla. L'agente non sa cosa intendi per "bene". Risultato: altro output sbagliato, altra frustrazione, spirale negativa.

"Il mio codice è meglio"

L'altra trappola è la competizione. Soprattutto tra developer senior.

"Questo codice fa schifo, io l'avrei scritto meglio." Ok. Ma l'hai scritto tu il prompt? Perché se hai scritto tre parole e ti aspettavi cinque pagine di codice perfetto, il problema non è l'agente. È il tuo prompt.

Non siamo più nel mondo del single-shot. Il prompt engineering "scrivo una frase perfetta e ottengo il risultato perfetto" non esiste nell'agent coding. Questo è un processo. Un'iterazione. Dai contesto, vedi l'output, correggi, iteri.

Se dopo tre iterazioni non arrivi al risultato, la domanda non è "perché l'agente è stupido?" La domanda è: "cosa non sto comunicando bene?"

È collegato al punto 1: se parli, dai più contesto. Se dai più contesto, l'output è migliore. Se scrivi tre parole, non lamentarti che l'output non è quello che volevi.

Il mindset giusto

L'agente è uno strumento. Non si offende se lo insulti, e non ha bisogno che tu sia gentile. Ma funziona meglio se gli dai istruzioni chiare.

Dall'altro lato, scusarsi è inutile. "Scusa se ti disturbo ancora, ma potresti gentilmente..." è rumore. L'agente non ha bisogno di convenevoli.

Il tuo lavoro è dare istruzioni chiare, specifiche, con il contesto necessario. Niente di più, niente di meno.

E se non funziona? Itera. Cambia approccio. Dai più contesto. Ma non dare la colpa allo strumento.

3. Sbaglia. Tanto. Di Proposito.

Questa è la più controintuitiva.

La maggior parte dei developer tratta l'agent coding come un esame. Devi fare il prompt giusto al primo colpo. Se sbagli, hai perso.

È l'approccio sbagliato.

Perché gli errori sono preziosi

Ogni errore ti insegna qualcosa sui limiti dell'agente. Ti insegna come pensa (o non pensa). Ti insegna cosa funziona e cosa no.

Ho imparato più sull'agent coding dai prompt falliti che da quelli riusciti. Perché il fallimento ti costringe ad analizzare: cosa è andato storto? Come posso riformulare? Cosa mancava nel mio contesto?

L'esperimento che dovresti fare

Prendi un'ora. Un'ora dedicata a rompere cose.

Chiedi all'agente cose impossibili. Chiedi cose vaghe. Chiedi cose contraddittorie. Chiedi senza contesto. Chiedi con troppo contesto.

Guarda cosa succede. Non per ottenere output utile — per capire i pattern di fallimento.

Alcune cose che ho scoperto così:

• Se chiedi qualcosa di troppo vago, l'agente fa assunzioni. Spesso sbagliate.
• Se chiedi qualcosa di contraddittorio, a volte lo nota, a volte no.
• Se il contesto è troppo lungo, perde pezzi. Ha priorità implicite.
• Se chiedi "miglioralo" senza dire come, fa cambiamenti random.

Queste sono informazioni preziose. Non le trovi nei tutorial. Le trovi sbagliando.

Il costo dell'errore è basso

Questo è il punto chiave: sbagliare costa poco.

Un prompt fallito ti costa qualche secondo e qualche centesimo di API. Non rompe nulla. Non offende nessuno. Non finisce nel tuo git history (a meno che tu non faccia commit senza guardare — e quello è un altro problema).

Confrontalo con il costo di non sperimentare: mesi di utilizzo subottimale, prompt inefficienti, frustrazione accumulata.

L'approccio iterativo

I developer migliori con l'agent coding non sono quelli che fanno prompt perfetti. Sono quelli che iterano velocemente.

Primo prompt: vago, veloce, per vedere dove va. Secondo prompt: correggo la direzione in base all'output. Terzo prompt: affino i dettagli.

È come scolpire. Non parti dal dettaglio. Parti dalla forma grezza e affini.

Questo approccio richiede che tu sia a tuo agio con l'errore. Che lo veda come parte del processo, non come fallimento.

Il Pattern Comune

Hai notato cosa hanno in comune queste tre abitudini?

Tutte richiedono di lasciare andare qualcosa:

• Lasciare andare il perfezionismo del prompt scritto → parla
• Lasciare andare l'antropomorfizzazione → trattalo come strumento
• Lasciare andare la paura di sbagliare → sperimenta

L'agent coding è uno skill. Come tutti gli skill, si sviluppa con la pratica. Ma la pratica efficace richiede un mindset diverso da quello che la maggior parte dei developer porta.

Non sei a scuola. Non c'è un voto. L'unica metrica che conta è: stai ottenendo quello che ti serve?

Se sì, continua. Se no, cambia approccio.

Queste tre abitudini sono il punto di partenza.

Bonus: Le Allucinazioni Non Sono (Solo) un Problema

Tutti ne parlano come di un difetto. "L'AI allucina", "inventa cose", "non ci si può fidare".

Ma aspetta un attimo.

Gli LLM navigano in uno spazio vettoriale multidimensionale. Uno spazio che noi umani non riusciamo nemmeno a visualizzare — il nostro cervello si ferma a tre dimensioni, forse quattro se ci sforziamo. Quando l'agente "allucina", sta esplorando connessioni in quello spazio che noi non vedremmo mai.

E a volte, quelle connessioni sono oro.

Nella fase creativa — planning, brainstorming, esplorazione — chiedere cose che oggi non esistono può aprire strade nuove. L'agente può combinare concetti in modi che a te non verrebbero in mente. Può suggerire approcci che sembrano assurdi ma che, guardandoli meglio, hanno senso.

Nella fase di esecuzione — scrivere codice, implementare, deployare — le allucinazioni sono pericolose. Qui vuoi precisione, non creatività.

L'allucinazione è un eccellente architetto visionario, ma un pessimo ingegnere strutturale.

Il problema non è l'allucinazione in sé. Il problema è prendere tutto per buono senza verificare. Ma quello è lo stesso problema di un prompt fatto male che dà output sbagliato: non è colpa dello strumento, è colpa di come lo usi.

Se verifichi, se controlli, se usi il tuo giudizio — le allucinazioni diventano esplorazioni. Un modo per vedere connessioni che il tuo cervello tridimensionale non può fare.

Non trattarle solo come bug. Nella fase giusta, sono feature.

Prossimi Passi

Prova una di queste tre cose oggi. Solo una. Per una settimana.

Poi passa alla prossima.

Non devi cambiare tutto insieme. Devi cambiare abbastanza da vedere la differenza.

La differenza la vedrai.