Gli strumenti, e perché contano meno di quanto sembri

Dal campo

Una settimana persa a confrontare strumenti. Video su quale assistente scrive meglio il codice, confronti fra tecnologie, discussioni su quale sia la scelta giusta per iniziare. Alla fine della settimana: nessuna riga scritta e la sensazione di essere ancora impreparato.

È la trappola più prevedibile di tutte. Ha una ragione psicologica precisa: confrontare strumenti è comodo, perché somiglia al lavoro senza esporre a nessun fallimento. Costruire espone.

La verità sgradevole è che per una prima versione la scelta degli strumenti conta poco: quasi ogni combinazione ragionevole ti porta in fondo.

Cosa serve, in minimo

Un assistente che scrive codice dentro il tuo progetto. Non una chat in cui copi e incolli: uno strumento che vede i file, li modifica e può eseguire i comandi. La differenza è sostanziale. Con il copia e incolla passi il tempo a fare da postino fra due finestre e a introdurre errori nel trasporto. Con un assistente che lavora nella cartella, chiedi una cosa e la trovi fatta.

Gli esempi di questo laboratorio usano Claude Code, che lavora dal terminale dentro la cartella del progetto. Gli strumenti equivalenti degli altri fornitori funzionano allo stesso modo: cambiano i comandi e l’aspetto, non il metodo.

Un posto dove tenere il progetto. Una cartella sul tuo computer e la sua copia su un servizio come GitHub. Non è un vezzo da professionisti, ma l’unica assicurazione contro il momento in cui qualcosa si romperà in modo irreparabile e vorrai tornare a com’era ieri. Quel momento arriva sempre.

Un posto dove pubblicare. Se ne parla nel terzo modulo. Per ora basta sapere che esiste e che costa poco o niente per un progetto piccolo.

Nient’altro. Nessun corso di programmazione preliminare, nessun ambiente complicato da preparare.

La scelta che conta: lasciar decidere, ma capire

C’è una decisione tecnica che non puoi evitare: con quali tecnologie sarà costruita la cosa. La buona notizia è che puoi delegarla. Quella meno buona è che non puoi delegarla in silenzio.

Il modo giusto di delegarla è chiedere all’assistente di proporre e motivare, dicendogli i vincoli che conosci: quanto ti aspetti che costi tenerla accesa, quanto sei disposto a occupartene, se ci sono dati di persone dentro. Poi leggere la motivazione e capirla. Basta capire cosa comporta per te.

Le domande da fare sono sempre le stesse tre: quanto costa tenerla accesa ogni mese, cosa succede se un giorno voglio spostarla altrove e quanto è diffusa questa scelta. L’ultima conta più di quanto sembri: su una tecnologia molto usata l’assistente ha visto milioni di esempi e sbaglia meno.

Il criterio finale, se resti indeciso fra due opzioni: prendi la più noiosa. La noia, in questo campo, è sinonimo di collaudato.

Il costo, prima di cominciare

Vale la pena guardarlo subito, perché è l’unica sorpresa spiacevole ricorrente.

L’abbonamento all’assistente è la voce principale: per un uso serio, a settembre 2026, sta nell’ordine delle decine di euro al mese. Pubblicare un progetto piccolo costa poco o nulla: quasi tutti i servizi hanno un livello gratuito che basta ampiamente finché nessuno lo usa. Il dominio, se lo vuoi, sono poche decine di euro l’anno.

La voce che sfugge è quella che cresce con l’uso: alcuni servizi si pagano a consumo. Un errore in una parte che gira in continuazione può produrre un conto sgradevole. Prima di pubblicare qualcosa che resta acceso, la domanda da fare all’assistente è esplicita: cosa in questo progetto si paga a consumo e cosa succede se qualcuno lo usa mille volte in un’ora.

Quando ti accorgi di aver scelto male

Succede. Non è grave quanto sembra. Il segnale non è tecnico. Ti trovi a chiedere all’assistente sempre le stesse correzioni, o che ogni piccolo cambiamento ne rompe un altro.

A quel punto la mossa giusta non è ricominciare da zero. È chiedere all’assistente di spiegarti cosa sta creando l’attrito e valutare se cambiare quel pezzo. Avendo la specifica scritta, ricostruire una parte è un lavoro di ore, non di settimane: è la seconda ragione per cui quel documento vale più del codice.

Al lavoro con l’AI

Da eseguire con la specifica già nel progetto, prima di far scrivere qualunque riga di codice.

«Ti allego la specifica del progetto. Proponimi due combinazioni di tecnologie per costruirlo, senza scrivere codice. Per ciascuna dimmi: quanto costa tenerla accesa al mese con pochi utenti, cosa si paga a consumo e cosa a canone fisso, quanto è diffusa (cioè quanti esempi esistono là fuori), cosa comporta spostare il progetto altrove fra un anno. Alla fine consigliami quella che sceglieresti per una persona che non programma e che deve mantenerla da sola. Spiegami perché in cinque righe senza termini tecnici.»

Errori comuni

• Confrontare strumenti invece di cominciare: è la forma di rinvio più credibile che esista, perché somiglia al lavoro.
• Usare una chat con copia e incolla al posto di un assistente che lavora nella cartella: la maggior parte degli errori nasce nel trasporto fra le due finestre.
• Non mettere il progetto sotto controllo di versione dal primo giorno: il momento in cui servirà tornare indietro arriva sempre. Senza copia non si torna.
• Delegare la scelta tecnica senza leggerne la motivazione: non devi saperla valutare, devi sapere cosa ti costa e cosa ti vincola.
• Ignorare cosa si paga a consumo: è l’unica voce che può produrre un conto inatteso: si chiede prima di pubblicare, non dopo.

Checklist operativa

• Attiva un assistente che lavora dentro la cartella del progetto, non una chat da copia e incolla.
• Crea la cartella del progetto e mettila sotto controllo di versione con una copia remota.
• Fatti proporre due combinazioni di tecnologie con costi, diffusione e vincoli. Scegli la più noiosa.
• Chiedi esplicitamente cosa si paga a consumo e cosa succede con mille usi in un’ora.
• Annota nella specifica la scelta fatta e la ragione, in cinque righe.