Dvě největší výzvy AI vývoje: ověřování kvality a závislost na velkých modelech

V minulém článku jsem psal, že AI píše přesně takový kód, jaký si řeknete. Dnes navážu tím, co z toho plyne — protože pokud generování kódu přestalo být problém, něco jiného se problémem stát muselo.

Podle mě jsou to dvě věci. A ani jedna z nich není „AI není dost chytrá".

Výzva č. 1: Generovat umí každý. Ověřovat málokdo.

Ještě před pár lety platilo, že napsat kód je drahé a pomalé. Celý průmysl byl postavený na téhle vzácnosti: platili jsme za člověkodny psaní.

Dnes je psaní skoro zadarmo. AI vygeneruje funkci, modul nebo celou aplikaci za minuty. A tím se ekonomika vývoje překlopila: úzkým hrdlem už není produkce kódu, ale ověření, že je správný. QA, které bývalo popelkou na konci procesu, se stává nejcennější disciplínou v celém řetězci.

Je to logické. Když deset lidí denně vygeneruje kód, který by dřív psalo sto lidí měsíc, množství věcí, které je potřeba zkontrolovat, otestovat a schválit, roste stejným tempem. Jenže kontrola se zautomatizovat dá jen zčásti — testy, statická analýza, typové kontroly a strojové review odchytí hodně, ale finální otázky zůstávají lidské:

• Dělá to opravdu to, co byznys potřebuje — ne jen to, co bylo v zadání?
• Chová se to rozumně v krajních případech, které nikdo nesepsal?
• Nerozbije to za půl roku něco, co dnes nikdo nevidí?

Role vývojáře se tím mění víc, než si většina oboru připouští. Hodnota se přesouvá od „umím to napsat" k „umím to přesně zadat a spolehlivě ověřit". To je dovednost bližší seniornímu inženýrovi, architektovi a testerovi než klasickému psavci kódu. Lidský faktor z vývoje nemizí — přesouvá se na místo, kde je nenahraditelný: na konec řetězce, k rozhodnutí „tohle je správně a může to ven".

U nás to v praxi znamená, že na každý projekt jde víc energie do testů, review a ověřovacích běhů než do samotného psaní. Zní to obráceně, než jak se AI vývoj prodává. Je to přesně ten důvod, proč naše výstupy fungují v produkci.

Výzva č. 2: Velký model všude = závislost, kterou jste nepotřebovali

Druhá výzva je architektonická a mluví se o ní překvapivě málo, protože jde proti zájmu všech, kdo prodávají tokeny: kde v systému má LLM vůbec být?

Převládající vzorec roku 2026 je „nacpi GPT/Claude API do všeho". Každá feature volá cloudový model: kategorizace objednávky? API call. Vyhledávání? API call. Notifikace? API call. Výsledek je aplikace, která:

• má v každém požadavku latenci externí služby,
• platí za tokeny při každém kliknutí uživatele,
• posílá firemní data třetí straně, i když nemusí,
• a hlavně — přestane fungovat, když přestane fungovat dodavatel modelu. Nebo když zdraží. Nebo když změní chování mezi verzemi.

Přitom pro většinu těch úloh platí nepohodlná pravda: nepotřebují inteligenci za miliardy dolarů. Potřebují dobře napsaný deterministický kód. A tady se obě výzvy krásně potkávají, protože ten kód vám dnes velký model napíše.

Pipeline, která nám dává smysl

Náš přístup se dá shrnout do jedné věty: velké cloudové LLM při vývoji, deterministický kód v provozu, malé modely tam, kde je opravdu potřeba jazyk.

V praxi to vypadá takhle:

1. Build-time: velké modely na maximum. Návrh, generování kódu, testy, code review, dokumentace, migrace. Tady se špičková inteligence vyplatí — a závislost na dodavateli je v téhle fázi bezpečná: kdyby zítra zmizel, vaše aplikace v produkci si toho ani nevšimne. Zpomalí se jen další vývoj.
2. Runtime: deterministický kód jako výchozí volba. Kategorizace podle pravidel, výpočty, workflow, reporty, integrace — to všechno je levnější, rychlejší a spolehlivější jako obyčejný kód. Že by ho dřív bylo drahé napsat? Právě to už neplatí.
3. Runtime s jazykem: nejmenší model, který úlohu zvládne. Extrakce údajů z dokumentů, klasifikace textů, shrnutí, jednoduché odpovědi — na tohle stačí malé modely, často běžící lokálně na vlastním železe. Žádné tokeny, žádná data mimo firmu, predikovatelné náklady.
4. Runtime s velkým modelem: jen když má skutečný důvod. Otevřená konverzace se zákazníkem, komplexní uvažování nad libovolným vstupem, agentní scénáře. Tyhle případy existují — ale je jich menšina, a mají být vědomým rozhodnutím s rozpočtem, evaluacemi a fallbackem, ne výchozím stavem.

Poctivá poznámka k „lokálnosti"

Aby to nebyla agitka: „malý" a „lokální" jsou dvě různé osy. Malý cloudový model řeší cenu a latenci, ale data pořád odcházejí ven. Lokální model přidává soukromí a nezávislost, ale přináší provozní starosti — inference server, aktualizace, vyhodnocování kvality. Pro nízké objemy může být malý cloudový model paradoxně levnější než vlastní GPU. Rozhoduje objem, citlivost dat a to, jestli máte kapacitu si infrastrukturu provozovat. Neexistuje jedna správná odpověď — existuje správné pořadí otázek.

Rozhodovací žebřík

Když u nás navrhujeme novou funkci, ptáme se v tomhle pořadí:

1. Jde to deterministickým kódem? → Napiš ho (klidně s pomocí velkého modelu). Konec.
2. Je potřeba porozumění jazyku? → Zvládne to malý model? Vyzkoušej, změř, nasaď ten nejmenší, který projde evaluací.
3. Opravdu to chce špičkový model? → Dobře — ale s rozpočtem na tokeny, s evaluační sadou, s fallbackem pro výpadek a s vědomím, že jste si právě koupili závislost.

Většina funkcí končí na první příčce. A to je v pořádku — cílem není mít v aplikaci co nejvíc AI, ale vyřešit problém co nejspolehlivěji.

Závěr

Největší výzvy AI éry nejsou technologické, ale disciplinární. První: udržet kvalitu, když se kód valí rychlostí, na kterou QA procesy nebyly stavěné — a smířit se s tím, že lidský úsudek je teď to nejdražší a nejdůležitější v celém řetězci. Druhá: odolat pokušení nacpat velký model do každého requestu a stavět systémy, které AI využívají tam, kde dává smysl — hlavně při svém vzniku — a v provozu stojí na vlastních nohou.

Obě výzvy mají společného jmenovatele: rozhodují lidé, ne modely. Pořád.

V Reactive Studiu takhle stavíme aplikace za měsíční paušál — AI naplno při vývoji, střízlivě v provozu. Jestli řešíte, kam ve vašem systému AI patří a kam ne, přijďte na konzultaci — je to přesně typ otázky, kterou rádi rozebíráme.