Az AI-alapú fejlesztésnél nem az a fő kérdés, hogy egy csapat milyen coding assistantet használ. A valódi kérdés az, hogy van-e körülötte olyan módszertan, amely kordában tartja a sebességet.
Erre ad választ a BMAD framework, teljes nevén Build More Architect Dreams Method. A BMAD hivatalos dokumentációja alapján ez egy AI-driven development framework, amely az ötlettől és tervezéstől az implementációig strukturált workflow-kkal, specializált AI-ágensekkel és projektkomplexitáshoz igazodó tervezéssel támogatja a fejlesztést.
A BMAD nem egy újabb csoda AI-tool, hanem fejlesztési módszertan: kontextust, követelményeket, architekturális döntéseket, implementációs workflow-kat és review-pontokat rendez egy folyamatba.
Mikor érdemes BMAD-ben gondolkodni?
A BMAD-szerű működés akkor kezd igazán értelmet nyerni, amikor a fejlesztés már nem egy-két izolált feladatból áll. Tipikusan ilyenek a több sprinten átívelő fejlesztések, enterprise integrációk, legacy modernizációk, ügyfélportálok, belső workflow-rendszerek vagy AI-jal támogatott üzleti alkalmazások.
Néhány napos automatizálásoknál, egyfejlesztős prototípusoknál vagy egyszerű belső segédeszközöknél a teljes BMAD-folyamat könnyen túlzás lehet. Ilyenkor elég lehet néhány alapelvet átvenni: tiszta cél, rövid scope, dokumentált döntések és kötelező review.
Előbb kontextus, aztán kód
A BMAD egyik alapelve, hogy a fejlesztés nem kódgenerálással kezdődik. Először tisztázni kell, mit építünk, kinek, milyen üzleti célból, és honnan fogjuk tudni, hogy sikeres lett. Nagyvállalati környezetben ez különösen fontos, mert egy fejlesztés ritkán önálló sziget: meglévő rendszerekhez, integrációkhoz, adatmodellekhez és jogosultsági szabályokhoz kell illeszkednie.
Ezt szolgálja az Analysis Phase, a PRFAQ és a Product Brief.
Az Analysis Phase célja, hogy még a fejlesztés előtt kiderüljön: pontosan milyen problémát akarunk megoldani, kiknek készül a rendszer, milyen üzleti cél kapcsolódik hozzá, és milyen korlátok között kell gondolkodni.
A PRFAQ az Amazonból ismert „working backwards” gondolkodást hozza be: a csapat még a fejlesztés előtt úgy írja le a megoldást, mintha a termék már elindult volna. Megfogalmazza a rövid press release-t, majd megválaszolja a legnehezebb ügyfél- és üzleti kérdéseket. Ha ez nem meggyőző, a termék még nem áll készen a fejlesztésre.
A Product Brief rövid, vezetői szinten is értelmezhető összefoglalóba rendezi a lényeget: mi a cél, mi tartozik a scope-ba, milyen eredményt várunk, és milyen szempontok alapján döntjük el, hogy sikeres volt-e a fejlesztés.
Követelmények, architektúra és projektkontextus
A PRD, vagyis Product Requirements Document fordítja le az üzleti szándékot fejleszthető követelményekké: funkciókká, teljesítmény-, biztonsági, jogosultságkezelési, skálázhatósági és üzemeltetési elvárásokká.
A BMAD az architekturális döntéseket sem hagyja implicit tudásként a csapatban. Az Architecture Decision Recordokban rögzíthetők a fontos technikai választások: API-stílus, autentikáció, adatmodell, integrációs minta, tesztelési stratégia vagy deployment megközelítés.
Ehhez kapcsolódik a Project Context is: a projekt saját szabálykönyve. Ide kerülhet a stack, a repo-struktúra, a kódolási konvenció, a branch-stratégia és a tesztelési minta. Így az AI nem általános best practice-ek alapján dolgozik, hanem a konkrét rendszerhez igazodik.
Specializált AI-ágensek, nem általános asszisztens
A BMAD egyik szakmailag fontos, ugyanakkor a kommunikációban gyakran háttérbe szoruló eleme, hogy az AI-támogatás nem egyetlen, mindenre használt asszisztensként jelenik meg. A hivatalos BMAD-dokumentáció helyette specializált ágenseket definiál, amelyek mindegyike egy-egy fejlesztési szerepre van hangolva: van product manager, architect, developer, scrum master, QA és UX ágens, mindegyik saját feladatkörrel, elvárt outputtal és felelősségi határral.
Ennek az a haszna, hogy az AI-interakciók nem folynak össze ad hoc beszélgetésekké, hanem világos átadásokká válnak. Egy követelménytisztázási feladat a PM-ágenshez tartozik, egy architekturális döntés az architect-ágenshez, egy story-implementáció a developer-ágenshez – és minden átadáshoz dokumentált artifact kapcsolódik: PRFAQ, PRD, ADR, story. Ettől válik a fejlesztési folyamat nemcsak gyorsabbá, hanem visszakövethetővé és auditálhatóvá is.
Fontos azonban tisztán látni: ezek az ágensek nem helyettesítik az emberi szerepeket, hanem strukturált munkafelületeket adnak hozzájuk. Az AI az adott szerep gondolkodási sablonját és sebességét viszi, az ember a kontextust, a döntést és a felelősséget.
Hogyan változnak a csapatszerepek?
A BMAD tehát nem megszünteti a szerepeket, hanem eltolja a fókuszukat. A product owner feladata a pontosabb üzleti kontextus és priorizálás: az AI által generált PRFAQ-ot és Product Briefet ő pontosítja, és ő dönti el, mi kerül scope-ba. Az architect szerepe a döntések rögzítése és konzisztenciája: az ADR-tervezeteket validálja, és gondoskodik róla, hogy a megoldás a Project Contextben rögzített kerethez igazodjon. A fejlesztőé egyre inkább a developer-ágens által javasolt megoldások irányítása, validálása és integrálása.
A QA és security szerepek korábban kapcsolódnak be, mert a minőségi és biztonsági szempontokat már a követelményeknél, az architektúránál és a review-folyamatoknál érdemes beépíteni.
Review, kontroll és mérhető eredmény
Az AI-támogatott fejlesztés egyik kockázata, hogy gyorsabban keletkezik több ellenőrizendő kód. Ha a review-folyamat nem skálázódik ezzel együtt, technikai adósság, biztonsági rés vagy architekturális eltérés keletkezhet. Erről részletesebben írtunk az AI-kódolás valóságáról szóló cikkünkben is.
A BMAD ezért az ellenőrzést is keretezi. Az adversarial review nem egy udvariassági jóváhagyás, hanem tudatos hibakeresés: hol sérülhet az üzleti logika, hol gyenge a validáció, hol tér el a megoldás az architekturális döntésektől?
Ez kapcsolódik az automatizált Quality Gateway-ek szerepéhez is: AI mellett nemcsak a kódírást, hanem a minőségbiztosítási kontrollpontokat is rendszerszinten kell kezelni.
A BMAD-szerű működés hatását érdemes konkrét KPI-okkal mérni. Ilyen lehet a lead time, a cycle time, a review-ra visszadobott változtatások aránya, az éles környezetben talált hibák száma, az újranyitott ticketek aránya vagy az architekturális eltérések száma. A cél nem pusztán a gyorsabb kódolás, hanem az, hogy a delivery sebessége minőségromlás nélkül javuljon.
Az AI gyorsít, a fejlesztő irányít
A BMAD nem fejlesztők nélküli fejlesztési modell. Akkor működik jól, ha tapasztalt fejlesztők értelmezik a követelményeket, validálják az architektúrát, felügyelik az AI-javaslatokat, és döntést hoznak a vitás helyzetekben.
A Nitrowise AI-Powered Delivery Teamjeiben is ezt az elvet követjük: az AI-eszközök értéke nem önmagában a kódgenerálás, hanem a strukturált, fejlesztők által kontrollált delivery-folyamat.
A BMAD tanulsága nagyvállalati IT vezetők számára egyszerű: az AI-alapú fejlesztés nem attól lesz megbízható, hogy több eszközt vezetünk be, hanem attól, hogy jobb rendszert építünk köré. Kontextussal, követelményekkel, architekturális döntésekkel, review-val és emberi felelősséggel.
