Architektura AI řešení bez kódu: jak stavět, když neumíte programovat

Když se mě někdo zeptal, jak přemýšlím, když něco stavím. První, co mě napadlo, nebyla odpověď. Byla to překážka: je strašně těžké naučit lidi, že se musí ptát. A ještě těžší je naučit je rozbíjet vlastní pohodlnost.

Protože přesně o tohle tady jde. Ne o techniku, ne o správná zaklínadla. O ochotu vzít odpověď, která vypadá hotově, a začít do ní rýpat - i když by bylo pohodlnější ji prostě přijmout a jít dál. To je nepohodlné. Jde to proti tomu, jak jsme nastavení. A přesně tohle odděluje člověka, který s AI něco postaví, od člověka, kterému AI něco postaví.

A přesto to spousta lidí ani nezkusí. Ti, kdo nikdy nenapsali řádek kódu, se dívají na hotového AI agenta a berou jako danost, že to postavil někdo, kdo umí programovat. A protože oni programovat neumí, uzavřou to: „tohle není pro mě.“

Neumím programovat v tom smyslu, jak si to většina lidí představuje. Nepíšu složité systémy od nuly, syntaxe není moje řemeslo. A přesto stavím produkční AI řešení, která reálně běží a reálně někdo používá. Můj e-mailový agent třídí a zpracovává poštu přes tři různě velké modely. Můj fotbalový prediktor počítá pravděpodobnosti zápasů a používají ho lidé, co si na něm tipují.

Jak to jde dohromady? Protože jsem časem pochopila jednu věc: architektura není programování. Architektura je rozhodování a postupné stavění - položit správnou otázku, postavit hrubý základ a iterovat na něm. A nic z toho nevyžaduje syntaxi.

•  •  •

Co vlastně znamená „stavět“ v době AI

Když dnes stavíte s jazykovým modelem, nepíšete většinu kódu vy. Píše ho model. Vy říkáte, co chcete, a on to vygeneruje. To zní jako zkratka, po které stačí umět dobře poprosit - a přesně tady většina lidí udělá chybu.

Model vám totiž postaví cokoli. I špatnou věc. I věc, kterou jste si špatně objednali. Nenasazuje vlastní krk - jemu je jedno, jestli to, co staví, dává smysl, jestli to za měsíc spadne, jestli jste vůbec potřebovali to, o co jste požádali. Krk nasazujete vy. Vy budete ten systém provozovat, vy poneste následky, když bude špatně navržený.

Z toho plyne celá tahle disciplína. Když model postaví, co řeknete, pak nejdůležitější dovednost není „umět mu to hezky říct“. Je to umět se ptát na správnou věc, stavět po krocích a odmítnout první odpověď jako hotovou.

Tohle nejsou dovednosti programátora, ale architekta - a dají se natrénovat bez jediného řádku kódu. Níže jsou tři, které používám každý den.

•  •  •

1. Ptejte se na problém, ne na řešení

Nejčastější past leží hned na začátku. Někdo přijde s hotovým řešením v ruce: „Uděláme to takhle.“ Může to být konkrétní technologie, konkrétní postup, konkrétní nástroj. A protože to zní sebejistě, člověk automaticky začne řešit, jak to udělat - místo aby se zeptal, jestli se to má dělat vůbec.

Jenže řešení v zadání není požadavek. Je to hypotéza. Někdo si už předem tipnul, jak to dopadne - často proto, že o tom četl, že to má konkurence, nebo že to prostě zní dobře. A vaše práce architekta není tu hypotézu poslušně naplnit. Je ji prověřit.

První otázka proto nikdy nezní „jak to udělám“. Zní: „Jaký problém tím řeším? A mám ten problém vůbec?“ Tohle platí pro volbu technologie úplně stejně jako pro celý návrh - kolikrát se ukáže, že půlka vymyšlené složitosti řeší situaci, která vůbec nenastane.

