Se nel tuo team gli agenti AI scrivono già una parte del codice, probabilmente conosci la sensazione: ogni sessione funziona in modo un po' diverso dalla precedente. Qualcuno dà istruzioni dettagliate, qualcuno no; qualcuno fa girare i test, qualcuno si fida dell'output. Il risultato è un'orchestrazione degli agenti AI fatta a mano, che dipende da chi siede alla tastiera.

Fabro è uno strumento open source nato proprio per questo: trasformare il modo in cui il team lavora con gli agenti in un processo scritto, ripetibile e verificabile. In questo articolo vediamo cos'è, come funziona, quando ha senso adottarlo e quali limiti tenere presenti prima di portarlo in un progetto reale.

Il problema: agenti potenti, processo fragile

Strumenti come Claude Code o Codex sono pensati per una sessione interattiva: chiedi, l'agente lavora, tu controlli. Va benissimo per un'attività isolata. Diventa più difficile quando vuoi che lo stesso flusso, per esempio "analizza il ticket, proponi un piano, implementa, fai girare i test, correggi", venga eseguito sempre allo stesso modo.

I sintomi tipici sono questi:

  • ogni sviluppatore ha il suo modo di guidare l'agente, e la qualità varia di conseguenza;
  • i controlli (test, linter, revisione) vengono saltati quando c'è fretta;
  • non resta traccia di cosa l'agente ha fatto, con quale modello e a quale costo;
  • si usa il modello più costoso anche per passaggi banali, o quello più economico per passaggi delicati.

Se hai letto il nostro articolo sulla differenza tra agente, LLM e harness, il punto è chiaro: il modello conta, ma conta altrettanto la struttura in cui lo fai lavorare.

Cos'è Fabro, in breve

Fabro si presenta come una "software factory" open source per ingegneri esperti. Il codice è su GitHub con licenza MIT, è scritto in Rust e si distribuisce come un singolo eseguibile, con un'API REST e un'interfaccia web.

L'idea centrale è semplice: invece di dare istruzioni all'agente ogni volta, descrivi il processo una volta sola come un grafo, e Fabro lo esegue coordinando agenti AI, comandi di shell e punti di approvazione umana.

Workflow come grafi versionati

I workflow si scrivono in formato Graphviz DOT, un linguaggio testuale per descrivere grafi. Ogni nodo è un passaggio (un agente, un comando, una verifica, una decisione umana) e gli archi definiscono l'ordine, i rami alternativi, i cicli e le parti che girano in parallelo.

Essendo testo, il workflow vive nel repository insieme al codice: si può rivedere in una pull request, confrontare tra versioni e migliorare nel tempo come qualsiasi altro file del progetto.

Le funzionalità principali

Dalla documentazione del progetto emergono alcune caratteristiche che lo distinguono:

  • Approvazioni umane nel flusso: il workflow si ferma dove serve una decisione, per esempio prima di passare dal piano all'implementazione. Puoi anche correggere la rotta di un agente mentre lavora.
  • Scelta del modello per ogni passaggio: con un foglio di stile in stile CSS assegni a ogni nodo il modello e il fornitore più adatto, con eventuali alternative in caso di errore. Un modello economico per riassumere, uno più capace per scrivere codice.
  • Verifiche integrate: test, linter, controlli sui tipi o un modello che fa da giudice possono essere nodi del grafo. Se falliscono, il flusso torna indietro a correggere.
  • Ambienti isolati: gli agenti possono lavorare in sandbox cloud usa e getta, con accesso SSH per il debug.
  • Checkpoint su Git: ogni fase registra le modifiche su un branch, così un'esecuzione si può riprendere, annullare o ricostruire.
  • Retrospettive automatiche: al termine di ogni esecuzione Fabro produce un riepilogo con costo, durata e file modificati.

Un esempio concreto di workflow

Il README del progetto mostra un flusso che rende bene l'idea. Proviamo a descriverlo applicato a una piccola modifica su un gestionale:

  1. Pianificazione: un modello economico legge la richiesta e la specifica, e propone un piano di intervento.
  2. Approvazione: il flusso si ferma e lo sviluppatore responsabile approva o corregge il piano.
  3. Implementazione: un modello più capace scrive il codice in una sandbox isolata.
  4. Verifica: girano test e linter; se qualcosa fallisce, l'agente torna a correggere.
  5. Semplificazione e revisione: un ultimo passaggio pulisce il codice e lo prepara per la revisione umana.

