Autor: Kwame Boateng
Kódování s pomocí AI se často popisuje jako rychlejší verze párového programování. Toto srovnání je nyní příliš úzké. Když agent dokáže prozkoumat repozitář, změnit několik souborů, spouštět nástroje, vygenerovat náhled a otevřít pull request, hlavním problémem spolupráce už není pouze „Dokáže psát kód?“ Zní spíše: „Mohou lidé vidět, zkontrolovat, schválit a později zrekonstruovat, co se stalo?“
Proto může být nejdůležitějším posunem v návrhu softwarových týmů využívajících agenty přechod od soukromých promptů k viditelným pracovním prostorům. Slack Code je například popisován jako kombinace projektových kanálů s kódovacími agenty, auditu rozdílů v kódu, živých náhledů HTML, pracovních postupů pro zpětnou vazbu a schvalování, automatické archivace a auditních protokolů. Aplikace GitHub Copilot také přidala panel „My work“ pro organizaci issues a pull requestů napříč projekty. Tyto funkce směřují k praktickému principu: práce agenta by měla vypadat méně jako neprůhledná odpověď a více jako sada změn procházející řízeným výrobním procesem.
Chat není záznamem práce
Konverzace s agentem může být užitečná při zkoumání nápadu, ale jako systém záznamů je slabá. Důležité podrobnosti mohou být ukryté v dlouhém vlákně: které soubory se změnily, které příkazy se spustily, jaké předpoklady agent učinil, co kontrolor odmítl a zda se konečný výsledek liší od prvního návrhu.
Trvalý pracovní prostor tyto podrobnosti zpřístupňuje ke kontrole. Měl by propojit požadavek s konkrétním repozitářem nebo projektem, uchovat plán agenta, zobrazit akce nástrojů a změny souborů, odkazovat na testy a náhledy a zaznamenat, kdo výsledek schválil. Přesné rozhraní se může lišit — nástroj pro sledování issues, pull request, kanál pro spolupráci nebo konzole agenta — informace by však měly zůstat zachovány i po skončení relace.
Na tom záleží z běžných technických důvodů, nejen kvůli dodržování předpisů. Pokud se o dva týdny později objeví chyba, tým potřebuje více než konečný diff. Možná bude potřebovat znát původní požadavek, vygenerovaný plán, důkazy z testů, komentáře kontrolora a to, zda člověk výslovně přijal riskantní kompromis. Trvalý záznam toto vyšetřování zkracuje.
Pět vrstev viditelné práce
Týmy zavádějící kódovací agenty mohou každou změnu chápat jako malý, kontrolovatelný spis. Zvláště užitečných je pět vrstev:
- Záměr: issue, akceptační kritéria, omezení a požadovaný rozsah.
- Plán: navrhovaný postup agenta před úpravou souborů. U netriviální úlohy jde o kontrolní bod pro schválení, nikoli o dekoraci.
- Diff: přesné přidání, odstranění, změny závislostí, úpravy konfigurace a vygenerované prostředky.
- Důkazy: výsledky testů, výstup linteru, bezpečnostní kontroly, snímky obrazovky a tam, kde je to relevantní, živý nebo nasaditelný náhled.
- Záznam rozhodnutí: komentáře kontrolora, požadované změny, schválení, zamítnutí, návrat změn nebo navazující práce.
Smyslem není nutit každou změnu procházet těžkopádným výborem. Překlep a změna platebního toku by neměly podléhat totožným kontrolám. Jde o to, aby úroveň kontroly odpovídala potenciálnímu dopadu.
Schválení by měla být propojena s akcemi
„Člověk ve smyčce“ je příliš vágní na to, aby šlo o užitečnou kontrolu. Člověk může schválit plán, aniž by viděl výsledný diff, nebo schválit změnu kódu, aniž by si všiml, že agent zároveň upravil soubor pro nasazení. Lepší pracovní postupy jasně stanoví, co schválení umožňuje.
Tým může například agentovi povolit automatické čtení repozitáře a spouštění lokálních testů, vyžadovat schválení před zápisem mimo určenou větev a samostatné schválení před sloučením nebo nasazením. Agent může navrhnout migraci databáze, ale může mu být zakázáno ji provést v produkci. Navrhovaný přístup SAE ke klasifikaci úloh, které mohou agenti dokončit oproti úlohám, které mohou pouze doporučit, odráží tento širší vzorec: autonomie by měla být přidělována podle úlohy, nikoli globálně předpokládána.
Schválení také potřebují rozsah a dobu platnosti. Schválení pro „aktualizaci textu úvodní stránky“ by nemělo mlčky opravňovat k přidání nového analytického balíčku. Plán schválený včera by dnes neměl automaticky pokrývat podstatně změněný diff. Rozhraní by mělo tyto hranice zviditelnit.
Náhledy mění kontrolu v prohlížení
Kontrola kódu je často snazší, když lidé mohou výsledek prohlédnout, místo aby jej odvozovali ze zdrojových souborů. Živý náhled HTML může odhalit rozbité rozestupy, chybějící stavy, nepřístupné ovládací prvky nebo nechtěnou změnu navigace, kterou by kontrolor mohl v textovém diffu přehlédnout.
Náhledy nejsou důkazem správnosti. Měly by stát vedle testů a kontroly zdrojového kódu, nikoli je nahrazovat. Vytvářejí však společný objekt k diskusi: kontrolor může ukázat na konkrétní obrazovku, stav nebo interakci a připojit zpětnou vazbu k navrhované změně.
To je obzvláště cenné, když se kontroly účastní i odborníci mimo technickou oblast. Produktový manažer nemusí být schopen posoudit změnu frameworku, ale může být tím správným člověkem k potvrzení, že pracovní postup odpovídá požadavku. Designér může ověřit vizuální regresi. Bezpečnostní specialista se může zaměřit na oprávnění a nakládání s daty. Pracovní prostor s podporou agentů může každou otázku směrovat k osobě, která je nejlépe připravena na ni odpovědět.
Diffy potřebují kontext, nejen barvy
Známý diff v červené a zelené barvě zůstává nezbytný, ale změny generované agentem mohou být natolik rozsáhlé, že kontrolora zahltí. Týmy by měly agentům zadávat, aby commity nebo skupiny změn udržovali úzce vymezené, vysvětlili, proč se změnil každý podstatný soubor, a samostatně označili generované soubory nebo soubory dodavatelů.
Užitečné otázky pro kontrolu zahrnují:
- Jaké chování viditelné pro uživatele se změnilo?
- Které soubory byly změněny pouze na podporu implementace?
- Jaké předpoklady učinil agent ohledně stávajícího chování?
- Které testy byly přidány, upraveny nebo nebyly spuštěny?
- Mohla by tato změna ovlivnit oprávnění, uchovávání dat, účtování nebo externí API?
Tyto otázky mění kontrolu z vágní žádosti „podívej se na to“ na opakovatelné prověření. Pomáhají také odhalit běžný způsob selhání: zdánlivě věrohodnou funkci doprovázenou neúplnou aktualizací testů nebo nechtěnou změnou konfigurace.
Archivujte důležité zdůvodnění
Uchovávání každého tokenu každé konverzace s modelem není automaticky užitečné. Dlouhé historie mohou být nákladné na ukládání a obtížně prohledatelné, zatímco výzkum kompakce kontextu varuje, že shrnutí mohou ztratit důležité informace. Praktická auditní stopa by proto měla uchovávat artefakty relevantní pro rozhodování, nikoli bez rozdílu ukládat vše.
Minimálně uchovávejte požadavek, schválený plán, výsledný diff, výsledky nástrojů a testů, odkaz na náhled nebo nasazení, rozhodnutí kontrolujících a případné udělené výjimky. Pokud agent použil externí zdroje nebo načetl interní dokumenty, zaznamenejte příslušné odkazy na zdroje a okamžik, kdy ovlivnily změnu. U vysoce rizikové práce může být opodstatněné uchovat úplný záznam interakce a provedení.
Tam, kde to vyžaduje závažnost situace, zajistěte, aby záznamy umožňovaly odhalit neoprávněné změny, a pravidla uchovávání definujte ještě před krizí. Auditní stopa, která zmizí při archivaci kanálu — nebo nedokáže rozlišit upravený výsledek od původního — nebude oporou při seriózním vyšetřování.
Co to znamená pro kariéru v softwaru
Nově vznikající dovedností není jen psaní lepších promptů. Jde o navrhování práce tak, aby ji jiný člověk mohl prověřit a důvěřovat jí. Vývojáři si budou muset osvojit pohodlí při stanovování akceptačních kritérií, rozkládání úkolů, kontrole diffů ve velkém měřítku, vytváření smysluplných testů a rozhodování, kdy se agent musí zastavit a zeptat.
Odborníci na produkt a design budou mít větší úlohu při kontrole náhledů a upřesňování záměru. Inženýři kvality mohou pomoci definovat schvalovací brány a chybové scénáře. Engineering manažeři budou muset měřit průchodnost, aniž by odměňovali neviditelné riskování. Techničtí spisovatelé a specialisté na provoz mohou přispět tím, že zajistí trvalost rozhodnutí, výjimek a provozních příruček.
Užitečným cvičením je vzít běžnou funkci a zmapovat řetězec důkazů: požadavek, plán, větev, diff, testy, náhled, schválení, vydání a návrat zpět. Poté se ptejte, kde by budoucí kolega byl nucen hádat. Každý takový odhad je kandidátem na lepší pracovní prostor, jasnější oprávnění nebo trvalejší záznam.
Jednoduché provozní pravidlo
Nechte agenty pracovat rychle v rámci viditelného a vratného prostoru. Poskytněte jim vymezený pracovní prostor, omezte citlivé akce, vyžadujte schválení na významných hranicích, připojte ke změně důkazy a uchovejte konečné rozhodnutí. Cílem není zpomalit automatizaci natolik, aby připomínala ruční programování. Jde o to, aby rychlost byla slučitelná s odpovědností.
Při vývoji s podporou agentů není nejlepším spolupracovníkem systém, který izolovaně vytvoří nejvíce kódu. Je jím systém, jehož práci lze pochopit, zpochybnit, schválit, vrátit zpět a poučit se z ní.