Znám to z vlastní praxe do detailu. Nejednou jsem dostala zadání ve stylu „udělejme to pomocí nějaké nabušené technologie“ a po jediné otázce - co přesně se má stát, koho se to týká, co se má reálně vyřešit - se ukázalo, že se celé zadání dá vyřešit něčím desetkrát jednodušším. Ta nabušená technologie byla odpověď na otázku, kterou nikdo nepoložil.

•  •  •

2. Postavte základ a iterujte - v dialogu, ne v objednávce

Tohle je jádro celé věci, a proto je to nejdelší část. Většina lidí si architekturu představuje jako velký plán, který se musí celý vymyslet dopředu a pak jednorázově postavit. Tak to nefunguje. Architektura je proces: postavíte hrubý základ, zkusíte ho, zjistíte, kde skřípe, a přepracujete. A pak znovu. A znovu.

To je osvobozující zpráva, takže ji řeknu natvrdo: nemusí to být hned dokonalé. První verze má být záměrně jednoduchá - má fungovat, ne oslnit. Teprve když ji máte v ruce a vidíte, jak se chová, víte, co je špatně. Papírový plán vám to neřekne. Chyby v architektuře se ukážou, až když do systému něco proteče.

A tady přichází to, co dělá celý rozdíl: jak s modelem mluvíte mezi iteracemi.

Většina lidí používá model jako automat na odpovědi. Vhodí dotaz, vezme, co vypadne, a jde dál. Tak se dá napsat e-mail. Systém se tak stavět nedá. Rozdíl mezi „objednávkou“ a „dialogem“ je v tom, co po modelu chcete mezi jednotlivými kroky. Objednávka zní „postav mi tohle“. Dialog zní jinak:

• „Zkus to nabořit. Kde tenhle základ selže, až přijde reálný provoz?“
• „Ukaž mi tři různé cesty, jak to udělat, a u každé výhodu a nevýhodu.“
• „Co jsem přehlédla? Jaký případ tohle rozbije?“
• „Tohle je moje první verze. Co bys na ní změnil jako první, až ji budu chtít zlepšit?“

Model je totiž nejlepší stavební partner, jakého si umíte představit - má nekonečnou trpělivost, nikdy se neurazí, když ho pošlete přepracovat návrh popáté. Ale ta trpělivost je k ničemu, když se ho ptáte špatně. Když chcete potlesk, dostanete potlesk. Když chcete díry ve vlastním nápadu, musíte si o ně říct.

A teď to nejdůležitější, protože vím, že tohle spoustu lidí brzdí: je jedno, že promptujete jak primitiv. Nemusíte umět elegantní, vyšperkované prompty. Nemusíte znát žádné triky. Můžete se ptát úplně obyčejnými větami - pokud se ptáte na to podstatné. Správná otázka položená neohrabaně porazí dokonalý prompt na špatnou otázku pokaždé. Kvalita toho, co postavíte, nestojí na tom, jak hezky mluvíte s modelem. Stojí na tom, jestli víte, na co se ptát.

Přesně takhle vznikl můj e-mailový agent. Nezačal jako promyšlený systém tří modelů. Začal jako jednoduchý základ, který uměl málo. Ta jeho nejchytřejší část - že jednoduché e-maily zpracovává malý levný model, složitější prostřední a jen ty nejtěžší ten nejdražší - nevypadla z první odpovědi. Vypadla z iterací. Z opakovaného „tohle běží, ale jde to udělat levněji? a co když přijde tenhle typ e-mailu? a nedá se to rozdělit?“. Kdybych vzala první návrh jako hotový a už na něj nesáhla, mám dnes systém, který na každý pozdrav od kolegy pálí nejdražším modelem. Iterace ho udělala chytrým, ne původní plán.

•  •  •

3. Neodsouhlaste první návrh

Tohle je nejtěžší ze tří, protože jde proti pohodlí. První odpověď modelu obvykle vypadá kompletně, sebejistě a hotově. Je lákavé ji vzít a mít klid.