Nessuno di questi passaggi è nuovo. La differenza è che diventano obbligatori e tracciati, invece di essere affidati alla disciplina del singolo.

Vuoi portare gli agenti AI nel tuo ciclo di sviluppo? Possiamo partire da un flusso reale del tuo team e capire insieme dove un processo strutturato fa la differenza. Parliamone

Fabro e Spec-Driven Development

Un orchestratore funziona bene solo se sa cosa deve costruire. Qui entra in gioco lo Spec-Driven Development: prima si scrive una specifica chiara, condivisa e verificabile, poi gli agenti la implementano.

Le due cose si completano. La specifica dice cosa va fatto e come si capisce che è fatto bene; il workflow dice in che ordine, con quali controlli e dove serve una persona. Senza specifica, anche il grafo più elegante orchestra agenti che lavorano su richieste ambigue.

Quando ha senso adottarlo

Fabro non è uno strumento per tutti. Ha senso valutarlo se:

  • il tuo team usa già agenti AI in modo regolare e ha raggiunto i limiti dell'uso "a sessione";
  • ci sono attività ripetitive e ben definite (aggiornamenti di dipendenze, piccole feature su moduli stabili, correzioni a partire da ticket) che si prestano a un flusso standard;
  • hai una base di test e controlli automatici affidabile, perché è lì che il grafo trova i suoi punti di verifica;
  • ti serve tracciabilità: sapere cosa ha fatto l'agente, con quale modello e quanto è costato.

Probabilmente è prematuro se il team sta ancora sperimentando con gli agenti, se il progetto non ha test, o se ogni intervento è così diverso dal precedente da non poter essere descritto come un processo.

Errori comuni da evitare

Chi introduce un orchestratore tende a inciampare negli stessi punti:

  • Automatizzare un processo che non esiste: se oggi il team non ha un modo condiviso di lavorare, il grafo codificherà solo confusione. Prima si definisce il processo, poi lo si scrive.
  • Togliere le persone dal flusso troppo presto: le approvazioni umane sono il primo strumento di controllo. Meglio ridurle gradualmente, quando i dati delle retrospettive lo giustificano.
  • Fidarsi delle verifiche fatte da un modello: un LLM che fa da giudice è utile, ma non sostituisce test deterministici.
  • Sottovalutare la maturità dello strumento: il progetto è giovane, pubblicato nel 2026, ed evolve rapidamente. Conviene partire da un caso circoscritto e tenere d'occhio il changelog.
  • Ignorare i dati: codice e contesto passano per i fornitori dei modelli e per le sandbox cloud. Va verificato prima cosa può uscire dall'azienda e a quali condizioni.

Un dettaglio da sapere: il progetto non accetta pull request esterne. Segnalazioni e richieste passano dalle issue su GitHub e le modifiche vengono sviluppate dai maintainer. La licenza MIT consente comunque di farne un fork.

Come lo affrontiamo in Mine Consulting

Quando aiutiamo un team a portare gli agenti AI nel ciclo di vita del software, lo strumento è l'ultima scelta, non la prima.

  • Obiettivo condiviso: partiamo da un flusso concreto che oggi costa tempo o produce errori, e definiamo insieme come misurare se migliora.
  • Primo risultato da provare: scriviamo la specifica e il processo per quel solo flusso, con approvazioni umane dove servono, e lo facciamo girare su casi reali. Uno strumento come Fabro può essere il motore; a volte basta qualcosa di più semplice.
  • Percorso che continua: dalle retrospettive capiamo dove il flusso regge e dove no, e solo allora lo estendiamo ad altri casi o riduciamo i controlli manuali.

Trovi più dettagli su come lavoriamo.

In sintesi

  • Fabro è un orchestratore open source che descrive lo sviluppo con agenti AI come un grafo versionato, con approvazioni umane, verifiche e scelta del modello per ogni passaggio.
  • Il suo valore sta nel rendere il lavoro con gli agenti ripetibile e tracciabile, non nel renderlo più "autonomo".
  • Funziona meglio insieme a specifiche chiare e a una buona base di test.
  • È uno strumento giovane: conviene provarlo su un flusso circoscritto, valutando con attenzione dati e sicurezza.

Se stai pensando di strutturare lo sviluppo con agenti AI nel tuo team, parliamone.