Myslitelé

Vaše systémy už mají slepá místa. AI je jen zhoršuje.

mm
Přidejte Unite.AI mezi své preferované zdroje na Google

V roce 2022, ještě před tím, než se generativní nástroje pro kódování staly součástí naší každodenní inženýrské práce, jsem napsal o mé filozofii výběru nástrojů. Stálo to lépe, než jsem očekával. Tehdy jsem argumentoval, že je třeba začít s problémy, které skutečně řešíte, znát své slabiny a upřednostnit, jak nástroje používáte, místo abyste se jen vrhli na jakýkoli nástroj, který zní nejlépe, a doufali, že to funguje. Poznejte sebe a své cíle, abyste si mohli nastavit správná očekávání od svých nástrojů.

V té době jsem přemýšlel o rozrůstání SaaS, ne o kódu generovaném AI. Dnes je však má filozofie ještě naléhavější a důležitější ji dodržovat.

Mnoho z nás si přečetlo 2025 DORA report, který zjistil, že na rozdíl od předchozího roku adopce AI nyní pozitivně koreluje s propustností dodávek. Zjištění pod tím bylo, že nestabilita dodávek stále roste, a testovali, zda rychlostní zisky tuto situaci kompenzují. Ne. To odpovídá naší zkušenosti. Náš tým přijal agentický vývoj softwaru a zaznamenal 48 % nárůst propustnosti během dvou čtvrtletí, následovaný 16 % nárůstem problémů se stabilitou. Deset lidí je malý vzorek, ale je to také vzorek, ze kterého mohu vidět celý obraz, a vzorec se potvrdil. 

Adopce AI už není otázkou. Buďte právě na začátku, nebo už jste uprostřed. Co je nyní jiné, je to, že od inženýrských vedoucích se očekává, že AI adoptují a také prokáží, že se vyplácí. CEO, představenstvo i finance chtějí vědět, jak optimalizovat jejich investice do AI. Ptají se, zda vybrané nástroje skutečně efektivně řeší reálné problémy. 

Mezera tam vždy byla. AI ji jen rozšířila.

Jako CTO trávím značnou část času rozhovory s dalšími inženýrskými vedoucími, včetně zákazníků, potenciálních klientů a kolegů, abychom porovnávali úspěchy a stížnosti ohledně toho, co zažíváme s AI. Po dostatečném počtu těchto rozhovorů jsem začal vnímat vzorce v adopci AI a jejích výsledcích.

Hlavní pozorování není moje. DORA to uvádí už dva roky: AI zesiluje vše, co se v organizaci již děje, jak silné stránky, tak slabiny. Tým s čistou architekturou a zdravými revizními návyky je rychlejší. Tým, který se sotva vyrovnal s chaotickým technickým dluhem jen natolik, aby mohl nasadit kód, nyní zjistí, že technický dluh roste a stává se hlavní překážkou. Co však tento rámec opomíjí, je důvod, proč to tolik týmů překvapuje. AI tyto slabiny neukryl; systémy, na které jsme se spolehli, je nikdy neodhalily.

Řetězec ticketů a reportování, na kterém většina inženýrských organizací funguje, byl vytvořen k odpovídání na otázky, které lidé mají, lidskou rychlostí, lidmi, kteří přibližně chápali, co \”dokončeno\” znamená pro daný úkol. Nikdy to nebyl dokonalý záznam. Vždy to byla aproximace, doplněná někým, kdo shrnul něco složitějšího pod tím. Nyní AI přidává objem a nové vstupy, které generují novou aktivitu. Žádný ze systémů (nebo nástrojů) používaných pro tradiční, ne‑AI vývoj nebyl pro to nikdy navržen.

Nicméně stále neseme odpovědnost za stejné cíle. Stále řídíte rychlost, kvalitu, náklady a skutečný stav svého týmu. Už nemůžete brát loňské dashboardy jen na víru.

Existuje zde oprávněná výhrada. DORA’s 2026 ROI report popisuje J‑křivku: pokles produktivity těsně po adopci, způsobený křivkou učení, náklady na ověřování kódu generovaného AI a následnými procesy, které ještě nedošly do tempa. Nazývají to „náklady na výuku“ transformace a varují vedoucí, aby to nepomýlili s neúspěchem. Spravedlivé. Ale náklady na výuku a skutečný problém vypadají na dashboardu z ticketů stejně. Pokud nedokážete rozpoznat, ve které situaci jste, neprojevujete trpělivost. Hádate.

Musíme se vrátit k základům. Poznejte sebe. Poznejte svůj tým. Poznejte, jaké problémy řešíte. 

Jak se s AI „poznáte“?

Z mých rozhovorů jsem identifikoval pět hlavních oblastí, kde konvenční systémy, vytvořené pro lidsky generovanou a lidsky hlášenou práci, jsou slepé. Ignorovat je znamená riskovat zesílení vašich slabin při dalším nasazování AI.

Slepé místo 1: Divadlo rychlosti

Více commitů a více PR může působit jako pokrok, a často i je. AI automaticky zvyšuje oba počty. Stanford case study ukázala, že adopce AI zvýšila počet PR o 14 %. Co však chybí, je, kolik z této aktivity představuje funkční vývoj, který se nasadí, oproti údržbě, přepracování nebo otřesům z refaktoringu, který nevytrval.

Abyste to řešili, sledujte rozdělení mezi vývojem funkcí a údržbou a sledujte frekvenci nasazení a dobu dodání oproti vlastní historické základně, ne oproti průměru odvětví. Bez tohoto rozdělení hlásíte pokrok, který nemůžete skutečně podložit.

