Umělá inteligence mění způsob, jakým píšeme kód, dokumentujeme systémy a připravujeme technické podklady.
To už dnes není futuristická debata. Je to běžná pracovní realita vývojových týmů.
Model dokáže během chvilky shrnout ticket, projít část codebase, vytvořit návrh dokumentace, najít souvislosti mezi službami, navrhnout otázky pro business analytika nebo připravit první verzi technické
specifikace. To všechno je užitečné. Ale zároveň se tím otevírá problém, který se v enterprise vývoji nesmí podcenit:
AI umí velmi dobře vyrábět výstupy, které vypadají důvěryhodně. I když důvěryhodné být nemusí.
A to je pro technické týmy větší změna, než se na první pohled zdá.
Dřív šla kvalita často poznat podle formy. Dnes už ne.
V tradičním vývoji jsme si částečně zvykli odhadovat kvalitu práce podle její formy. Chaotický diagram často signalizoval, že autor nemá jasno.
Nesouvislá dokumentace naznačovala, že nebyla promyšlená. Nedotažený popis ticketu byl viditelný už na první přečtení.
Špatně strukturovaný návrh architektury většinou působil podezřele hned od začátku. Samozřejmě to nikdy nebylo dokonalé pravidlo. Ale nějak fungovalo.
U AI výstupů se tahle intuice rozpadá.
Model umí vytvořit text, který je gramaticky správný, strukturovaný, sebevědomý, přiměřeně technický a na první pohled velmi přesvědčivý. Umí vytvořit diagram, který vypadá jako architektonický návrh. Umí vytvořit dokumentaci, která působí kompletně. Umí dodat seznam doporučení, který vypadá jako výstup zkušeného konzultanta.
Jenže forma už není dobrý indikátor obsahu.
Výstup může být hezký, ale postavený na špatném předpokladu.
Může být logický, ale vycházet ze zastaralého ticketu.
Může být srozumitelný, ale ignorovat důležitou výjimku v produkčním provozu.
Může být technicky znějící, ale prakticky nepoužitelný.
To je důvod, proč se při práci s AI musíme naučit číst výstupy jinak. Ne rychleji. Kritičtěji.
Ticket není pravda. Dokumentace není pravda. Kód také není celý příběh.
Jedno z nejdůležitějších témat při zapojení AI do vývoje je otázka kontextu.
Když dáme modelu tickety, získáme určitý pohled na systém. Ale ticket obvykle popisuje to, co někdo chtěl, očekával nebo nahlásil v určitém čase. Nemusí popisovat to, co nakonec vzniklo. Nemusí obsahovat všechny dopady. Nemusí být aktuální. A někdy může být jednoduše špatně.
Když dáme modelu dokumentaci, získáme jiný pohled. Dokumentace může být cenná, protože nese záměr, terminologii a vysvětlení. Ale dokumentace v dlouho žijících systémech často zastarává. Někdy popisuje cílový stav, nikoli realitu. Někdy je příliš obecná. Někdy se aktualizovala jen část.
Když dáme modelu codebase, jsme blíž aktuální implementaci. Ale ani kód není celý příběh. Kód říká, co systém dělá. Ne vždy říká, proč to tak dělá. Neříká, jaké kompromisy vznikly v delivery. Neříká, co bylo dočasné řešení, které zůstalo pět let v produkci. Neříká, která integrace je citlivá kvůli provozu, zákazníkovi nebo historické smlouvě.
V enterprise systémech se pravda často neskrývá v jednom artefaktu.
Je rozložená mezi kód, dokumentaci, tickety, provozní zkušenost, znalost domény a paměť týmu. AI s tím může výrazně pomoci. Ale jen pokud ji používáme jako nástroj pro práci s kontextem, ne jako automatického rozhodčího.
AI dokumentace není jednorázové generování textu
Častá chyba je přemýšlet o AI dokumentaci jako o akci typu:
„Projdi repozitář a vytvoř dokumentaci.“
To může být dobrý začátek. Ale samo o sobě to nestačí.
V praxi je mnohem důležitější vytvořit pracovní postup, ve kterém je jasné:
Co má AI číst.
Čemu má dávat větší váhu.
Které zdroje jsou zastaralé.
Jak má pracovat s odkazy na třídy, metody a moduly.
Jakou terminologii má používat.
Jaké otázky má klást, když si není jistá.
Kdo výstup kontroluje.
Kdy se dokumentace aktualizuje.
Jak se pozná, že dokumentace přestala odpovídat realitě.
Tohle je méně atraktivní než demo, ve kterém agent během minuty vytvoří krásný markdown soubor. Ale pro dlouhodobou udržitelnost systému je to mnohem důležitější.
Dobrá AI dokumentace by neměla být jen „text o systému“.
- Měla by být navigační vrstva nad systémem.
- Měla by pomoci novému vývojáři rychleji pochopit strukturu.
- Měla by pomoci analytikovi lépe formulovat otázky.
- Měla by pomoci architektovi najít vazby mezi službami.
- Měla by pomoci týmu ověřit, jestli ticket dává smysl vzhledem k existujícímu řešení.
- Měla by zrychlit orientaci, ale nezakrývat nejistotu.
A hlavně: měla by být navázaná na realitu.
Ne na iluzi, že když je text hezký, je také správný.
Kvalita AI výstupu závisí na kvalitě otázek
V běžném vývoji často řešíme, jestli je ticket dost dobře připravený. Jestli má jasné acceptance criteria. Jestli popisuje business hodnotu. Jestli neobsahuje technické detaily, které by měl řešit tým. Jestli se dá podle něj rozumně groomovat. AI v tomhle může být velmi užitečná.
- Může z ticketu vytáhnout nejasnosti.
- Může připravit otázky pro business analytika.
- Může upozornit na chybějící edge cases.
- Může porovnat zadání s existující dokumentací.
- Může dohledat podobné historické požadavky.
- Může navrhnout, kde v systému může být dopad.
Ale opět platí: není cílem, aby AI ticket „schválila“.
Cílem je, aby pomohla týmu lépe se ptát.
To je důležitý posun. V mnoha situacích není největší hodnota AI v tom, že odpoví. Největší hodnota je v tom, že pomůže pojmenovat, co ještě nevíme.
U složitých B2B systémů bývá špatně položená otázka dražší než pomalá odpověď. Protože zavede tým do implementace, která vypadá správně, ale řeší jiný problém.
Seniorita v době AI není o objemu vygenerovaného textu
AI zvyšuje produkční kapacitu jednotlivce. To je zjevné. Vývojář může rychleji připravit návrh. Architekt může rychleji porovnat varianty. Analytik může rychleji formulovat otázky. Tým může rychleji vytvořit první verzi dokumentace.
Ale objem výstupu není totéž co hodnota.
Ve skutečnosti může nekontrolované používání AI vytvořit nový typ technického dluhu: dokumentační a kontextový dluh.
- Více markdown souborů.
- Více shrnutí.
- Více diagramů.
- Více pravidel.
- Více textu, který působí správně, ale nikdo neví, jestli stále platí.
Proto se bude měnit i význam seniority.
Seniorní člověk nebude jen ten, kdo umí dobře promptovat. Bude to člověk, který pozná, kde je výstup podezřelý. Kde chybí důkaz. Kde model přeskakuje důležitý detail. Kde se tváří jistě, ale ve skutečnosti jen doplňuje pravděpodobnou větu.
Bude to člověk, který umí říct:
- „Tohle vypadá dobře, ale ověřme to.“
- „Tady chybí vazba na kód.“
- „Tady vycházíme ze starého ticketu.“
- „Tohle je hypotéza, ne fakt.“
- „Tady se AI má ptát, ne odpovídat.“
To není brzda inovace. To je podmínka, aby AI v produkčním vývoji pomáhala, a ne vytvářela další vrstvu nejistoty.
V ASSISTu dává smysl přemýšlet o AI jako o součásti engineering procesu
V ASSISTu dlouhodobě pracujeme na systémech, které nežijí jen v repozitáři. Mají historii, provoz, datové vazby, integrace, doménové kompromisy a týmy, které za ně nesou odpovědnost delší dobu.
Právě v takovém prostředí je AI velmi zajímavá. Ne proto, že by magicky odstranila složitost. Ale proto, že může pomoci složitost zpřístupnit.
- Může zrychlit orientaci v kódu.
- Může pomoci udržet dokumentaci blíž implementaci.
- Může připravit lepší otázky pro grooming.
- Může najít souvislosti, které by člověk hledal dlouho.
- Může snížit tření při předávání znalostí mezi lidmi.
Ale jen pokud je zasazená do procesu, který počítá s kontrolou, odpovědností a pravidelnou aktualizací. AI v engineeringu není jen nástroj v editoru. Je to změna v tom, jak tým pracuje s věděním. A tam nestačí koupit licenci nebo přidat agenta do workflow. Je potřeba rozhodnout, jak se bude zacházet s pravdou.
Závěr: Nejde o to AI nevěřit. Jde o to vědět, kdy jí nevěřit.
Umělá inteligence bude v softwarovém vývoji stále běžnější. To není problém. Problém by byl tvářit se, že hezký výstup automaticky znamená správný výstup. V enterprise vývoji máme odpovědnost za systémy, které často běží roky, propojují více domén a ovlivňují reálný provoz firem. Tam nestačí generovat text. Tam je potřeba udržovat porozumění. AI může být skvělý pomocník pro dokumentaci, analýzu i vývoj. Ale musí zůstat nástrojem, který rozšiřuje technické myšlení týmu, ne náhražkou za něj.
Možná tedy nejdůležitější otázka pro další fázi AI ve vývoji nezní:
„Co všechno nám AI dokáže vygenerovat?“
Ale spíš:
„Máme dost dobrý proces na to, abychom poznali, kdy se AI mýlí?“
