Project Manager dell’intelligenza artificiale: Perché la costruzione di agenti di intelligenza artificiale è solo un altro progetto IT

Come un team aziendale ha iniziato a costruire agenti AI

Costruire agenti di intelligenza artificiale anche se non siamo IT

L’aspetto interessante degli ultimi due anni è che non è più necessario un team di sviluppo per fornire un’intelligenza artificiale funzionante. Un professionista in grado di descrivere ciò che dovrebbe accadere e di copiare alcuni input di esempio può costruire un agente che svolge un lavoro reale. Non avevamo pianificato di diventare costruttori. Abbiamo continuato a svolgere attività per le quali la risposta era ovviamente “questo può essere fatto da un agente”, così abbiamo iniziato a costruire. La prima operazione ha richiesto un pomeriggio. Il secondo ha richiesto un pomeriggio. Poi sono iniziati i problemi, non con l’edificio, ma con tutto ciò che lo circonda.

Gli agenti che abbiamo costruito

L’elenco è cresciuto più velocemente di quanto ci aspettassimo. Abbiamo un agente che inserisce automaticamente i dati del cliente nei nostri contratti Standard. Un agente che prepara la prima bozza di offerta sulla base del riepilogo di una conversazione di vendita. Un integratore che importa l’elenco dei progetti Excel di un cliente direttamente nel suo ambiente FlexiProject. Un assistente che ci aiuta a gestire parti del nostro sito web. Un agente che estrae i dati di Google Search Console per il nostro dominio e li trasforma in un riepilogo settimanale leggibile. Un agente che, dopo le riunioni con i clienti, aggiorna il nostro backlog di prodotti con ciò che le aziende ritengono manchi, in modo che le idee sulle funzionalità non vadano perse tra una telefonata e la successiva sessione di pianificazione. E decine di altri più piccoli, aiutanti per singole attività che qualcuno ha costruito per sé, ha continuato a migliorare e alla fine ha condiviso con il team.

Quando lo stesso agente viene esteso in parallelo

L’attrito non è venuto dagli agenti che abbiamo costruito una volta e di cui ci siamo dimenticati. Veniva dagli agenti che contavano davvero. Due persone prendevano un agente utile, ognuno aveva un’idea diversa su come migliorarlo e iniziavano a estenderlo in modo indipendente. Una settimana dopo avevamo due versioni: suggerimenti diversi, strumenti diversi inseriti, casi limite diversi e nessun modo pulito per unirli. Si trattava dello stesso problema che gli sviluppatori hanno risolto decenni fa con Git: non è possibile che due persone lavorino su un punto di partenza condiviso e lo migliorino in direzioni diverse senza un modello di ramificazione. Ma non pensavamo di averne bisogno. Gli agenti erano “facili”. L’espressione AI project management non era ancora entrata nel nostro vocabolario.

Perché lo sviluppo di agenti di intelligenza artificiale è, fondamentalmente, la gestione di un progetto IT

Costruire agenti è banalmente facile

La prima lezione è quella più scomoda: creare un agente è davvero facile. Chiunque stia leggendo potrebbe aprire un modello e avere qualcosa di funzionante nel giro di un’ora. La demo sembrerà magica. I primi tre utenti lo adoreranno. Ed è proprio questo il momento in cui il progetto diventa difficile, perché spedire una demo non significa spedire uno strumento su cui l’azienda può fare affidamento. Il divario tra “funziona con gli input che ho provato” e “funziona con gli input che l’intera azienda gli fornisce” è enorme e il modello stesso non fa nulla per colmarlo. La gestione dei progetti di intelligenza artificiale serve a colmare questo divario.

Un team aziendale che costruisce agenti AI deve imparare la gestione dei progetti IT

