Když kód píše AI: Proč je softwarová architektura důležitější než kdy dřív

Tento článek vychází z anglického originálu Delegating Responsibility to Agents a poukazuje na to, jak kvalita architektury softwaru ovlivňuje jeho komplexitu v průběhu času.

V technologické komunitě se v souvislosti s nástupem autonomních AI agentů vede intenzivní debata o tom, který jazykový model disponuje lepší schopností generovat kód. Tento narativ však zcela míjí reálné jádro problému. Praxe ukazuje, že s rostoucí inteligencí modelů se paradoxně nezmenšuje role lidského architekta, ale naopak se dramaticky zvyšuje hodnota jeho klíčových rozhodnutí.

Zlaté pravidlo agentického inženýrství: AI netvoří novou softwarovou architekturu sama od sebe – pouze extrémně urychluje trajektorii, kterou jí člověk vymezuje.

Největší přínos AI agentů nespočívá v tom, že dokážou psát kód rychleji než člověk. Skutečná revoluce tkví v tom, že poprvé v historii softwarového inženýrství máme možnost aktivně a radikálně ovlivňovat trajektorii růstu vnitřní složitosti celého systému.

Pokud agentovi svěříte zdravou architekturu, akceleruje vznik robustní aplikace. Pokud mu však předhodíte chaos, s děsivou rychlostí a efektivitou vybuduje neudržitelnou digitální džungli. Implementaci lze delegovat na stroje téměř stoprocentně; architektonickou odpovědnost však delegovat nelze.

Tradiční pohled na delegování úkolů předpokládá, že čím komplexnější systém budujeme, tím více lidské práce a přímého dozoru vyžaduje. V agentickém vývoji je tomu přesně naopak, což dokonale ilustruje S-křivka (sigmoida) na Grafu 1, která znázorňuje míru autonomie AI v průběhu životního cyklu projektu.

Na samém počátku projektu je křivka plochá nebo jen mírně rostoucí. Agent je v této fázi v pozici extrémně kvalifikovaného programátora, který má sice encyklopedické znalosti celého internetu, ale postrádá jakoukoliv lokální intuici a kontext. Pokud v této chvíli architekt nepřevezme zodpovědnost a neinvestuje čas do striktního definování pravidel, struktur a mantinelů, projekt se nebude vyvíjet správným směrem. V tomto nultém bodě musí architekt odpracovat největší penzum kontextuální práce – navrhnout datové modely, rozhraní a systémové hranice.

Tato investice se však vyplácí v momentě, který na grafu představuje strmě stoupající křivku: Bod zlomu. Jakmile v codebase existují pevná pravidla, jasné architektonické vzory a konzistentní kostra aplikace, dynamika spolupráce se radikálně mění. Agent už nepotřebuje být veden za ruku krok za krokem. Začíná chápat systém ne z obecných pouček, ale z kontextu aplikace samotné.

Každý, kdo s agenty pracoval na hlubší úrovni, tento moment zná: ještě minulý týden jste psali polovinu kódu sami a detailně promptovali každý endpoint, dnes už agent na základě jednoho stručného záměru autonomně odbaví 80 % implementace, protože správný vzor jednoduše vyčte z existující struktury. Křivka autonomie se následně asymptoticky blíží k maximu. Čím lépe a čistěji připravíte základy, tím méně lidské mikromanagementové práce bude potřeba v pozdějších fázích projektu.

Když delegujeme psaní kódu na agenty, klíčovou byznysovou a technickou otázkou není, jak rychle máme hotovou první verzi. Nejdůležitější je, co se stane se strukturální složitostí systému po stovkách nebo tisících dalších změn a iterací. Zde se dostáváme k interpretaci Grafu 2, který ukazuje dlouhodobé důsledky tří různých přístupů k řízení agenta.