Ale první návrh je hypotéza, ne výsledek. A model má nepříjemný zvyk: chce se vám zavděčit. Když dáte najevo, že se vám něco líbí, přikývne a jede dál vaším směrem, i kdyby ten směr byl slepá ulička. Souhlas je pro něj snadnější než odpor. Proto ten odpor musíte dodat vy.

Nejde o nedůvěru ze zásady. Jde o to nechat si věci ověřit, ne odkývat. U fotbalového prediktoru jsem měla model, který sebejistě chrlil pravděpodobnosti zápasů. Vypadaly rozumně. Mohla jsem si plácnout a vydat to. Místo toho jsem si nechala udělat kalibrační analýzu - tedy porovnání, jestli když model řekne „60 % šance“, ono to reálně v 60 % případů vyjde. A teprve ta ukázala, co samotné predikce zamlčely: u některých lig se model prostě netrefoval a žádné leštění promptu s tím nehnulo, protože ta nejistota byla v datech, ne v modelu.

To zjištění jsem nedostala proto, že bych uměla líp programovat. Dostala jsem ho proto, že jsem odmítla vzít hezky vypadající výstup jako pravdu a zeptala se „a je to opravdu tak dobré, jak to vypadá?“.

•  •  •

Jak z těch tří návyků udělat systém

Ty tři návyky mají jednu společnou slabinu: musíte si na ně vzpomenout. A to je přesně to, co ve slabé chvíli neuděláte. Když vás tlačí čas nebo se vám návrh líbí, jsou první, na co zapomenete. Disciplína, která stojí na tom, že si ji pokaždé sami připomenete, není disciplína - je to náhoda.

Tady se moje práce s modelem posunula nejvíc. Přestala jsem spoléhat na to, že si vzpomenu, a začala jsem si ta pravidla zapisovat. Ne do hlavy - do souboru, který model přečte pokaždé, než se pustí do práce. Sepsala jsem si vlastní „provozní řád“: kdy se má zastavit a zeptat se mě (nová knihovna, zásah do víc souborů najednou, změna něčeho, na čem visí další věci), kdy má něco udělat a jen mi to oznámit, a kdy má pracovat potichu. Napsala jsem si, že po každé větší změně musí shrnout, co udělal, proč zrovna takhle a jaká rizika u toho vidí. Ne proto, že bych ho nekontrolovala - ale proto, aby ta kontrola nezávisela na tom, jestli zrovna dávám pozor.

Ze stejného důvodu mám připravený jeden příkaz, který spustím, když chci, aby model přestal být příjemný. Řekne se mu, ať projde celou hotovou práci očima útočníka a hledá konkrétní typy chyb: kde by mohla uniknout cizí data, co se rozbije na prázdném nebo obřím vstupu, kde dvě věci naráz udělají zmatek. Není to nálada, na kterou musím mít sílu. Je to tlačítko, které zmáčknu vždycky stejně.

A tohle je vůbec ta nejvíc „architektonická“ věc, co dělám - a přitom v ní není jediný řádek kódu. Nenavrhla jsem systém. Navrhla jsem způsob, jakým s modelem spolupracuju. Postavila jsem si vlastní mantinely, kontrolní seznamy a stopky, protože vím, že na sebe ve slabé chvíli spolehnout nemůžu. To není práce programátora. To je přesně ta práce, o které je celý tenhle článek.

•  •  •

Kde končí kouzlo (protože nechci lakovat)

Byla bych nefér, kdybych vám naslibovala, že otázkami postavíte cokoli. Nepostavíte.

Jsou systémy, které vyžadují skutečné inženýrství - velké, složité, s infrastrukturou, kterou samotnými otázkami nedáte dohromady. Sama teď na jednom takovém spolupracuju a je mi jasné, že bych ho od nuly nepostavila. Není to moje řemeslo a předstírat opak by byla lež.

