Quando usi un coding agent, la tentazione più naturale è partire dal risultato.
“Costruiscimi un’applicazione che faccia questo.“
Descrivi la funzionalità, magari indichi linguaggio e framework preferiti, lasci che l’AI cominci a lavorare. Dopo poco compaiono la struttura del progetto, il database, alcune API, l’interfaccia, forse anche una prima serie di test.
Il risultato può essere impressionante.
Il problema è che, mentre guardi il codice apparire, quasi tutte le decisioni che hanno prodotto quel codice restano invisibili.
Perché è stato scelto quel modello dati? Quali casi d’uso sono stati considerati prioritari, e quali esclusi? Quali assunzioni sono state fatte su sicurezza, numero di utenti, mantenimento nel tempo?
In molti casi, nessuno lo sa davvero. Il modello ha incontrato degli spazi vuoti e li ha riempiti con decisioni plausibili. Ma una successione di decisioni plausibili non è automaticamente un progetto coerente.
Il prompt engineering comincia a stare stretto
Per molto tempo abbiamo parlato di prompt engineering: assegnare un ruolo ad un modello di LLM, descrivere il risultato desiderato, aggiungere vincoli, fornire esempi. Questa procedura continua ad essere utile, un prompt migliore produce una risposta migliore. Ma quando l’AI non deve scrivere una funzione, bensì contribuire a costruire un intero prodotto, il prompt è solo l’inizio del problema.
Si è cominciato a parlare di context engineering: non dare solamente un’istruzione, ma fornire all’AI un contesto, architettura, convenzioni, decisioni precedenti, requisiti, codice esistente. Un passo avanti reale. Ma il contesto dice all’AI cosa deve sapere. Non stabilisce quali decisioni vadano prese, in che ordine, da chi vadano verificate.
Con project engineering si intende il processo attraverso cui un’intenzione diventa un progetto governabile: chiarire il problema, distinguere obiettivi da funzionalità, definire cosa non verrà costruito, rendere espliciti i vincoli, prendere decisioni architetturali, suddividere il lavoro, stabilire criteri di accettazione.
Il prompt produce una risposta. Il project engineering costruisce il sistema di decisioni vincolanti dentro cui quella risposta deve avere senso.
Quando l’AI riempie uno spazio vuoto, sta decidendo
Immagina di chiedere a un agente di sviluppare un’applicazione per creare e pubblicare moduli online. Sembra chiaro: editor, tipi di campo, un database per le risposte, una modalità di embed. L’AI può partire subito in quarta.
Deve però decidere se i moduli siano modificabili dopo la pubblicazione, se le modifiche alterino anche le risposte già raccolte, se un modulo appartenga a una persona o a un’organizzazione. Deve stabilire i permessi, cosa succede quando un utente lascia un team, quanto conservare i dati, cosa significhi davvero “eliminare” una risposta. Poi deve decidere come gestire l’embed dentro una Content Security Policy restrittiva, cosa mostrare con rete lenta, come evitare doppie sottomissioni.
Bada bene: nessuna di queste decisioni era nella richiesta iniziale. Il modello deve fermarsi e chiedere, oppure inventare una risposta ragionevole. Molto spesso inventa, non perché sia incapace, ma perché il suo compito è produrre qualcosa.
Il codice risultante può funzionare perfettamente e, allo stesso tempo, incorporare decine di decisioni che nessuno ha consapevolmente approvato. Il problema non è solo che l’AI possa generare codice sbagliato. Può generare molto velocemente il codice corretto per un progetto che non abbiamo mai deciso di costruire.
A che punto entra in gioco BMAD?
La documentazione di BMAD organizza il lavoro in quattro fasi: analisi, pianificazione, solutioning, implementazione. L’analisi può essere facoltativa. La pianificazione definisce cosa costruire e, soprattutto, per chi. Il solutioning rende esplicite le decisioni tecniche e suddivide il lavoro. L’implementazione trasforma le stories in codice verificato. Gli artefatti di una fase alimentano quella successiva: product brief, PRD, spec UX, documento architetturale, epic, stories, criteri di readiness, code review, retrospettiva.
Non ogni modifica deve attraversare tutta la catena. Per una correzione locale e ben definita, BMAD ti fa entrare direttamente nel processo di build. Per un’iniziativa più ampia, costruisci prima il contesto attraverso requisiti, UX, architettura. La profondità del processo dovrebbe dipendere dal rischio e dalla complessità, non dalla voglia di produrre documentazione.
BMAD presenta agenti con ruoli distinti: business analyst, product manager, UX designer, system architect, senior engineer. Personalmente considero i nomi e le personalità la parte meno importante. Dare un nome a un prompt non crea automaticamente competenza. Il valore sta nella separazione delle responsabilità: l’agente che analizza il problema non dovrebbe giustificare contemporaneamente l’architettura che ha già deciso di implementare. Le stories dovrebbero derivare da requisiti e architettura, non essere inventate mentre si scrive il codice.
Non si tratta di simulare una riunione tra personaggi virtuali. Si tratta di impedire che analisi, progettazione, implementazione e verifica si confondano dentro la stessa risposta.
Il vero valore di BMAD è la “frizione utile“
Gli strumenti di sviluppo assistito dall’AI hanno eliminato una grande quantità di attrito: non serve più preparare manualmente ogni file, cercare la sintassi di una libreria, scrivere da zero righe ripetitive. Un vantaggio enorme.
Ma abbiamo eliminato anche parte della frizione che costringeva le persone a pensare prima di costruire. Quando produrre una feature richiedeva giorni, qualcuno tendeva almeno a chiedersi se fosse davvero necessaria. Oggi una direzione può essere implementata così velocemente da farci dimenticare di verificarla.
Da questo punto di vista, la funzione più importante di BMAD non è accelerare ulteriormente il codice. È reintrodurre punti in cui il progetto deve fermarsi e spiegare sé stesso. Qual è il problema? Come sapremo di averlo risolto? Quali assunzioni stiamo facendo? Cosa non farà il prodotto? Cosa dovrà essere dimostrato prima di considerare completata una story?
Questa frizione sembra una perdita di tempo solo fino al momento in cui impedisce di implementare perfettamente la cosa sbagliata.
Gli artefatti non devono diventare documenti decorativi
C’è un rischio opposto, altrettanto reale. Una volta scoperto che l’AI produce rapidamente PRD, documenti architetturali, user story, si può finire per generare una quantità enorme di documentazione senza aver preso una sola decisione vera. Il documento appare professionale, ha sezioni, tabelle, requisiti numerati. Questo non significa che sia vero.
Una specifica generata dall’AI può contenere assunzioni non verificate esattamente come il codice, e può essere ancora più pericolosa: una volta trasformate in documento formalmente autorevole, quelle assunzioni cominciano a essere usate come se fossero requisiti approvati. L’errore non appartiene più a una singola risposta. Diventa contesto per tutte le risposte successive.
La documentazione recente di BMAD riconosce questo problema esplicitamente: il project context non dovrebbe essere una grande descrizione del repository, ma una quantità ridotta di informazioni verificate che l’agente non può ricavare direttamente dal codice: convenzioni non ovvie, vincoli organizzativi, aree pericolose, motivazioni dietro certe decisioni. Il contesto dovrebbe contenere ciò che il codice non può spiegare. Un documento non è utile perché è lungo. È utile se modifica correttamente il comportamento di chi lo usa. Tutto il resto è rumore a cui abbiamo attribuito autorità.
Come userei BMAD in un progetto reale
Per un progetto nuovo e sufficientemente complesso, partirei dall’intenzione, non dalla lista di funzionalità: chi userà il prodotto, quale problema risolve, cosa succede oggi in sua assenza.
Subito dopo definirei i non-obiettivi. È uno dei modi più efficaci per impedire all’AI di espandere continuamente il progetto: dire cosa il sistema non farà riduce lo spazio in cui il modello può inventare una soluzione apparentemente utile.
Userei il PRD come strumento di interrogazione, non come consegna automatica. Il compito dell’agente non è riempire tutte le sezioni, è individuare contraddizioni, decisioni mancanti, requisiti impossibili da verificare. Quando un’informazione non esiste, va segnata come sconosciuta, non trasformata in una risposta plausibile.
Solo dopo passerei all’architettura vera e propria: le decisioni che attraversano più parti del sistema, le alternative considerate, le conseguenze da accettare. Se un agente usa REST, un altro GraphQL, un terzo introduce una seconda libreria per lo state management, il problema non è che uno abbia sbagliato: è che nessuno ha stabilito quale decisione appartenesse al progetto e quale potesse essere lasciata alla singola implementazione.
Le epic e le stories andrebbero create solo dopo che queste decisioni hanno raggiunto un livello sufficiente di stabilità, ciascuna con casi di errore, condizioni di accettazione, prove necessarie per dichiararla completata.
E poi userei il processo di build una story alla volta. Non perché l’AI sia incapace di implementarne dieci insieme, ma perché la capacità di generare molto codice non coincide con la capacità umana di verificarlo.
Un progetto esistente non è un progetto nuovo con più file
BMAD si può usare anche su codebase esistenti, ma qui il problema cambia. In un progetto nuovo descrivi cosa il sistema dovrà diventare. In un progetto esistente devi prima capire cosa il sistema è realmente, e le due cose non vanno confuse.
Una codebase con anni di storia contiene convenzioni, eccezioni, aree congelate, decisioni delle quali potrebbe non esistere più una spiegazione completa. Parte della documentazione può essere obsoleta, o descrivere l’intenzione originaria e non il comportamento attuale.
Il flusso brownfield di BMAD parte dalla scansione del codice, verifica le informazioni contro ciò che esiste realmente, e chiede all’essere umano soprattutto ciò che non può essere dedotto: vincoli organizzativi, landmine, aree da non toccare. Il risultato dovrebbe essere un piccolo nucleo di contesto verificato, non una nuova montagna di documenti generati.
In un progetto legacy il codice e la configurazione sono la prova di cosa il sistema fa. La documentazione è una fonte da verificare, non una verità da imporre al codice. Se mescoli le due cose, l’agente può modificare il sistema come se una decisione desiderata fosse già implementata, oppure continuare a rispettare una regola che il progetto ha abbandonato anni prima. Un contesto sbagliato non rende l’AI meno informata. La rende più sicura mentre procede nella direzione sbagliata.
Quello che BMAD non può fare
BMAD può obbligare una decisione a essere scritta. Non può obbligarla a essere intelligente.
Può separare il lavoro di un business analyst da quello di un architect e di un developer, ma questi ruoli possono essere eseguiti dallo stesso modello, con le stesse informazioni incomplete e gli stessi punti ciechi. Cinque agenti che condividono un’assunzione sbagliata non sono cinque verifiche indipendenti. Sono un errore ben coordinato.
Può inoltre produrre specifiche molto convincenti anche quando il problema iniziale è stato descritto male. Nessun workflow elimina il giudizio umano.
C’è anche il rischio che l’approvazione diventi un rituale: l’agente produce un documento, l’essere umano lo scorre velocemente, preme “continua”, e interpreta il passaggio attraverso il workflow come validazione. Ma un gate che viene sempre attraversato non è un controllo. È solo una schermata aggiuntiva.
Lo stesso vale per la code review: se il codice viene generato da un agente e revisionato da un secondo agente che condivide lo stesso contesto, la revisione può essere utile, ma non sostituisce test indipendenti, analisi statica, controlli di sicurezza, e la capacità del team di spiegare cosa sta mettendo in produzione.
BMAD può ridurre l’architettura accidentale. Non garantisce una buona architettura. Può migliorare la tracciabilità. Non garantisce la verità. Può organizzare il lavoro. Non può assumersi la responsabilità delle conseguenze.
Il developer non scompare: cambia dove produce valore
Se l’AI diventa progressivamente più capace di implementare, il valore dello sviluppatore non si riduce alla quantità di codice che scrive manualmente. Si sposta verso la capacità di mantenere coerente il progetto.
Non significa trasformare ogni developer in un project manager che sposta ticket su Jira. Significa capire il problema, riconoscere le assunzioni nascoste, valutare un compromesso architetturale, stabilire quali decisioni vadano centralizzate, impedire che il codice si allontani dall’intenzione senza che nessuno se ne accorga.
Paradossalmente, più l’AI diventa capace di produrre software, meno possiamo permetterci di essere vaghi. Il codice può crescere molto più velocemente della nostra capacità di comprenderlo. Il project engineering serve a impedire che questa distanza diventi permanente.
BMAD è un’impalcatura, non il progetto
Il valore di BMAD non è l’illusione di avere improvvisamente un’intera azienda fatta di agenti artificiali. È offrire un’impalcatura: costringe l’intenzione a diventare requisito, il requisito a confrontarsi con l’architettura, l’architettura a produrre unità di lavoro verificabili.
Usato bene, rende visibili decisioni che altrimenti resterebbero sepolte nella cronologia di una conversazione. Usato male, diventa una fabbrica di documenti attraverso cui l’AI approva progressivamente le proprie assunzioni.
La differenza non la fa il framework. La fa la persona che interrompe il processo quando una risposta è elegante ma non convincente, quando un requisito è completo ma non verificato, quando un’architettura è tecnicamente possibile ma inadatta al progetto.
Il vero salto non è passare da un prompt a cinque agenti. È passare da una successione di risposte a un sistema di decisioni. L’AI può contribuire a scrivere il product brief, il PRD, l’architettura, le story, il codice, i test. Quello che non può fare al nostro posto è decidere se siamo disposti ad assumerci la responsabilità del sistema che tutte quelle parti, insieme, stanno costruendo.
Ed è esattamente lì che comincia il project engineering.