Quando un agente IA deve sviluppare un prodotto, spesso si guarda prima al modello e agli strumenti. Quale LLM, quale CAD, quale simulazione? Dopo qualche settimana di robot challenge sono convinto: la qualità del risultato la decide l’Operating Model in cui l’agente lavora. Cioè la domanda su come si lavora, si decide, si verifica e si impara.
Per chi non lo ricordasse: nella Next challenge mi ero proposto di far sviluppare in autonomia a un agente IA un piccolo robot DIY. Dai requisiti all’architettura, dal CAD al firmware, fino alla simulazione. Io definisco framework e requisiti, montarlo a vite devo farlo io. Un primo progetto del robot è ormai completo e simulato (ma non ancora costruito). Più interessante è ciò che c’è stato da imparare lungo il percorso.
Fedele al processo, eppure fuori strada
La mia prima bozza del framework consisteva essenzialmente in regole base e in uno stack tecnologico. Il risultato è stato così così.
L’esempio più eloquente: l’agente aveva scelto autonomamente come base un kit da acquistare, un telaio rotondo in acrilico a due piani. Nel suo modello CAD, però, compariva un telaio rettangolare in alluminio. La foto del prodotto era rimasta per tutto il tempo nella cartella del progetto. Me ne sono accorto io stesso, semplicemente guardando.
La cosa notevole: l’agente aveva rispettato tutte le regole di processo. Requisiti derivati, decisioni documentate, ricerca con fonti. Mancava semplicemente un criterio per riconoscere un buon lavoro ingegneristico — per lui il telaio in alluminio era, detto un po’ provocatoriamente, un «andrà bene così». E io, in qualche modo, avevo dato per scontato che fosse ovvio che il modello corrispondesse a ciò che poi doveva uscirne.
La seconda lezione riguardava me stesso. Mi era chiaro dall’inizio che volevo separare il regolamento (come lavora l’agente?) dal progetto (cosa costruisce?), per poterlo riutilizzare. Anche questo non lo avevo scritto come requisito. Mi è diventato chiaro guardando le prime bozze del framework: no, non siamo ancora arrivati.
Le aspettative implicite diventano requisiti espliciti, oppure non vengono soddisfatte.
Il mio Operating Model prende forma
Dopo due, tre giri di revisione, ne è nato il mio Operating Model nella forma attuale.
A sinistra entra l’Intent: obiettivi, requisiti, vincoli, budget. A destra escono i pacchetti di build, i prototipi e i report di test. In basso scorre un circuito di controllo che torna indietro, con findings, esperienze e change request.
Nell’agente stesso si trovano più livelli. La parte superiore (blu) dipende dal dominio e dall’organizzazione (nel mio caso: da me): strumenti come SysML, CAD, ECAD e simulazione, oltre a regole di design, lessons learned e la domanda su cosa l’organizzazione (= io) sia effettivamente in grado di realizzare e testare. Nella mia «azienda individuale» questo significa: saldare sì, SMD no, nessuna stampante 3D, un multimetro. L’agente deve pianificare con ciò che poi sono davvero in grado di fare.
La parte inferiore (gialla) è il nucleo fisso dell’Operating Model. Vale per tutti i progetti e si compone di tre livelli:
Governance & Conventions. Chi decide cosa; come procedono le modifiche; quando l’agente passa la mano alla persona; come vengono denominati gli asset.
Engineering Platform. Git, container, skill e controlli automatici. Potrebbe però anche essere un ambiente PLM completo come Windchill o Teamcenter.
Engineering Method. Basato sui modelli e architecture first. Prima requisiti e architettura (nel mio caso in SysML v2), poi costruzione e codice. Ogni requisito è tracciabile fino al caso di test.
Chi si muove abitualmente nel PLM non scoprirà molto di nuovo. Manuale di sviluppo, change management, processo di approvazione, design guidelines: per i team umani tutto questo esiste da decenni. Un agente ha bisogno delle stesse cose, solo molto più esplicite e in molti punti imposte in modo automatico.
Cosa mancava ancora all’inizio
Metodo, piattaforma e regole del gioco per le decisioni c’erano fin dall’inizio. Mancava un criterio per un buon lavoro ingegneristico. Il framework l’ha ottenuto nel secondo giro, sotto forma di linee guida di design per le singole discipline, come le conosce ogni reparto di sviluppo. La lezione del telaio è una di queste.
Per me era altrettanto importante che queste linee guida non restassero ferme al primo giorno. L’agente annota ciò che ha imparato e ne propone nuove regole. Sono io a decidere quali valgono.
Quando mi fido dell’agente
Nel mio articolo «L’IA nell’engineering ha bisogno di regole – e di fiducia» si parlava di quando ci si può fidare del lavoro di un’IA. È esattamente questa affidabilità che l’Operating Model deve fondare. Voglio potermi fidare del risultato senza controllare io stesso ogni singola riga.
Per questo serve prima di tutto la tracciabilità: ogni decisione è motivata, ogni requisito è tracciabile fino al test. Poi responsabilità chiare. Le questioni tecniche le risolve l’agente da solo, obiettivi, budget, sicurezza e le regole del gioco solo insieme a me. E questi limiti li impone la piattaforma: una richiesta nel prompt sarebbe troppo debole su sessioni lunghe. Curiosità: una volta ho modificato le regole del gioco direttamente da solo e senza CR, e all’avvio successivo l’agente se n’è accorto e me l’ha attribuito. Beccato!
Agentic Engineering non è Vibe Engineering
Andrej Karpathy ha descritto il Vibe Coding più o meno così: ci si abbandona al vibe e si guarda cosa ne esce. E spesso i termini Vibe Engineering e Agentic Engineering vengono confusi. Ma quello che succede qui è tutto tranne che «vibe». C’è un framework chiaro, che deve soddisfare dei requisiti rispetto a un Intent, e in modo tracciabile.
Nella costruzione di questo framework c’è un bel po’ di sostanza grigia e pochissimo vibe.
In questo noto qualcosa che conosco da tempo lavorando con l’IA. Per compiti singoli e mirati funziona in modo eccellente. Nei progetti più ampi, dove forse si conosce solo l’Intent ma la direzione è ancora molto incerta, e anche la definition of done si riesce a formulare solo in modo vago, funziona solo nel dialogo tra persona e IA. Senza IA questo progetto non sarebbe esistito. Ma senza di me, nemmeno.
E il robot?
In costruzione c’è un robot domestico timido. Si spaventa con luce e rumore e si nasconde nel buio, preferibilmente sotto il nostro divano. Viene simulato in un gemello digitale del nostro soggiorno, con lo stesso firmware che poi funzionerà sul microcontrollore.
Sotto il cofano di «proto-1» ci sono circa 50 requisiti, tutti tracciabili fino al caso di test, 14 decisioni documentate, un’architettura SysML v2 verificata automaticamente e una distinta base per poco meno di 75 euro (su un budget fissato di 100 euro). L’agente stesso aveva inserito tre bug nel suo firmware. E li ha trovati anche lui, in test di scenario e simulazione.
Il prossimo passo è la costruzione. Allora si vedrà se il progetto tiene e quanto è valsa la simulazione. Secondo i requisiti, il piccolo fugge da luce e rumore. Darmi la caccia non è scritto da nessuna parte. Sono curioso di vedere se si attiene alle regole 😉
Detto fra le righe: a chi si sta chiedendo come potrebbe essere un Operating Model per agenti IA nel proprio engineering, con requisiti, processo di change e Digital Thread, io e i miei colleghi di BHC e PROSTEP siamo felici di dare una mano.
Domande e risposte
Cos’è un Operating Model per agenti IA nell’engineering?
Il quadro in cui lavora un agente, indipendentemente dal singolo progetto: un metodo di engineering (nel mio caso basato sui modelli, architecture first), una piattaforma di engineering (Git, container, skill, controlli automatici) e una governance con convenzioni (diritti decisionali, processo di change, passaggi di consegna alla persona, denominazione). A questo si aggiunge un circuito di controllo che trasforma le esperienze del progetto in nuove regole.
In cosa si differenzia l’engineering agentico dal Vibe Coding?
Nel Vibe Coding si descrive a grandi linee cosa si vuole ottenere e ci si lascia sorprendere dal risultato. L’engineering agentico lavora invece su un Intent esplicito: requisiti con ID, decisioni documentate, richieste di modifica e verifiche, in modo che ogni risultato possa essere ricondotto al proprio requisito.
