Se domani i tuoi sviluppatori scrivessero il doppio del codice, la tua azienda riuscirebbe a consegnare il doppio del valore?
È la domanda con cui ho aperto questa conversazione con Riccardo Tartaglia di Artiforge. Perché quando parliamo di AI nello sviluppo software, è facile concentrarsi sul risultato più visibile: una feature implementata in poche ore, una modifica generata con un prompt, una pull request pronta molto prima del previsto.
Il lavoro di un team, però, comprende anche tutto quello che rende quel codice utile: capire il problema, condividere le decisioni, verificare il comportamento e mantenere il sistema nel tempo. Accelerare la scrittura cambia l’equilibrio tra queste attività. Non garantisce, da solo, che il processo migliori.
L’esperienza raccontata da Riccardo nello sviluppo di Knotic offre uno spunto per affrontare il tema dal punto di vista di chi guida un’organizzazione tecnica: come rendere il lavoro con l’AI comprensibile, condivisibile e sostenibile?
1. Il codice arriva prima. Il valore potrebbe arrivare dopo
«Stiamo spostando soltanto la tempistica dalla scrittura codice alla parte di revisione.»
Riccardo descrive una situazione concreta: una modifica che prima richiedeva una settimana viene implementata in poche ore, ma poi attraversa cinque cicli di review senza arrivare a un risultato accettabile. La velocità guadagnata nella scrittura viene assorbita dalle correzioni successive.
Il punto è che la pull request arriva quando molte decisioni sono già state prese. Se l’errore nasce nell’interpretazione del requisito o nell’impostazione della soluzione, il reviewer si trova a correggere a valle qualcosa che andava chiarito prima. E più ampio è l’output generato, più lavoro può servire per ricostruirne la logica.
Per un CTO, questo cambia la domanda da fare al team. Il numero di modifiche prodotte racconta soltanto una parte della storia. Bisogna capire quanto tempo passa prima che siano accettate, quante volte tornano indietro e quanto lavoro richiedono alle altre persone.
Un punto di partenza pratico è osservare una feature lungo tutto il percorso, dal requisito al rilascio. È lì che diventa visibile se l’AI sta riducendo il lavoro complessivo oppure lo sta spostando tra fasi e persone.
2. La conoscenza deve sopravvivere alla conversazione
«Il problema non è avere 10 conversazioni, il problema è che ci sono magari 10 modi completamente diversi di gestire una problematica.»
Una conversazione con un coding agent può funzionare bene per chi la conduce. Quella persona conosce il contesto, ricorda le alternative scartate e sa interpretare le risposte. Il problema emerge quando qualcun altro deve riprendere il lavoro: ciò che era evidente durante la sessione potrebbe non essere stato reso esplicito da nessuna parte.
Nell’intervista parliamo del “chat vortex”: cicli di richieste, modifiche e nuove richieste nei quali diventa difficile ritrovare il filo. Il rischio riguarda soprattutto i requisiti, le motivazioni e i vincoli che rimangono dispersi nella conversazione, mentre nel repository arriva soltanto il risultato.
Riccardo propone una memoria condivisa che aiuti a comprendere anche le regole di business rappresentate dal codice. Sapere dove si trova una funzione è utile; capire a quale processo contribuisce, quali dipendenze ha e come quel comportamento si è evoluto permette di intervenire con maggiore consapevolezza.
Il criterio, per chi guida il team, è molto concreto: un nuovo sviluppatore riesce a ricostruire il funzionamento di una parte del prodotto attraverso materiali accessibili e aggiornati? Oppure deve trovare la persona giusta e sperare che ricordi tutte le decisioni?
3. Un metodo comune può lasciare spazio alla libertà individuale
«La vera velocity del team nasce nel momento in cui si riduce il lavoro ripetuto.»
La governance diventa utile quando evita di rifare analisi, ricostruire contesti e discutere più volte decisioni già prese. In questa prospettiva, serve a rendere disponibili le informazioni necessarie nel momento in cui qualcuno deve agire.
Riccardo distingue la libertà nella fase implementativa dalla necessità di condividere l’impostazione del lavoro. Uno sviluppatore può avere i propri prompt e le proprie skill; il team deve però poter ritrovare la specifica, il piano e le decisioni tecniche su cui quella implementazione si basa.
È una distinzione importante per evitare che l’introduzione dell’AI si traduca in una serie di pratiche individuali scollegate. Il coordinamento richiede che le persone possano capire cosa stanno facendo i colleghi e su quali presupposti, anche quando usano strumenti o approcci diversi.
Da qui una possibile regola operativa: rendere comuni gli elementi necessari per collaborare e verificare il risultato. L’obiettivo è ridurre l’ambiguità nei passaggi di lavoro, mantenendo autonomia dove l’autonomia aiuta davvero.
4. La responsabilità umana comincia prima della review
«L’umano oltre a essere il revisore deve essere anche il cervello che c’è dietro l’intelligenza artificiale.»
Riccardo esprime una posizione netta sull’human in the loop: il contributo dell’ingegnere comprende la traduzione del bisogno di business in una soluzione tecnica. Architettura, vincoli e scelte implementative fanno parte del pensiero che guida il lavoro dell’agente.
Questo significa che la supervisione non può esaurirsi nell’approvazione finale di una pull request. Se nessuno ha chiarito il problema e valutato la soluzione, la verifica arriva tardi e rischia di concentrarsi soltanto su ciò che il codice sembra fare.
Anche il superamento dei test lascia aperta una domanda: il comportamento ottenuto corrisponde alla specifica iniziale? Nell’approccio descritto dall’ospite, la revisione umana e la verifica end to end mantengono un ruolo centrale proprio per valutare questa corrispondenza.
Per un Tech Leader, l’implicazione organizzativa è assegnare responsabilità comprensibili: chi definisce il risultato atteso, chi valuta le scelte e chi conferma che la modifica risponda al bisogno. L’automazione può supportare queste attività; il team deve sapere chi ne risponde.
5. Un piano condiviso rende il lavoro trasferibile
«Ogni tool tira fuori un artefatto, cioè un output strutturato che può essere condiviso all’interno dei repository.»
Uno dei passaggi più interessanti della conversazione riguarda la possibilità di trasformare il ragionamento in materiali riutilizzabili. Nell’esperienza raccontata da Riccardo, il brainstorming produce una specifica e la pianificazione la suddivide in fasi di lavoro. Questi output possono essere versionati e condivisi.
Il beneficio emerge quando più persone lavorano sulla stessa feature. Se ognuno chiede al proprio agente di elaborare un piano partendo da una descrizione generica, può ottenere una sequenza diversa, con assunzioni e priorità differenti. Un piano comune offre invece un riferimento su cui coordinarsi.
Riccardo usa l’espressione “determinismo nell’indeterminismo” per descrivere questa ricerca di maggiore controllo. Il principio organizzativo è ridurre la variabilità del processo attraverso input condivisi, dipendenze esplicite e passaggi verificabili; questo non equivale a garantire che ogni output del modello sia corretto.
La lezione applicabile anche al di fuori del singolo strumento è rendere trasferibile il lavoro di progettazione. Una specifica utile consente a un collega di proseguire senza dover ricreare da zero tutto il ragionamento.
6. Sul legacy, comprendere il sistema è parte del lavoro
«Riusciamo appunto a ricostruire anche lo storico, non soltanto del codice, ma della conoscenza del progetto.»
Su un prodotto esistente, la difficoltà può stare nel capire ciò che c’è già: flussi modificati nel tempo, vincoli di compatibilità, dipendenze e conoscenze concentrate in persone che magari hanno lasciato l’azienda. In questo scenario, generare rapidamente una modifica risolve soltanto una parte del problema.
Riccardo descrive il lavoro sulla memoria del progetto attraverso l’esempio del login: ricostruire come funzionava in un determinato commit e che cosa è cambiato in quello successivo. L’obiettivo dichiarato è rendere leggibile l’evoluzione del comportamento, oltre alla differenza tra i file.
Per il team, poter interrogare questa conoscenza può aiutare nell’onboarding e nell’analisi dell’impatto di una modifica. La qualità del contesto disponibile diventa quindi un elemento da valutare insieme alle capacità del coding agent.
La domanda da portare in una valutazione degli strumenti è concreta: quanto aiutano gli sviluppatori a comprendere il sistema su cui devono intervenire? Su una codebase con anni di storia, questa capacità può essere decisiva per usare bene la velocità di generazione.
7. Tre domande prima di introdurre un nuovo strumento
«Riesco a ricostruire il costo di un’attività svolta con le AI nel mio team?»
Nella parte finale, Riccardo suggerisce tre domande da affrontare prima dell’adozione. La prima riguarda il processo: quali sono davvero le fasi che portano da un’esigenza a una modifica rilasciata? Bisogna sapere quali output produce l’analisi e come diventano lavoro implementabile.
La seconda riguarda l’uso attuale dell’AI: quali strumenti e skill utilizzano le persone? Quali pratiche sono condivise e dove, invece, ciascuno lavora per conto proprio? Questa ricognizione aiuta a capire dove mancano continuità e coordinamento.
La terza riguarda il costo dell’attività, includendo sia l’utilizzo dei modelli sia le ore delle persone. Una generazione economica che richiede molte revisioni va valutata nel suo insieme, così come una soluzione più costosa che riduce sensibilmente il lavoro successivo.
Il passo concreto per un CTO è scegliere un’attività reale e ricostruirla dall’inizio alla fine: specifica, strumenti utilizzati, implementazione, verifiche e rilavorazioni. Quel percorso offre una base per decidere dove intervenire e che cosa chiedere a un nuovo strumento.