Slepé místo 2: Dluh revizí

Kapacita revize se automaticky nezvětšuje spolu s výstupem. Daň za ověřování není fází, kterou překonáte; je součástí stálých nákladů na agenturní vývoj. A nedávný průzkum vedoucích inženýrů zjistil, že 80 % týmů věnuje alespoň 10 % svého času revizi a přibližně jeden z deseti věnuje více než 40 %. Při takovém zatížení týmy kolísají mezi rostoucími backlogy a mechanickým schvalováním, což není skutečné řešení.

Omezení při vydávání už není rychlost, jakou se kód píše. Jde o to, jak rychle může člověk skutečně mít jistotu, že změna je správná, jak rychle a přesně lze detekovat a řešit chyby. Sledujte, jak je zátěž revize skutečně rozložena mezi vaším týmem; jinak riskujete přetížení seniorních inženýrů, zpoždění vydání nebo vážné problémy v produkci.

Blind Spot 3: Skrytá práce

Refaktorizace a architektonické posuny mají tendenci se skrývat v jiných tiketech, pokud se v systému tiketů vůbec objeví. AI produkuje více takové práce, ne méně. Agent neváhá dotknout se dvanácti souborů k opravě jedné chyby, zatímco člověk může zastavit a přehodnotit. Práce, která obchází systém záznamu, také obchází plánování, což znamená, že váš model kapacity je špatný a každá předpověď postavená na něm je také špatná. 

Abyste pochopili, kolik práce se skutečně vykonává, musíte sledovat, kolik se ve skutečnosti mění v kódu a v historii pull requestů. Bez toho je váš plán kapacity postaven na tom, co si lidé zapamatovali zaznamenat, ne na tom, co skutečně udělali. 

Blind Spot 4: Pokles kvality

Stejný průzkum zjistil, že téměř polovina vedoucích inženýrů má potíže s detekcí bezpečnostních problémů týden po týdnu. Složitost, duplikace a závislosti, které nepatří, se hromadí napříč mnoha malými, samostatně rozumnými změnami. Žádná z nich sama o sobě nepůsobí alarmující. Ve stejné případové studii Stanfordu klesla kvalita kódu o 9 % a její rozptyl se více než ztrojnásobil. Zatímco průměr se jen mírně posunul, rozptyl (ta část, kterou si všimnete) se posunul výrazně. Při objemu AI se tyto problémy kumulují rychleji, než je většina revizních procesů dokáže zachytit. Pokles se často projeví jako upozornění on-call, které se vrací k závislosti, na kterou si nikdo nepamatuje, že ji kontroloval. Do té doby má zákazník často už první poznámku.

Sledujte trendové čáry u bezpečnostních zjištění, závislostí a selhání a obnovy – ne jednotlivé commity. Složitost a duplikace narůstající během několika týdnů mají větší význam než jakákoli jedna změna, která je v revizi označena. Bez toho zachytíte pokles tak, jak to dělá většina týmů: až poté, co už způsobí incident. 

Blind Spot 5: Neověřený výdaj

Jakmile přestane adopce AI být předmětem debaty, stane se otázkou, na kterou se všichni soustředí, výdaj na AI a ROI. Finance chtějí vědět, co je kapitalizovatelné a co operativní. Vedení chce vědět, jaký výsledek investice přinesla. Většina týmů stále rozhoduje o nástrojích, licencích a personálních kapacitách na základě intuice, nikoli na základě důkazu o spojení mezi penězi a dodanou prací.

Sledujte, kam se úsilí inženýrů ve skutečnosti přesouvá v samotném kódu, čtvrtletí po čtvrtletí – ne tam, kde roadmapa říká, že by mělo proudit. Bez tohoto propojení bráníte rozpočtu na příští rok anekdotami, a anekdoty nepřežijí tvrdý rozhovor s finančním ředitelem.

Začněte tím, co nevidíte

Otázka financí ohledně kapitalizovaných výdajů a on-call stránky v 2 ráno se zdají nesouvisející, ale nejsou. Obě lze „odhadnout“ z aktivity. Obě jsou však ve skutečnosti zodpověditelné, s důkazy, přímo z kódu.

Odpovědí DORA na vše je samotný inženýrský systém: kvalita platformy, jasnost pracovního postupu, sladění týmu. To je pravda, a není to ani první krok. Nemůžete opravit systém, který nevidíte. Každou z těchto pěti oblastí musíte být schopni pozorovat, než můžete argumentovat pro investice do nich.

Prvním užitečným krokem není nový nástroj nebo nový proces. Je to znát sám sebe, upřímně, a určit, které z těchto pěti oblastí jsou slepá místa, kde postrádáte skutečné důkazy. Většina vedoucích může okamžitě identifikovat (a věnuje pozornost) problémy v jedné z těchto oblastí. Nicméně oblasti, kde máte nejméně informací, jsou nejpravděpodobněji ty, které vás při dalším nasazování AI překvapí a pošlapou.

Aaron Beals je CTO společnosti Flux, kde buduje vysoce výkonné, produktově orientované inženýrské týmy a škálovatelné platformy éry AI pro lídry v softwaru. S více než dvaceti lety zkušeností vedl inženýrské a produktové iniciativy ve firmách Endeca, Netezza, Harvard Medical School's Global Health Delivery Project a Appsembler (zakoupený společností Xenon Partners).