本站提供正體中文版。切換到正體中文本站提供简体中文版。切换到简体中文This site is available in English.View in Englishこのサイトには日本語版があります。日本語で表示이 사이트는 한국어로도 제공됩니다.한국어로 보기Diese Website ist auch auf Deutsch verfügbar.Auf Deutsch ansehenEste sitio web también está disponible en español.Ver en españolCe site est également disponible en français.Afficher en françaisEste site também está disponível em português.Ver em portuguêsDeze website is ook beschikbaar in het Nederlands.In het Nederlands bekijkenЭтот сайт также доступен на русском языке.Смотреть на русскомयह वेबसाइट हिन्दी में भी उपलब्ध है।हिन्दी में देखेंهذا الموقع متاح أيضًا باللغة العربية.عرض بالعربيةSitus ini juga tersedia dalam bahasa Indonesia.Lihat dalam bahasa IndonesiaBu site Türkçe olarak da mevcut.Türkçe görüntüleTa strona jest dostępna także po polsku.Wyświetl po polskuTrang web này cũng có phiên bản tiếng Việt.Xem bằng tiếng Việtاین وب‌سایت به فارسی هم در دسترس است.مشاهده به فارسی

Da «basta che giri» a «oso cambiarlo e farlo funzionare»: il diario di un mese di programmazione di un novellino

IA2026.04

Una premessa: non sono un ingegnere del software, e i contenuti di programmazione di cui parlo qui sono in realtà tutti quel cosiddetto Vibe Coding, quello del tipo «vai dove ti porta l’istinto».

Un portatile sulla scrivania mostra del codice; accanto ci sono foglietti adesivi, una piccola lavagna con annotato il flusso delle modifiche, un timer pomodoro, un diario di programmazione scritto a mano e una tazza con un gatto

Ultimamente, per far filare un po’ meglio il lavoro, sto sviluppando da tempo i miei piccoli strumenti. In questi due giorni ho fatto tre cose: ho iniziato a fare backup con Git, ho corretto qualche bug nella logica del programma e ho collegato un nuovo modello di IA.

La parte più difficile non è la sintassi, ma «trasformare ciò che si vuole in codice»

Dopo un mese, la conclusione più grande è questa: la parte più difficile dello scrivere codice non è, in realtà, la sintassi, bensì convertire «che cosa voglio davvero» in «codice concreto».

Per esempio, «correggere un bug» si dice in un attimo, ma prima di metterci davvero le mani bisogna porsi un mucchio di domande:

  • Salvo prima?
  • Apro un nuovo branch?
  • Quando faccio il test? E come lo faccio?
  • Una volta finita la modifica, che cosa vale come «fatto»?
  • Ne approfitto per assegnare un numero di versione?

In realtà nessuna di queste è una questione di programmazione, ma di «abitudini di lavoro». Questo insieme di procedure sarà forse comunissimo nel settore, ma per un principiante della programmazione è, né più né meno, un incubo.

Alcune piccole cose che ho imparato

In questo mese ho imparato alcune piccole cose, che condivido con i principianti come me:

  1. Prima alza lo scudo protettivo, poi mettiti a smanettare. Usando Git per il controllo di versione, anche se combini un disastro, in trenta secondi puoi tornare al passato: rassicurante come un punto di salvataggio in un videogioco.
  2. Fai una cosa sola per volta. Mai e poi mai «già che ci sono, cambio un’altra riga»: è proprio il genere di cosa che farà venire al te futuro una gran voglia di sbattere la testa contro il muro.
  3. Andare piano è normale. Un intero pomeriggio per tirar fuori una sola piccola funzione? Sì, è la quotidianità. Quei tutorial-lampo, per lo più, ti stanno prendendo in giro.
  4. Scrivi appunti per il te futuro. Altrimenti, la prossima volta che torni a guardarlo, penserai che quel programma l’abbia scritto qualcun altro. (Va bene, sì: questo programma l’ha scritto davvero un’IA.)

Da «basta che giri» a «oso cambiarlo e farlo funzionare», ciò che sta nel mezzo sono, probabilmente, proprio queste abitudini di lavoro che sembrano insignificanti eppure vanno colmate una a una.