Philippe Martin presenta il metodo BMAD (Breakthrough Method for Agile AI-Driven Development) come un "piano regolatore urbanistico" essenziale per strutturare l'uso dell'IA agentica nel ciclo di vita dello sviluppo software, in contrapposizione al "vibe coding", che genera un debito tecnico esplosivo.
Il problema: dall'arrivo degli LLM, molti team hanno adottato un approccio "a sensazione" con l'IA — prompting, recupero di codice, aggiustamenti manuali, si ricomincia da capo. Nel breve termine, è entusiasmante. Nel lungo termine, è come lasciare che ogni sviluppatore negozi da solo con un appaltatore: ampliamenti ovunque, nessun piano d'insieme, un impianto elettrico pronto a prendere fuoco.
La risposta di BMAD: organizzare gli agents IA come una squadra di cantiere disciplinata. Ogni agente svolge il ruolo di caposquadra specializzato: un agente chiarisce il requisito e produce una specifica reale anziché un prompt vago, un architetto propone opzioni allineate agli standard, gli "artigiani" generano codice, test e documentazione, e i controllori monitorano difetti e regressioni. L'essere umano resta architetto capo e project owner: definisce la visione, i vincoli non negoziabili, e prende le decisioni strutturanti.
Integrazione nell'SDLC: l'autore propone tre punti di inserimento. A monte, gli agenti trasformano un'intenzione di business in un PRD strutturato molto più rapidamente. Nel mezzo, propongono architetture e generano codice all'interno di un framework definito — "non si chiede all'IA di 'scrivermi un'app', le si chiede di 'implementare questo modulo all'interno di questo design preciso'". A valle, gli agenti monitorano, analizzano i log e alimentano un backlog di debito tecnico prioritizzato.
Legacy e debito tecnico: BMAD spinge i team ad affrontare la struttura piuttosto che lo strato di vernice. Gli agenti mappano il codice, identificano le aree a rischio e propongono refactoring progressivi. La generazione sistematica di test e documentazione aiuta a ridurre il backlog.
Evoluzione dei ruoli: l'analogia del pilota automatico in aviazione illustra la trasformazione — il pilota non è scomparso, ma il mestiere è cambiato. Gli sviluppatori diventano progettisti di soluzioni e revisori esigenti, gli architetti orchestrano un sistema in cui i vincoli aziendali vengono iniettati negli agenti, e i manager imparano a inquadrare il problema e a valutare il valore prodotto dalla catena ibrida.
Raccomandazioni: iniziare dalle regole del gioco prima degli strumenti, scegliere casi d'uso pilota concreti, misurare e comunicare i risultati, e accettare che il framework evolverà — proprio come un buon piano urbanistico permette di rinnovare una città senza doverla demolire ogni volta.