Přiznejme si i druhou stranu: vývojář má proti mně výhody, které mu žádnými otázkami nevezmu. Když model řekne „hotovo“, přečte si ten kód a pozná, jestli nelže - já se musím spolehnout na to, jak se věc chová a jaké chyby si model najde sám. To je slabší kontrola. Vývojář navíc zná terén: ví, jak vypadají všechny cesty, takže hloupý návrh ucítí okamžitě a zeptá se ostřeji. Moje umění ptát se je zčásti náhrada za mapu, kterou on má rovnou v hlavě. A když se model zasekne nebo si začne vymýšlet, vývojář sleze dolů a spraví to ručně - já jsem odkázaná na to, že se vyhrabe sám. Ty výhody jsou reálné a nemá smysl je zamlčovat.

A přesto i na takovém projektu má smysl u toho být. Hledat místo, kde se to zlomí, dřív než se to zlomí naostro. Nepovede se to pokaždé - ale ptát se na to je práce, kterou jinak neudělá nikdo.

Ještě jednu věc vám dlužím, protože nechci prodávat kouzlo. Až sem to vypadalo jako sada technik: správné otázky, zapsaná pravidla, kontrolní seznam. Jenže pod nimi leží dvě věci, které předat nejdou - a bez kterých jsou ty techniky k ničemu.

To první je nedůvěra, která jde proti tomu, jak dobře ta odpověď vypadá. Většina lidí uvěří o to víc, o co je výsledek hladší a sebejistější. Vy to musíte umět obráceně: čím čistěji něco vypadá, tím víc zpozornět. Příkazem se to nenaučíte - buď vás u pěkného výstupu něco zašimrá „počkat, tohle bylo moc snadné“, nebo ne. Vypěstuje se to jedině tak, že vás párkrát spálí něco, co vypadalo dokonale.

To druhé je tvrdohlavost. Model má nekonečnou trpělivost; vy k ní musíte dodat chuť poslat návrh popáté zpátky a vydržet v „ještě tomu nerozumím“. U mě je to povaha - když něčemu nerozumím, nedokážu to nechat být, potřebuju pochopit, co je pod tím. Někdy přitom rozumět nemusíte a klidně se spolehněte, že to AI napíše dobře za vás. Ale ne vždycky, a poznat ten rozdíl - kdy stačí věřit a kdy musíte rozumět - je kus umění sám o sobě.

Pravidla z minulé kapitoly jsem si proto nenapsala jako náhradu za tohle. Napsala jsem si je proto, že vím, že mě i instinkt občas zradí - ve tři odpoledne, unavenou, když se mi to líbí. Návod je záchranná síť pod povahou, ne náhrada za ni.

A nebudu vám lhát, že to máte zadarmo: hodně téhle práce stojí na analytickém myšlení - rozložit problém, vidět, jak do sebe věci zapadají, kde se logika zlomí. Není to ale dar, se kterým se člověk narodí a ostatní mají smůlu. Je to sval. Talent dá někomu náskok, jistě - jenže mistry nedělá talent, dělá je trénink. Ronaldo taky nebyl nejtalentovanější kluk na hřišti; byl to ten kluk, co dřel, když ostatní šli domů. Analytické myšlení, tvrdohlavost nepustit problém, umění ptát se - to všechno se dá vytrénovat, ať začínáte odkudkoli.

„Mistry nedělá talent, dělá je trénink. Platí to na trávníku a platí to tady.“

A tady je, co si odneste: ptejte se. Zkoumejte. Rozbíjejte. Umět napsat kód je běžnější než umět se zeptat, jestli se ten kód vůbec má psát. Ta druhá dovednost bývá vzácná a snadno se přehlédne - přitom rozhoduje, jestli se staví správná věc, nebo jen věc.

•  •  •

Žádná z nich nevyžaduje umět programovat. Ani jednu z nich nezachrání hezký prompt - zachrání je jen to, že se ptáte na správnou věc.

Umět se ptát a bořit je vstupenka dovnitř. Ne záruka, že odejdete jako architekt - tu si musíte odpracovat.

AIvKostce.cz  |  Markéta Antalíková  |  srpen 2026