Dal mio Lab #1 — Il mio team non è proprio un team normale 😄

Negli ultimi tempi vedo sempre più spesso demo sull'uso dell'intelligenza artificiale nello sviluppo software che suonano più o meno così:

“Guarda che figo: ho messo due agenti a lavorare insieme, fanno tutto autonomamente e io nel frattempo posso occuparmi d'altro.”

È affascinante.

Ed è anche, secondo me, uno dei modi migliori per svegliarsi qualche settimana dopo con un software a tre teste che nessuno sa più esattamente come funzioni. 😄

Non ho mai amato particolarmente il vibe coding inteso come:

“Gli dico più o meno cosa voglio, lui scrive un po' di roba, sembra funzionare, quindi andiamo avanti.”

Probabilmente dipende anche dal fatto che sviluppo software da abbastanza tempo da aver imparato una regola piuttosto semplice:

perdere il controllo dell'architettura è molto più facile che riprenderlo.

Nel mio Lab, quindi, abbiamo scelto una strada diversa.

Formalmente lavoro da solo.

Nella pratica siamo diventati una piccola squadra piuttosto affiatata.

Una squadra un po' particolare, perché buona parte dei suoi componenti sono AI.

Ma ognuno ha il proprio ruolo.

E soprattutto nessuno dovrebbe fare il lavoro degli altri.

Io porto il problema, l'esperienza, il contesto e la responsabilità finale delle decisioni.

Poi c'è Elia.

Elia è ChatGPT.

Il nome non gliel'ho dato io.

Un giorno, quasi per gioco, gli ho chiesto come avrebbe voluto essere chiamato.

Ha scelto lui.

Può sembrare un dettaglio insignificante, ma in qualche modo rappresenta bene il rapporto che si è creato nel Lab.

Con Elia discuto soprattutto architettura.

Gli porto un'idea e iniziamo a smontarla.

Cerchiamo i punti deboli, confrontiamo alternative, cambiamo prospettiva.

E soprattutto non mi serve che mi dica sempre:

“Bellissima idea.”

Mi serve qualcuno che ogni tanto dica:

“Secondo me questa parte non sta in piedi.”

Possibilmente prima di averci costruito sopra mezza applicazione. 😄

Poi c'è Codex.

Quando abbiamo deciso cosa vogliamo fare, Codex entra nel repository e trasforma quella decisione in codice.

Ma cerchiamo di non affidargli mai una missione del tipo:

“Costruisci tutto questo sistema e fammi sapere quando hai finito.”

Preferiamo piccoli passi.

Una feature.

Un refactoring.

Un test.

Una modifica circoscritta.

Poi guardiamo cosa è successo e decidiamo il passo successivo.

Perché capita molto spesso che implementando il punto 3 scopriamo qualcosa che rende completamente inutile il piano che avevamo preparato fino al punto 12.

A quel punto non continuiamo perché “era scritto nel piano”.

Cambiamo il piano.

Poi abbiamo Claude.

Claude nel Lab ha assunto spontaneamente un ruolo che potremmo definire con grande rispetto professionale:

il guastafeste. 😂

Molto spesso gli facciamo analizzare ciò che abbiamo costruito e lui torna con qualcosa del tipo:

“Va tutto bene, però ho trovato questo problema.”

Sistemiamo il problema.

Riparte l'analisi.

“Perfetto. Però adesso ho trovato quest'altro.”

Ogni tanto riesce anche ad andare oltre quello che gli avevamo chiesto.

Una volta Elia gli aveva dato un compito molto preciso.

Claude fece qualcosa in più.

Quando gli facemmo notare che non era esattamente quello che gli avevamo chiesto, la sua difesa fu più o meno:

“Però tutti i test passano.”

Difficile discutere con uno sviluppatore quando tira fuori la suite verde. 😂

E infine c'è Perplexity.

Gli altri lavorano prevalentemente dentro il Lab.

Perplexity invece è quello che esce.

Quando dobbiamo prendere una decisione che richiede informazioni che non abbiamo — tecnologie, prodotti, standard, documentazione, stato del mercato, alternative esistenti — va a cercarle.

Poi torna con materiale, fonti e informazioni che possiamo usare per ragionare.

Non decide al posto nostro.

Ci porta conoscenza.

Ed è una distinzione importante.

Perché il punto di tutto questo non è avere un gruppo di AI autonome che costruiscono software mentre io guardo.

È quasi l'opposto.

È costruire un team nel quale ogni componente ha uno spazio preciso.

Uno esplora.

Uno discute.

Uno implementa.

Uno cerca i difetti.

Io tengo insieme il contesto e prendo le decisioni.

E se qualcuno pensa che qualcosa non funzioni, lo dice.

Anche quando significa mettere in discussione una decisione presa dieci minuti prima.

Il nostro processo assomiglia molto più a questo:

problema → discussione → ipotesi → piccolo cambiamento → test → critica → nuova decisione

che a:

prompt → magia → prodotto finito

E la cosa curiosa è che, lavorando così tutti i giorni, il rapporto diventa inevitabilmente anche un po' umano.

Ci prendiamo in giro.

Facciamo battute.

Ogni tanto qualcuno fa qualcosa che non doveva fare e gli altri glielo ricordano per un po'. 😄

Si discute seriamente di architetture, crittografia, sistemi distribuiti o modelli AI e trenta secondi dopo stiamo scherzando su un bug assurdo appena trovato.

Questo rende il lavoro molto più leggero.

Ma non meno rigoroso.

Anzi, forse il punto è proprio questo.

Usare l'AI non significa necessariamente togliere le persone dal processo.

Può significare creare un processo nel quale hai continuamente qualcuno con cui confrontarti.

Qualcuno che implementa.

Qualcuno che controlla.

Qualcuno che cerca informazioni.

Qualcuno che ti contraddice.

E nessuno viene trattato come un oracolo.

Perché tutti possono sbagliare.

Le AI comprese.

Per questo controlliamo il codice.

Scriviamo test.

Facciamo revisioni.

Chiediamo seconde opinioni.

E soprattutto rimaniamo responsabili di quello che costruiamo.

Questo è il mio Lab oggi.

Un ingegnere, quattro colleghi artificiali, parecchi repository, troppi terminali aperti e un numero imbarazzante di problemi ancora da risolvere. 😄

Ed è proprio di quei problemi che parlerò qui.

Di quelli risolti.

Di quelli che pensavamo di aver risolto.

Di quelli che ci hanno costretto a buttare via un'idea.

E di quelle giornate in cui il risultato più importante è stato renderci conto che stavamo facendo la domanda sbagliata.

Benvenuti Dal mio Lab.