Zde je nutné striktně oddělit dva pojmy: Velikost kódu versus jeho komplexita. Mnoho manažerů žije v iluzi, že více řádků kódu automaticky znamená komplexnější systém. To je omyl. Můžete mít perfektně modulární systém o 20 000 řádcích, který má nízkou komplexitu, kde vazby jsou čisté a čitelné. A můžete mít skript o 2 000 řádcích, který vykazuje katastrofální komplexitu, který je provázaný skrytými závislostmi s implicitním chováním. Komplexita je definována množstvím vazeb, počtem větvení a objemem znalostí nutných k pochopení systému. A protože agenti generují obrovské objemy kódu v podstatě zdarma, velikost kódu přestává být metrikou. Hlavním bojištěm se stává strukturální složitost, kterou graf rozděluje do tří trajektorií:

Tento scénář nastává, když agent dostane absolutní autonomii bez architektonického dozoru. Každý nový požadavek je vyřešen jako lokální optimalizace – agent napíše kód, který sice splní zadání a projde základním testem funkčnosti („happy path“), ale bez ohledu na širší celek. Kód se začne neřízeně nabalovat na starší vrstvy.

Složitost systému roste výrazně rychleji než objem nově přidávané funkcionality. Po určité době systém degraduje do stavu, kdy už ani člověk, ani samotný agent kvůli omezenému kontextovému oknu nedokáže spolehlivě predikovat, co další změna v systému může narušit. Každý nový řádek vyžaduje enormní úsilí a projekt se stává neudržitelným.

Tento stav odpovídá standardnímu, dnes běžně zažitému vývoji softwaru. Komplexita systému roste úměrně tomu, jak roste samotný produkt a jak přibývají nové byznysové funkce. Člověk zde funguje jako neustálý filtr, korektor a validátor.

Zadavatel či vývojář hlídá vstupy, iteruje požadavky na základě existujícího kódu a nenechá agenta provádět radikální strukturální excesy. Režie na údržbu a neustálé upřesňování kontextu je sice vysoká a vývoj se v čase přirozeně zpomaluje, ale systém je držen v provozuschopném stavu a nezkolabuje pod vlastní vahou.

Ultimátní cíl úspěšného agentického vývoje. Architekt hned na začátku omezí autonomii agenta striktními pravidly a přinutí ho psát kód maximálně efektivně, modulárně a lineárně. Agent zpočátku naráží na mantinely, ale jakmile se systém stabilizuje, architekt nezačne AI používat pouze jako bezhlavý generátor nového kódu, ale jako silný nástroj pro průběžný refaktoring.

Agent je systematicky úkolován k tomu, aby čistil starší moduly, odstraňoval duplicity a zjednodušoval vazby. Po počátečním nárůstu se tak celková strukturální složitost systému stabilizuje a roste výrazně pomaleji než objem funkcionality.

Aby mohl architekt udržet komplexitu na spodní křivce, musí rozumět tomu, proč mají jazykové modely přirozenou tendenci kód zbytečně komplikovat a nafukovat. Často se tvrdí, že modely generují zbytečný boilerplate kód prostě proto, že se učily z průměrných a nekvalitních dat na internetu. To je však pouze polovina pravdy.

Modely bez explicitního architektonického kontextu inklinují k over-engineeringu — není to neodstranitelná vada, ale důsledek toho, že statisticky bezpečnější odpovědí je robustní vzor než elegantní jednoduchost. Čím méně kontextu model dostane, tím více sáhne po učebnicovém řešení. Architektonická pravidla tento sklon korigují — sám o sobě nevymizí, dokud architekt nestanoví striktní mantinely.

V praxi pak vidíme situace, kdy agent do banálního skriptu zavede hluboké hierarchie dědičnosti, dependency injection, rozhraní a generické továrny (factories). Technicky je vše správně, model úspěšně doručil „neprůstřelné“ řešení. Prakticky však vytvořil systém s masivní vnitřní režií, který je zbytečně drahý na údržbu. Model ze své podstaty neví, kdy je inženýrská jednoduchost lepší než akademická správnost. Nemá dlouhodobou intuici pro technický dluh. Seniorní vývojář vidí kód a řekne: „Tohle sice teď funguje, ale za půl roku to může být problém.“ LLM vidí pouze: „Tohle splňuje statistické vzory správnosti, úkol je splněn.“

