Cosa cambia quando il tuo team di sviluppo è un’AI

Quasi tutto ciò che si scrive sullo sviluppo con l’AI parla della prima ora: la demo, lo scheletro del progetto, la funzione comparsa in dieci minuti. Pochissimo parla del nono mese, quando il codice è grande, diverse modifiche sono in corso insieme e gli errori interessanti non sono più errori di sintassi.

Questo è un appunto dal nono mese.

Le decisioni scritte sono diventate il vero vincolo

Un team di ingegneri umani porta con sé moltissimo contesto condiviso che non viene mai scritto da nessuna parte. Tutti conoscono la regola sui tenant, il motivo per cui il vecchio approccio è stato abbandonato, quale modulo è un campo minato.

Un team di AI, fra una sessione e l’altra, non ha nulla di tutto questo. Quindi ogni decisione che conta deve esistere come documento durevole e recuperabile, oppure non esiste affatto.

In pratica significa una struttura a livelli rigorosa. Ogni funzione ha una specifica funzionale (cosa fa per l’utente), un progetto tecnico (schema, endpoint, architettura) e un file di epic (storie e relativo stato). Le decisioni di architettura che attraversano più funzioni hanno i loro documenti numerati: perché la piattaforma si adatta al settore invece di partire da modelli, perché le modalità operative dell’AI hanno la forma che hanno, perché il sito di marketing è un export statico. Un file di avvio alla radice del repository indirizza ogni tipo di lavoro verso le letture obbligatorie, così un’attività che tocca l’autenticazione si porta dietro in automatico il modello delle minacce.

La cosa che mi ha sorpreso: non è un costo sostenuto a beneficio dell’AI. È la disciplina documentale che ogni team di sviluppo dice di volere e che pochi mantengono, resa obbligatoria perché l’alternativa si vede subito. Quando la documentazione si disallinea, la sessione successiva costruisce la cosa sbagliata il giorno stesso, non fra sei mesi quando arriva un nuovo assunto.

Uno stato registrato non è una prova

L’errore che non avevo previsto, e quello che ci è costato più tempo, è fidarsi di uno stato che si è rivelato la descrizione di un’intenzione.

Una issue chiusa significa che qualcuno ha deciso che il lavoro era finito. Una build verde significa che i job che sono girati sono passati. Nessuna delle due prova che la cosa funziona. In una giornata particolarmente istruttiva sono stati trovati cinque difetti in funzioni con le issue chiuse e le pipeline verdi. In ogni caso il registro era preciso su ciò che era successo e muto su ciò che non era successo.

Le trappole specifiche si ripetono, e valgono ben oltre lo sviluppo con l’AI:

• Una suite di test che non trova nessun test riporta un successo. Lo stesso vale per un filtro con un errore di battitura nel percorso. Il verde su un insieme vuoto è identico al verde su un insieme di test superati, a meno che tu non controlli il conteggio.
• Una pipeline con filtri sui percorsi salta le suite che la tua modifica non ha toccato. Un’esecuzione che riporta «successo» su sedici job può non provare nulla sulla modifica che hai davanti.
• Una build può passare su una macchina con dipendenze vecchie, e poi fallire per tutti gli altri.

La correzione è una regola, non più vigilanza: verifica sul prodotto del lavoro, non sul registro. Leggi il codice, conta le asserzioni che sono state eseguite, carica la pagina. Oggi è il primo istinto e non l’ultima risorsa, ed è la pratica che trapianterei in qualsiasi team, con o senza AI.

Il lavoro in parallelo ha bisogno di isolamento, non di galateo

Su questo repository lavorano più sessioni di AI contemporaneamente. Condividono un’unica directory git, il che significa che riferimenti dei branch, stash e stato remoto sono comuni a tutte: i worktree isolano i file, mai i riferimenti.

Senza un isolamento rigido succedono tre cose, e sono successe tutte e tre: due sessioni costruiscono la stessa cosa per conto loro, una sessione fa push sul branch di un’altra, e una sessione fa pulizia di un lavoro in corso che apparteneva a qualcun altro.

