Návrat extrémního programování

 Někdy počátkem tisíciletí si kolega kamarád Martin pověsil na stěnu naší kanceláře plakát s principy Extrémního Programování. "Začni jednoduše", "Nejprve testy", "Neboj se refaktorovat" a podobně. O agilních metodách jsme tehdy moc nevěděli, bylo to nové a teprve se to ve světě formovalo. Intuitivně jsme k podobným principům sice jako tým směřovali ("ty unit testy jsou super"), ale nešlo o nic metodického. Četli jsme o XP a diskutovali o zvláštních věcech, jako je párové programování.

"Co je to nesmysl? Budete ještě pomalejší, než jste teď, a to je co říct. Já platím dva lidi a oni si sednou k jedný klávesnici, to je fakt extrémní," zhodnotil tuto techniku náš šéf Tomáš. 
"Ale ten kód je kvalitnější, bude tam míň chyb, víc očí víc vidí. Navíc mu budeme líp společně rozumět," oponovali jsme mu.
Nepřekvapí příliš, že extrémní programování jsme v naší malé firmě tehdy neprosadili.

Mou krátkou zkušenost s párovým programováním si ale vybavuji i dnes: Během sezení nad klávesnicí se naše role střídaly mezi řidičem a navigátorem. Řidič psal kód, navigátor komentoval, byl v tu chvíli víc nad věcí. Když řidič nevěděl, kam dál, navigátor měl jasno, drapnul klávesnici a pokračoval.
S Martinem jsme si ujasnili několik sporných názvů tříd a metod (pojmenovávání věcí je, jak známo, jeden z největších problémů ve vývoji software). Vytvořili jsme během dlouhé diskuse nad několika málo řádky kódu sdílený mentální model, s nímž jsme byli oba spokojeni, a dokázali ho pak prosadit u ostatních. Rozdělili jsme si práci a většinu implementace pak napsali u vlastních klávesnic.
Byl to sice "pomalejší" způsob vývoje, zato ale byl *zásadnější*.

Přeskočme dvacet let do současnosti. Sdílení kódu je žádané, základní technikou agilního vývoje se staly pull requesty, tedy návrhy změn od jednoho vývojáře, které schvaluje jiný člověk z týmu. Pull requesty jsou, na rozdíl od párového programování, svou povahou asynchronní: Autor píše, když na to má čas, hodnotitel komentuje, když na to má čas. Oba odděleně u vlastních klávesnic. Komunikace a vytváření sdílených abstrakcí probíhá formou diskuse nad kódem.
Nepřekvapuje, že se tento způsob vývoje promítl i do nástrojů pro "Programování s AI": Člověk sází prompty a schvaluje pull requesty, velký jazykový model pak obstarává pracnou implementaci.

Při experimentech s Cursor AI přesně tohle očekávám. 
Snažím se nejprve krok po kroku budovat implementaci. Tuším, že čím podrobnější a uzavřenější mé prompty budou, tím lepší a zaměřenější pull requesty mi nástroj připraví. Nejsem pravý "vibe coder", jenž jedenkrát zavelí "Dej mi produkt, očekávám zázraky" a pak je ochoten brodit se tunami vyhalucinovaného kódu. Raději se smířím s tím, že budu postupovat krok po kroku.

Výsledky jsou překvapivě dobré. Cursor produkuje čitelný, dobře okomentovaný kód, přiléhavé názvy identifikátorů. Občas "ukročí stranou" a předloží pull request (což je v podání editoru změna existujícího kódu), který musím odmítnout, ale nikdy nejde o něco, co bychom si se Sonnet modelem nevysvětlili.
Nastává čas na odvážnější refaktorování, na větší změnu architektury. Protože jsem stále opatrný, rozdělím úpravu do dvou fází: V prvním promptu požaduji odstranění a výměnu jednoho podsystému za jakési statické lešení, které má pouze zajistit, aby celá stavba v mezikroku nespadla. Ve druhém promptu pak připravuji, že modelu vysvětlím, jak lešení nahradit funkčním podsystémem s novými vlastnostmi. Jako člověk bych podobně postupoval, s tím, že za "hotový stav" bych považoval až výsledek druhé fáze. 

Cursor mi ale do připraveného dvoufázového postupu hází vidle: Ve výstupu po prvním promptu dostávám implementaci obou fází! Je to, jako by LLM "nesnesl pomyšlení" na to, že v mezikroku je projekt napůl rozbitý, a tak pokračuje dál bez znalostí detailů druhé fáze a překvapivě se částečně trefuje do toho, co chci jako celkový výsledek.
Následuje upřesnění detailů z mé strany a ušetříme si i nějaký čas pro užitečnější úkoly, protože nemusím tolik ladit druhou fázi.
Ten okamžik znamená AHA moment v mé krátké zkušenosti s AI nástroji pro softwarový vývoj: LLM nemusí být jen otrokem, autistickým juniorem. A člověk nemusí být jen seniorem vydávajícím příkazy a schvalujícím pull requesty. Místo povelů je možno vést dialog se strojem rovnou nad kódem.

"Ale jen jestli si tu spolupráci s modelem příliš neantropomorfizuju," zakončuji celou historku nad kávou s dalším kolegou a kamarádem. "Snadno jeden zapomene, že má co do činění jen s hromadou čísel a astronomickým množstvím násobení a sčítání, k tomu sem tam nějaká ta nelinearita. Jazykový model, jakkoliv sofistikovaný, prostě nemyslí, to je jen naše snaha v tom myšlení vidět," ujišťuji sám sebe.
"No, dřív se tomu říkalo párové programování, vzpomínáš?" poznamenává kolega, jenž se náhodou jmenuje také Martin. A dále diskutujeme o tom, jak je dnes situace v některých aspektech podobná tomu, co se dělo v dávných dobách XP: Člověk je v roli navigátora v páru, určuje směr, LLM pak zastává roli řidiče, autora kódu. Oba hluboce sdílejí stejný kontext, oba znají současnou implementaci. Oba mají motivaci v tom, aby budovaný celek nepřetržitě fungoval, nebojí se rozsáhlých úprav.

Tentokrát je to ale, oproti původnímu párovému programování, extrémně rychlé. Soudobí Tomášové jistě ocení i fakt snížení nákladů za párek takových vývojářů: K mzdě navigátora postačí jen zaplatit podstatně méně peněz za to, že řidič se stal službou.
A ještě je tu jeden důležitý detail: Na rozdíl od původního párového programování se člověk se strojem v rolích řidiče a navigátora nestřídají.
Zatím.