--- title: Che cosa cambia quando il tuo team di sviluppo è una IA canonical: https://getcyril.com/it/blog/quando-il-tuo-team-di-sviluppo-e-una-ia/ published: 2026-08-28 author: Sam Akbari language: it --- # Che cosa cambia quando il tuo team di sviluppo è una IA Quasi tutto ciò che si scrive sullo sviluppo con IA riguarda la prima ora: la demo, l'impalcatura, la funzione comparsa in dieci minuti. Pochissimo riguarda il nono mese, quando la base di codice è grande, ci sono più modifiche in volo contemporaneamente e i guasti interessanti non sono più errori di sintassi. Questa è una nota dal nono mese. ## Le decisioni scritte sono diventate il vero vincolo Un team di ingegneria umano porta con sé una grande quantità di contesto condiviso che non viene mai scritto da nessuna parte. Tutti conoscono la regola di multi-tenancy, il motivo per cui il vecchio approccio è stato abbandonato, quale modulo è un campo minato. Un team di IA non ha niente di tutto ciò fra una sessione e l'altra. Quindi ogni decisione che conta deve esistere come documento durevole e recuperabile, oppure non esiste affatto. In pratica questo significa una stratificazione rigida. Ogni funzionalità ha una specifica funzionale (che cosa fa per chi la usa), un progetto tecnico (schema, endpoint, architettura) e un file di epica (storie e loro stato). Le decisioni architetturali trasversali hanno un proprio registro numerato: perché la piattaforma si adatta al settore invece di usare modelli preconfezionati, perché le modalità operative dell'IA hanno la forma che hanno, perché il sito di marketing è un'esportazione statica. Un file di avvio nella radice del repository instrada i tipi di lavoro verso le loro letture obbligatorie, così un compito che tocca l'autenticazione tira dentro automaticamente il modello delle minacce. La cosa che mi ha sorpreso: non è un sovraccosto pagato a beneficio dell'IA. È la disciplina di documentazione che ogni team di ingegneria dice di volere e che pochi sostengono, resa non facoltativa perché l'alternativa è immediatamente visibile. Quando la documentazione va alla deriva, la sessione successiva costruisce la cosa sbagliata quello stesso giorno, non fra sei mesi quando entra una persona nuova. ## Lo stato registrato non è una prova La modalità di guasto che non avevo previsto, e quella che è costata più tempo, è fidarsi di uno stato che si è rivelato una descrizione di intenzioni. Una segnalazione chiusa significa che qualcuno ha deciso che fosse finita. Una build verde significa che i lavori eseguiti sono passati. Nessuna delle due dimostra che la cosa funzioni. Nell'arco di una giornata particolarmente istruttiva sono emersi cinque difetti in funzionalità le cui segnalazioni erano chiuse e le cui pipeline erano verdi. In ogni caso il registro era accurato 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 IA: - **Una suite di test che non trova alcun test riporta successo.** Lo stesso fa un filtro con un refuso nel percorso. Il verde su un insieme vuoto è identico al verde su un insieme che passa, a meno che tu non controlli il conteggio. - **Una pipeline con filtri di percorso salta le suite che la tua modifica non ha toccato.** Un'esecuzione che riporta «successo» su sedici lavori può non dimostrare nulla sulla modifica che hai davanti. - **Una build può passare su una macchina con dipendenze obsolete** e poi fallire per tutti gli altri. La correzione è una regola, non più vigilanza: **verifica contro l'artefatto, non contro il registro.** Leggi il codice, conta le asserzioni eseguite, carica la pagina. Oggi è il primo istinto e non l'ultima risorsa, ed è la pratica che trapianterei in qualsiasi team, con IA o senza. ## Il parallelismo richiede isolamento, non buone maniere Più sessioni di IA lavorano insieme su questo repository. Condividono un unico directory di git, il che significa che riferimenti di ramo, salvataggi temporanei e stato remoto sono comuni a tutte: i working tree isolano i file, mai i riferimenti. Senza isolamento rigido succedono tre cose, e tutte e tre sono successe: due sessioni costruiscono la stessa cosa in modo indipendente, una sessione spinge codice sul ramo di un'altra e una sessione rimette in ordine lavoro in corso che apparteneva a qualcun altro. Le regole che hanno risolto non hanno nulla di affascinante. Ogni sessione lavora nel proprio working tree creato dal ramo principale condiviso. Un ramo ha esattamente un proprietario; non si spinge mai su un ramo che non hai creato. Non si tocca mai stato condiviso che non hai creato: il salvataggio temporaneo di qualcun altro non è tuo da ripulire. E la pulizia si fa all'*inizio* di una sessione e non alla fine, perché una sessione non può rimuovere il working tree dentro cui sta girando; l'istruzione di riordinare dopo è stata silenziosamente impossibile per un anno, ed è per questo che nessuno l'aveva mai eseguita. Se sembra la descrizione di un sistema distribuito più che di un team, è esattamente 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 IA, i test sono il modo in cui l'intenzione viene *trasmessa*. Una specifica dice che cosa dovrebbe succedere; un test lo afferma in una forma che non si può fraintendere, non va alla deriva e fallisce rumorosamente quando una modifica successiva la contraddice. Questo cambia che 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 e il cui cedimento sarebbe silenzioso: che nessuna interrogazione possa uscire dal perimetro del proprio cliente, che un permesso non possa essere ampliato da un percorso di codice, che esista un record di audit per ogni mutazione. Quelli reggono l'edificio. Un test che verifica che una funzione ausiliaria formatti una data, no. ## Il collegamento con il prodotto È qui che smette di essere una storia sul processo. Tutto quanto sopra descrive ciò di cui un sistema ha bisogno perché una IA possa lavorarci sopra in sicurezza: un modello di dati non ambiguo, decisioni registrate in forma leggibile da una macchina, stato verificabile invece che presunto, permessi che tengono senza contare sul buon comportamento, una traccia di audit che dice chi ha fatto cosa e un modo per annullare un errore. È anche, esattamente, l'elenco di ciò di cui una *piattaforma aziendale* ha bisogno perché una IA possa gestirla in sicurezza per conto di un cliente. Il che significa che costruire Cyril in questo modo non è stato un vezzo né un risparmio. È stata la prova più esigente possibile della promessa centrale del prodotto. Ogni volta che il processo di sviluppo ha avuto bisogno di una nuova garanzia per restare sicuro, quella stessa garanzia mancava alla piattaforma. Un registro di audit invece di parecchi. Un modello di permessi che l'attore automatico eredita invece di aggirare. Una via di ripristino che esiste perché lo schema la sostiene, non perché qualcuno si è ricordato di aggiungere un pulsante di annullamento. Quella simmetria non l'avevo pianificata. Oggi sosterrei che non è una coincidenza: il software operabile da agenti e il software costruibile da agenti sono la stessa categoria di cosa, e se stai costruendo il primo, costruirlo nel secondo modo è la prova onesta più economica che troverai. ## Che cosa direi a chi comincia - **Scrivi la decisione nel momento in cui la prendi**, nel posto in cui guarderà la sessione successiva. Una decisione non documentata verrà rimessa in discussione, e probabilmente ribaltata. - **Non fidarti mai di un campo di stato.** Verifica contro l'artefatto. Dai per scontato che ogni semaforo verde stia rispondendo a una domanda più stretta di quella che hai posto. - **Isola il lavoro parallelo a livello di strumento.** Le regole che contano sulla cortesia fra agenti falliscono alla prima collisione. - **Spendi il budget dei test sugli invarianti che cedono in silenzio**, non sulla percentuale di copertura. - **Rivedi il diff, non il riassunto.** Il riassunto è scritto dallo stesso sistema che ha scritto il codice, e descrive ciò che intendeva fare. Cyril è in fase precedente al lancio. La sua modalità Agentica — quella in cui consegni un obiettivo per intero — è in arrivo, non rilasciata; ciò che esiste oggi è la piattaforma e un assistente IA che pianifica, mostra il piano e agisce dove puoi guardare. Quella distinzione conta per me più di quanto conterebbe per un ufficio marketing, perché tutto il ragionamento qui sopra sostiene che la distanza fra ciò che un sistema dichiara e ciò che può dimostrare è dove vivono i problemi. ## Domande frequenti ### Scrive davvero una IA tutto il codice? Implementazione, test e documentazione sono scritti dall'IA. Direzione di prodotto, priorità, approvazione e revisione sono umane. La divisione che funziona è che l'IA possiede il *come* e una persona possiede il *cosa* e il *se*. ### È più veloce di un team umano? In modo sostanziale, nel momento in cui si scrive codice, e questa si rivela la variabile meno interessante. Il limite è la capacità di revisione e verifica, che è umana, quindi le pratiche che rendono rapida la verifica contano più della produzione grezza. ### Che cosa si rompe più spesso? La fiducia nello stato registrato. Non codice sbagliato: fiducia sbagliata sul fatto che il codice esistente funzioni, a partire da un campo di stato accurato sull'intenzione e muto sull'esito. ### Lo consiglieresti a un altro team? Le pratiche, senza riserve, che tu usi l'IA o meno: decisioni scritte e durevoli, verifica contro gli artefatti, isolamento rigido del lavoro parallelo e test come codifica dell'intenzione. Il modello di organico è una questione a parte e dipende da quanta capacità di revisione hai, perché quello è il vincolo reale. --- Se vuoi essere tra i primi a usare Cyril, [iscriviti alla lista d'attesa](/waitlist/).