Quando un team non informatico inizia a costruire software, e un agente è un software, eredita tutti i problemi che i team di ingegneri hanno imparato a gestire in cinquant’anni. I requisiti devono essere scritti. L’architettura deve essere progettata. Il codice, i suggerimenti o le definizioni degli strumenti devono essere condivisi da qualche parte. I test devono esistere. Le modifiche devono essere revisionate prima di essere rese operative. Saltare uno di questi aspetti non li fa sparire, ma sposta solo il costo in avanti nel tempo. La buona notizia è che il manuale esiste già. Le discipline che permettono ai progetti IT di avere successo si applicano immutate quando un team aziendale costruisce agenti. L’unico ingrediente nuovo è la valutazione, la versione specifica dell’IA del testing.

Il ciclo di vita del progetto dell’agente AI

1. Analisi iniziale: quale problema stiamo risolvendo?

Ogni agente che vale la pena costruire inizia con una fase di analisi che non ha nulla a che fare con l’intelligenza artificiale. Chi lo userà? Cosa fanno oggi, passo dopo passo? Quali di questi passaggi sono effettivamente dannosi? Cosa significa “fatto bene” – in modo misurabile? Prima di costruire l’agente per la preparazione dell’offerta, abbiamo scritto l’esatta sequenza manuale che il team di vendita seguiva, abbiamo segnato quali passaggi erano ripetitivi e quali richiedevano un giudizio, e solo dopo abbiamo deciso cosa l’agente avrebbe dovuto o non dovuto fare. L’analisi ha richiesto più tempo della costruzione. Questo rapporto è normale.

2. Pianificazione – ambito, integrazioni, filiale condivisa

La pianificazione è il momento in cui si decidono tre cose: gli input e gli output, le integrazioni che l’agente toccherà e, soprattutto, dove risiede il lavoro. Se due persone intendono contribuire, hanno bisogno di una definizione condivisa di “principale”. Può trattarsi di un unico documento con i prompt canonici e le definizioni degli strumenti, di un repo, di una cartella di competenze: il formato conta meno dell’accordo. Sceglietelo il primo giorno. Decidi cosa non farà l’agente, scrivilo e attieniti ad esso; lo scope creep è il motivo più comune per cui gli agenti diventano non manutenibili.

3. Sviluppo: la parte ingannevolmente facile

La costruzione in sé è veloce. Questa è la trappola. Scriverai i tuoi suggerimenti, collegherai i tuoi strumenti, eseguirai alcuni esempi e ti sembrerà di aver fatto l’80%. In realtà sei al 30%. Il restante 70% è costituito da tutto ciò che non hai ancora testato: gli input strani, gli input lunghi, gli input in un’altra lingua, i casi in cui uno strumento restituisce un risultato vuoto, i casi in cui l’utente cambia idea a metà conversazione. Niente di tutto questo è visibile dall’interno della build.

4. Testare – e poi ri-testare

Questo è il punto in cui gli agenti si differenziano maggiormente dal software classico e in cui la maggior parte dei team prende scorciatoie. Un agente supera un test oggi e potrebbe fallire lo stesso test domani perché è stata cambiata una singola riga del prompt o perché il modello sottostante è stato aggiornato. La disciplina di cui hai bisogno è la valutazione di regressione: una serie di input salvati con i comportamenti attesi, eseguiti automaticamente, o almeno sistematicamente, dopo ogni modifica. Senza questa disciplina, si viene a conoscenza delle regressioni solo quando un utente ci inciampa sopra.

5. Consegna e passaggio di consegne

Un agente che non viene mai consegnato ufficialmente è un agente che diventa legacy il primo giorno. La consegna implica la stesura della documentazione per l’utente, la definizione del successo in produzione e la creazione di un modo per monitorare se l’agente è ancora utile tre mesi dopo. Questo lo abbiamo imparato lentamente – vedi la prossima sezione.

MVP, Agile e Scrum nei progetti di AI

MVP prima di tutto: inizia con l’agente utile più piccolo