Tento rozdíl v přístupu k řízení komplexity má naprosto zásadní ekonomické důsledky, které v současných manažerských debatách o AI téměř úplně chybí. Pokud se na vývoj softwaru podíváme optikou celkových nákladů na vlastnictví (TCO – Total Cost of Ownership), zjistíme, že špatně uchopená AI sice radikálně zlevňuje první fázi, ale projekt v dlouhodobém horizontu ekonomicky zatíží.

V neřízeném agentickém vývoji získáte prototyp za zlomek ceny a času oproti lidskému týmu. Jenže kvůli exponenciálnímu nárůstu skryté komplexity a over-engineeringu se fáze údržby stane obtížně udržitelnou. Každá další úprava vyžaduje masivní analyzování nadměrného množství složitého kódu a cena za rozvoj systému začne strmě stoupat. Naopak dobře řízený agentický vývoj, kde architekt drží pevnou ruku nad mantinely, sice vyžaduje vyšší počáteční inženýrské úsilí, ale přináší trvalou ekonomickou udržitelnost: levnou implementaci doprovází levná údržba.

Zatímco stavět nový projekt na zelené louce s pomocí AI je relativně přímočaré, největší technické výzvy přicházejí ve chvíli, kdy se snažíme agenty nasadit na již existující, běžící řešení (legacy codebase). Zde narážíme na fundamentální paradox lidského a strojového vnímání softwaru.

Základní konflikt vnímání: Kód, který lidé považují za elegantní, může být pro AI agenta absolutně nečitelný a matoucí.

Historicky se software psal tak, aby byl v prvé řadě srozumitelný pro lidský mozek. Lidé, aby zvládli uřídit komplexitu, se spoléhají na logické abstrakce a mentální modely. Člověk si při čtení kódu představuje byznys logiku, doménové vztahy a záměr původního autora. Spoustu věcí si domyslí z kontextu a zkušenosti, což nám umožňuje používat pokročilou magii frameworků, hluboké dědičnosti nebo implicitní chování, kde se spousta věcí děje skrytě.

Jazykový model však žádný mentální model světa ani vaší firmy nemá. Vidí kód jako čistou síť tokenů, struktur a statistických vztahů, omezenou velikostí svého kontextového okna (context window). Pokud je codebase kvůli lidské představě o „čistotě“ extrémně fragmentovaná, plná skrytých stavů s implicitní magií, model v ní okamžitě ztrácí orientaci — nedokáže staticky vyčíst, co na co navazuje. Stroji paradoxně vyhovuje kód, který je explicitní, vysoce modulární, ale lineární.

Značnou výhodou nasazení agenta na existující projekt je, že model dokáže absorbovat obrovské objemy dosavadního kódu během několika sekund a okamžitě pochopit zažité grafy a vzory projektu. To je cennější než tisíc řádků instrukcí v promptu. Jenže kvalita této stávající codebase neúprosně rozhodne o celé budoucnosti projektu.

Pokud je stávající architektura čistá a přehledná, agent tyto kvality okamžitě absorbuje a začne je multiplikovat. Pokud je však codebase nepřehledná, plná technického dluhu a strukturálních chyb, agent začne nad těmito špatnými vzory improvizovat. Výsledkem je generování velmi slabého až nepoužitelného kódu, který lidského programátora uvrhne do nekonečného cyklu opravování, upřesňování a ladění halucinací.

Nástup agentického vývoje nemění základní pravidla softwarového inženýrství, pouze je činí extrémně neúprosnými. AI agent není architekt. Je to neuvěřitelně výkonný, encyklopedicky vzdělaný implementátor.

Hlavní otázkou budoucnosti vývoje softwaru proto není to, jak pokročilé a autonomní modely budeme mít k dispozici. Hlavní otázkou je, jak kvalitní, čistou a pevnou architekturu dokážeme těmto modelům připravit a svěřit do rukou. AI nikdy nevyléčí špatný návrh systému – pouze ho rozšíří rychlostí, kterou lidský vývojář nedokáže efektivně moderovat.