Vlákno názorů k článku AI asistenti pro vývoj software: postupy vhodné pro programátory od Petr Steinbauer - Autore nezapomeň zmínit: bmad-code-org/BMAD-METHOD a podobný frameworky... BMAD-METHOD je...

Autore nezapomeň zmínit: bmad-code-org/BMAD-METHOD a podobný frameworky...

BMAD-METHOD je otevřený framework, který z obyčejného „psaní promptů“ udělá řízený, agilní proces: místo chaosu dostaneš virtuální AI tým (analytik, architekt, produkták, QA), který ti pomáhá sepsat specifikaci, navrhnout architekturu, rozbít práci na úkoly a dotáhnout kód do produkční kvality – stačí npx bmad-method a najednou máš vedle sebe nadšeného, ale disciplinovaného parťáka pro celý vývoj. Sám si kontroluje zadání a to třeba z 10 úhlů (kvalita, zadání od šéfa, od zákazníka, ...)

Všechno co tady popisujes mi reálně přijde jako pravěk, vlastně jsme ve stavu kdy píšeme jen spec (respektive epics a stories) a agenti makají.
Když je něco špatně, je špatně spec a docs.

Programuju 25 let - a dost to bolelo pochopit - že čumět do kódu je už de facto k ničemu...
Teda furt ho čtu, ale vždycky když mám touhu klepnout do něj, tak se plesknu přes prsty a nechám bmad udělat nový stories. Do kódu se prostě nesahá, tečka, fuj.

Jasně objeviš hnusy, ale NIKDY je neopravuji napřimo, ale zlepšuji zadání v docs.

Zkusil jsem i extrém že projekt který jsme popsali 3 měsíce jsem smazal a nechal agenty jej dle docs napsat znovu. A představ si za 12 hodin to odevzdal funkční a stejný, rozdíl prakticky neviditelný - což značí že docs byl napsaný spravně.

Za překlepy se omlouvám.

Kdybych na několika projektech z poslední doby, na kterých jsem pracoval fungoval vámi popsaným způsobem, nepracuji na nich už ani já, ani nefungují ty projekty. Bohužel. Současná AI má problémy i s chápáním poměrně jednoduchých struktur. Kdybych ji nepoužíval denně... Takhle jednoduché to tedy obecně opravdu není. Lze to aplikovat na určitě spektrum projektů, o tom žádná, ale typicky na projekty na zelené louce a často hlavně na věci, které se opakují stále dokola a které, mimochodem, žádný zlatý důl nejsou už dost dlouho.

Ostatně ve vývoji tvoří vlastní tvorba nových features tak 30 % mé práce. A to i na nově vyvíjených projektech a to jsem programátor, ne analytik nebo projekťák. O maintenance ani nemluvě.

14. 11. 2025, 16:28 editováno autorem komentáře

Tohle mi přijde hodně zajímavé. Jasná mi není jedna věc - já vždycky vnímal jako ultimátní specifikaci právě kód, (pokud je dobře napsaný). Snažím se co nejvíc invariant zakódovat do typového systému. Tím pádem se stává, že až při kódování nějakého zadání se zjistí, že překladač křičí a ukáže mi, že tohle zadání koliduje s nějakou jinou částí systému a je třeba předělat zadání. Vývoj SW je v mých očí vlastně manageování komplexity - snažím se systém popsat na stovkách tisíc řádek tak, aby byl v rámci možností uchopitelný, srozumitelný, dobře dekomponovaný, funčnost ověřitelná.

Když budu mít specifikaci psanou - ve srovnání s kódem - volně, v BMAD, přijdu vlastně o jazyk, který mi umožňuje vyjádřit se zcela precizně (programovací jazyk), jazyk pro popis invariant systému (statický typový systém), strojové ověřování (unit testy) - jak hodně potom můžu věřit tomu, že když agentům řeknu, ať z BMAD specifikace udělají výsledek, dostanu potom opravdu to co chci? A že to zadání je vnitřně nerozporné?