Ogni agente che abbiamo costruito e che ha avuto successo è partito come la più piccola versione utile di se stesso. Un’attività. Un input. Un solo output. Abbiamo resistito alla tentazione di aggiungere il secondo caso d’uso finché non abbiamo visto il primo sopravvivere al contatto con utenti reali. Gli agenti che hanno avuto difficoltà erano l’opposto: ambiziosi fin dal primo giorno, con tre funzionalità nessuna delle quali funzionava fino in fondo. Gli agenti big-bang falliscono esattamente per gli stessi motivi per cui falliscono i progetti software big-bang: il fattore di forma non cambia i conti. Se vuoi trarre una sola regola da questo articolo, prendi questa: un MVP per un agente AI è abbastanza piccolo da permettere a una persona di descriverlo in tre frasi e di farlo funzionare end-to-end su un esempio reale entro la fine di una giornata. Tutto ciò che segue è un’iterazione.

Perché l’agilità si adatta naturalmente agli agenti di IA

Gli agenti sono particolarmente adatti al lavoro agile perché sono insolitamente imprevedibili. Non puoi specificare completamente un agente in anticipo come fai con un modulo di pagamento o un report. Si realizza una piccola versione, si osserva il funzionamento nel mondo reale, si vede dove fallisce e si aggiusta la cosa successiva. Cercare di progettare l’agente perfetto sulla carta prima di costruirlo è il modo più veloce per costruire l’agente sbagliato. L’iterazione non è una preferenza di gestione del progetto per l’IA; è un requisito strutturale – lo stesso ritmo di Plan, Do, Check, Act che Deming descrisse decenni fa per qualsiasi processo che deve migliorare continuamente, ma applicato ad agenti il cui comportamento non può essere completamente previsto.

Eseguire il lavoro dell’agente negli sprint Scrum

Trattiamo ogni agente significativo come un piccolo flusso di lavoro in stile Scrum. C’è un backlog di funzionalità che l’agente potrebbe avere. Ogni sprint ne seleziona un piccolo numero. La demo dello sprint è l’agente stesso, eseguito su input reali del team che lo utilizzerà. Se la demo non è convincente, il lavoro continua; la cadenza costringe a una conversazione reale tra il costruttore e gli utenti, invece di una costruzione silenziosa che dura mesi.

Errori che abbiamo commesso

Costruire prima di analizzare

Dato che la costruzione è così veloce, sembra efficiente passare direttamente ad essa. Non è così. Gli agenti che abbiamo costruito senza un’analisi chiara hanno finito per funzionare tecnicamente, ma per risolvere il problema sbagliato; il team che li utilizzava è stato educato per un po’ e poi è tornato tranquillamente a svolgere il lavoro manualmente. Un pomeriggio di analisi avrebbe risparmiato una settimana di lavoro.

Fiducia nel modello

Questo è stato l’errore più ricorrente e il più difficile da disimparare. Pensavamo che se avessimo dato al modello un compito in un linguaggio semplice, avrebbe progettato una buona soluzione. Spesso non lo faceva, non perché il modello fosse debole, ma perché non avevamo fatto noi stessi il lavoro di progettazione. Il modello non ha una visione del contesto aziendale, dei dati esistenti, delle convenzioni non scritte e del sistema che circonda l’attività. Più cose gli fornisci, una vera analisi, una vera architettura, la struttura che vuoi che segua, migliore sarà il risultato. Il modello è eccellente nell’esecuzione. Non è il tuo architetto.

Fare il big-bang invece di partire da un MVP

Ogni volta che abbiamo cercato di lanciare un agente completo al primo giorno, il risultato ha richiesto più tempo per essere costruito, è stato più difficile da debuggare ed è stato abbandonato più spesso rispetto alle piccole versioni che avevamo sviluppato deliberatamente. Il Big-bang sembrava più veloce. Non lo era.

Due persone che sviluppano lo stesso agente in parallelo

Questo era il momento Git. Due persone, lo stesso agente, idee diverse, rami diversi nelle loro teste, nessun “principale” condiviso. Una settimana dopo, due versioni che non si conciliavano. Ora trattiamo ogni agente significativo nello stesso modo in cui gli sviluppatori trattano il codice: una versione canonica, un modello di ramificazione esplicito quando più di una persona ci lavora e una fase di fusione esplicita. Oppure, se le idee divergono davvero, decidiamo deliberatamente di dividerci in due agenti separati invece di far finta che siano ancora uno.