Le regole che hanno risolto il problema sono poco appariscenti. Ogni sessione lavora nel proprio worktree, creato dal branch principale condiviso. Un branch ha esattamente un proprietario; non si fa mai push su un branch che non hai creato tu. Non si tocca mai uno stato condiviso che non hai creato: lo stash di qualcun altro non è tuo da ripulire. E la pulizia si fa all’inizio di una sessione, non alla fine, perché una sessione non può rimuovere il worktree dentro cui sta girando; l’istruzione di fare ordine alla fine è stata, senza che nessuno se ne accorgesse, impossibile per un anno, ed è per questo che nessuno l’aveva mai fatto.

Se suona come la descrizione di un sistema distribuito più che di un team, è proprio questo il punto. Il coordinamento fra agenti è un problema di ingegneria con soluzioni di ingegneria, non un problema di comunicazione con soluzioni culturali.

I test hanno cambiato mestiere

Con sviluppatori umani, i test intercettano le regressioni. Con sviluppatori AI, i test sono il modo in cui l’intenzione viene trasmessa. Una specifica dice cosa deve succedere; un test lo afferma in una forma che non si può fraintendere, non si disallinea e fallisce rumorosamente quando una modifica successiva la contraddice.

Questo cambia cosa vale la pena testare. I test di maggior valore qui non sono quelli che coprono più righe, ma quelli che codificano una regola che non deve mai essere violata, dove l’errore sarebbe silenzioso: che nessuna query possa uscire dal perimetro del proprio tenant, che un’autorizzazione non possa essere allargata da un percorso nel codice, che esista una traccia di controllo per ogni modifica. Quelli reggono il peso. Un test che verifica come una funzione di supporto formatta una data no.

Il collegamento con il prodotto

Qui smette di essere una storia di processo.

Tutto ciò che ho scritto sopra descrive ciò di cui un sistema ha bisogno perché un’AI ci possa lavorare in sicurezza: un modello di dati senza ambiguità, decisioni registrate in forma leggibile da una macchina, uno stato che si può verificare invece di darlo per scontato, autorizzazioni che reggono senza contare sul buon comportamento, una traccia di controllo che dice chi ha fatto cosa, e un modo per annullare un errore.

È anche, esattamente, l’elenco di ciò di cui un gestionale ha bisogno perché un’AI lo possa usare in sicurezza per conto di un cliente.

Il che significa che costruire Cyril così non è stato né una curiosità né un risparmio. È stato il test più severo possibile della tesi centrale del prodotto. Ogni volta che il processo di sviluppo aveva bisogno di una nuova garanzia per restare sicuro, la stessa garanzia si rivelava mancante nella piattaforma. Un solo registro di controllo invece di diversi. Un solo modello di autorizzazioni che l’attore automatico eredita invece di aggirare. Una via di ripristino che esiste perché lo schema la rende possibile, non perché qualcuno si è ricordato di aggiungere un pulsante Annulla.

Non avevo pianificato questa simmetria. Oggi sosterrei che non è una coincidenza: il software che un agente può usare e il software che un agente può costruire sono la stessa categoria di cose, e se stai costruendo il primo, costruirlo nel secondo modo è il test onesto più economico che troverai.

Cosa direi a chi comincia

• Metti per iscritto la decisione nel momento in cui la prendi, nel posto in cui la sessione successiva andrà a guardare. Una decisione non documentata verrà ridiscussa, e probabilmente ribaltata.
• Non fidarti mai di un campo di stato. Verifica sul prodotto del lavoro. Considera che ogni luce verde risponda a una domanda più ristretta di quella che hai fatto.
• Isola il lavoro in parallelo a livello di strumenti. Le regole che si basano sulla cortesia fra agenti saltano alla prima collisione.
• Spendi il budget dei test sulle regole che falliscono in silenzio, non sulla percentuale di copertura.
• Rivedi il diff, non il riepilogo. Il riepilogo è scritto dallo stesso sistema che ha scritto il codice, e descrive ciò che intendeva fare.

Cyril è in pre-lancio. La sua modalità agentica, in cui affidi del tutto un obiettivo, è in arrivo, non già rilasciata; ciò che esiste oggi è la piattaforma e un assistente AI che pianifica, mostra il piano e agisce dove puoi seguirlo. Questa distinzione conta più per me di quanto potrebbe contare per un ufficio marketing, perché tutto il ragionamento qui sopra dice che i guai stanno proprio nella distanza fra ciò che un sistema dichiara e ciò che può dimostrare.