Come lavoro
Su questa pagina c'è il metodo, non la lista delle tecnologie. Come si passa da un problema operativo a un sistema che funziona ogni giorno in mano alle persone che lo usano. L'IA è dentro questo metodo, come motore — non come scorciatoia.
01 Il metodo
Sei passi, sempre nello stesso ordine.
-
Il problema reale
Parto da un problema concreto, non dalla teoria completa: una pompa che non riparte, un foglio di calcolo che genera errori. Da lì, e non da uno schema astratto.
-
La lettura integrale
Quando qualcosa si rompe e i fix rapidi falliscono uno dopo l'altro, smetto di indovinare. Leggo tutto — codice, manuale, librerie — fino alla causa vera. Su un progetto esterno ha voluto dire oltre trentamila righe lette e cinque bug strutturali che nessuno aveva visto. La regola è netta: dopo due fix falliti di fila, ci si ferma e si legge.
-
Il brainstorming
Prima di scrivere codice per un lavoro non banale, esploro: il problema vero, le alternative, i vincoli. Meglio scartare una strada sulla carta che a metà implementazione.
-
La specifica
Fisso le decisioni in una specifica e in brevi note di decisione: cosa costruisco, perché, quali alternative ho scartato, quali compromessi accetto. Tra sei mesi quelle note spiegano il «perché» meglio della memoria.
-
Costruisco e itero
Una versione minima che funziona, poi itero su quella. E se sul campo una scelta elegante diventa ingestibile, la semplifico: ho già tolto funzioni «belle» perché complicavano la manutenzione.
-
Verifico
Test automatici, screenshot, e per l'hardware un banco di prova prima del campo. Un sistema non è «fatto» finché non l'ho visto reggere in condizioni reali.
02 L'IA come motore
Prima l'ingegnere, poi l'IA — sempre in quest'ordine. L'IA non sostituisce il metodo: lo amplifica. Ogni progetto raccontato in questo portfolio nasce così, con il mio metodo, la mia esperienza e l'IA come parte degli strumenti.
Soprattutto, non delego all'IA la comprensione tecnica. Arrivo con i test già fatti, le ipotesi precise, i dettagli concreti: l'IA accelera l'esecuzione, non sostituisce il capire. È la differenza che si vede quando un sistema deve reggere davvero — quando la pompa non riparte alle due di notte, c'è da leggere il firmware riga per riga, non da rigenerare una demo.
In concreto vuol dire un ambiente di lavoro costruito su misura: ogni decisione tecnica finisce in una nota di decisione, ogni sessione in un registro, così il contesto non si perde tra un giorno e l'altro. Le abitudini che mi tengono disciplinato — la lettura integrale, la regola dei due fix, i controlli automatici di qualità — sono codificate negli strumenti, non lasciate alla memoria.
Quello che non troverai qui: vanti sul numero di token o sul nome del modello del mese. Lo strumento è il motore, non il trofeo. La prova è il lavoro — cinque case study, ognuno con un capitolo «come l'ho costruito».
03 Il metodo applicato
Il metodo si capisce meglio applicato che descritto. Ognuno dei cinque case study ha un capitolo dedicato a come l'ho costruito — il problema, le decisioni, i compromessi.