Nessuna documentazione iniziale: gli utenti non sapevano cosa facesse l’agente.

I primi utenti interni delle nostre competenze continuavano a fare le stesse domande: cosa fa effettivamente questa cosa, cosa devo inserire, come si presenta l’output, quando dovrei usarla rispetto alla versione precedente. Pensavamo che l’agente si spiegasse da solo. Non lo era. Ora scriviamo una breve descrizione per l’utente di ogni agente al momento del passaggio di consegne: cosa fa, cosa gli si deve dare in pasto, cosa aspettarsi, cosa non fa. Costa dieci minuti ed evita settimane di utilizzo confuso.

Domande frequenti sulla gestione dei progetti di IA

La gestione dei progetti AI è diversa dalla normale gestione dei progetti IT?

Le discipline sono le stesse: analisi, pianificazione, costruzione, test, consegna, iterazione. Le differenze risiedono nelle fasi di costruzione e di test: i risultati non sono deterministici, il comportamento può andare alla deriva quando il modello o le richieste cambiano e il “test” diventa “valutazione rispetto a una serie di casi salvati”. Tutto ciò che circonda queste fasi assomiglia a un normale progetto IT.

Ho bisogno di uno strumento di project management per gestire lo sviluppo di un agente AI?

Hai bisogno di un luogo in cui ogni agente viva come un progetto: con un piano, una versione corrente, un proprietario e uno stato di consegna. Che si tratti di un sistema di gestione dei progetti, di un wiki o di una struttura di cartelle, non ha molta importanza. Per i team che gestiscono molti agenti in parallelo, un vero sistema di PM si ripaga rapidamente.

Quanto dovrebbe essere grande un agente MVP?

Abbastanza piccolo da permettere a una persona di descriverlo in tre frasi e di eseguirlo end-to-end su un esempio reale entro la fine della giornata. Se non ci riesci, l’ambito è troppo grande e l’MVP è qualcosa di più ristretto.

Come si impedisce a due persone di costruire lo stesso agente in parallelo?

Non si impedisce a due persone di contribuire, ma si rende esplicito dove risiede la versione canonica, chi è il proprietario del merge e quando le idee divergenti devono diventare un fork deliberato in due agenti separati. La lezione dell’ingegneria del software si applica da uno a uno: un ramo condiviso, con un processo di fusione concordato.

Quando un agente diventa legacy?

Nel momento in cui nessuno è responsabile di valutare se è ancora utile. Un agente che nessuno controlla si degrada silenziosamente, il mondo che lo circonda cambia, gli input si evolvono, il modello sottostante viene sostituito e un giorno si sbaglia e nessuno se ne accorge. L’eredità non è un’età, ma uno stato di abbandono.

Conclusione

La parte entusiasmante della creazione di agenti AI, il modello, i suggerimenti, il momento in cui una demo funziona per la prima volta, è la frazione più piccola del lavoro. Le parti non entusiasmanti sono quelle che trasformano una demo in uno strumento su cui tutta l’azienda può fare affidamento: un’analisi chiara, un piano reale, un ramo condiviso, test di regressione, documentazione e un ritmo di iterazione che mantiene l’agente utile anche dopo la consegna della prima versione. Niente di tutto questo è esotico. Si tratta esattamente della disciplina che ha portato al successo i progetti IT per decenni, applicata senza diluizioni a un tipo di software leggermente più recente. I team che adottano questa disciplina per tempo si ritrovano con agenti di cui si fidano. I team che la saltano finiscono per ricostruire lo stesso agente due volte. Trattare ogni agente come un vero e proprio progetto, con un piano che puoi definire, rivedere e migliorare, è il significato pratico della gestione dei progetti di intelligenza artificiale. Lo facciamo in FlexiProject, dove ogni agente ha un proprio registro di progetto con un piano d’azione chiaramente scritto; qualunque sistema tu scelga, tratta ogni agente come un progetto, non come un esperimento.