Jak sledovat nové AI modely bez hypu: praktický radar pro OpenAI, Claude, Gemini a coding agenty
Každý týden vyjde model, který „mění hru“. Většina releasů ale není změna, kterou máte co zapracovat do produktu — a ten rozdíl nepoznáte z marketingu, ale z disciplinovaného radaru. Čtyři druhy změn, tři vrstvy zdrojů a pět reakcí, které si CTO vede sám.
Každý týden vyjde model, který „mění hru“. Každý druhý týden vyjde benchmark, kde nový model „překonává člověka“. Tweet, demo, podcast, video s 800 tisíci zhlédnutími — a otázka, která vás reálně pálí, zní jinak: změnilo se něco, co mám zapracovat do produktu? Většinou ne. Občas dramaticky. Rozdíl mezi těmito dvěma stavy nepoznáte z marketingu, ale z disciplinovaného radaru, který si vede CTO nebo tech lead sám.
Tento článek se soustředí na uzavřené frontier modely (OpenAI, Anthropic, Google) a na coding agenty postavené nad nimi. Open-weight scéna (Meta, Mistral, DeepSeek, Qwen) a otázka, kdy se vyplatí jít lokálně, má vlastní dynamiku a řeší ji samostatný článek Lokální modely vs frontier modely.
01Tři druhy změn, které stojí za pozornost
Marketing vám naservíruje release jako jednu kategorii: „nový model je tady“. Pro praxi je užitečné to rozseknout na tři, protože každá vyžaduje jinou reakci.
Schopnostní změna. Model umí něco, co předtím skoro nikdo neuměl: spolehlivě skládat víceminutové coding úkoly bez ztráty kontextu, formálně dokazovat věty v Lean, řešit kompetiční úlohy typu AIME, držet sto tisíc tokenů kontextu bez halucinací v polovině. Tohle je málokdy. Když to nastane, mění to, co je vůbec rozumné zkoušet — někdy se otevřou produktové kategorie, které dřív nešly. Reakce: rozšířit eval, otestovat ostře, případně přepsat workflow.
Ekonomická změna. Stejná schopnost, jinak naceněná. Cena na 1 M tokenů spadne o řád, throughput se zdvojnásobí, kontextové okno zlevní, prompt caching dorazí jako default. Schopnost se nezměnila, ale ekonomika ano — věci, které dřív „nešly nákladově“, najednou jdou. Reakce: re-tierovat orchestraci, posunout úlohy z drahého modelu na levnější, znovu spočítat unit economy fíčur.
Workflow změna. Model se chová jinak, i když umí přibližně totéž: jiná interakce s nástroji, jiné formátování výstupu, jiný styl agentního chování, jiný tone of voice po RLHF kalibraci. Tohle nezakládá nový produkt, ale láme stávající integrace. Reakce: smoke test orchestrace, regression nad reálnými prompty, případně malá úprava systémových instrukcí.
Čtvrtá kategorie, kterou marketing ignoruje, ale která vás stejně dohoní: deprecation. Výrobce oznámí, že stará verze končí k datu X. Není to volitelné a má vlastní deadline. Patří do radaru přesně tak jako nové releasy — někdy víc, protože ignorování bolí spolehlivěji.
V praxi přitom jeden release málokdy spadá čistě do jedné škatulky. Nová
generace modelu bývá schopnostní a ekonomická a workflow
zároveň — je levnější, umí o kus víc a přitom se jinak chová
k nástrojům. Kategorie tu nejsou přihrádky, do kterých release patří celý; jsou
to čočky, kterými se na něj díváte. Do logu si zapíšete dominantní typ, ten, který
rozhoduje o vaší reakci — a pokud release vyžaduje dvě různé reakce (třeba
re-tier kvůli ceně i eval kvůli nové schopnosti),
klidně si ho zapište dvakrát. Užitečnější než správně zaškatulkovat je správně
reagovat.
Drtivá většina releasů spadá do workflow kategorie nebo do žádné — je to balení staré schopnosti do nového jména. Schopnostní průlomy přicházejí v měsících, ne v týdnech.
02Tři vrstvy zdrojů, které mají různou autoritu
Stejně jako u paperů (k tomu samostatný článek Jak číst AI papery), i u releasů platí, že ne všechny zdroje jsou si rovny.
Primární zdroje. Oficiální release notes, model cards, dokumentace, ceny v API console. To, co řekl výrobce sám, podepsanou stránkou. Pro OpenAI to je openai.com/news plus ChatGPT release notes; pro Anthropic anthropic.com/news plus Claude release notes a Claude model docs; pro Google blog.google/technology/google-deepmind plus Gemini API docs. Pro Claude Code samostatně What's New; pro Codex developers.openai.com/codex.
Pozor ale: primární zdroj není totéž co nestranný zdroj. Každý release je „our most capable model ever“ a každá model card vybírá benchmarky, kde model vyniká. Autoritativní znamená „toto je oficiální stanovisko výrobce“ — ne „toto je objektivní popis“. Rozdíl mezi tím, co výrobce měřil, a tím, co tvrdí, zůstává na vás.
Sekundární zdroje. Kvalifikovaní analytici a kurátoři, kteří release zasadí do kontextu — co se změnilo oproti minulé generaci, co tvrdí benchmarky, jak to ladí s aktuální vědou. AI Explained je dobrý příklad: nedělá hlavně novinky, ale jejich interpretaci s odkazem na zdroj. The AI Daily Brief je rychlejší a méně hluboký, vhodný jako denní detekční radar. Oba jsou ovšem v angličtině; česky kurátorský zdroj na srovnatelné úrovni neznám (pokud znáte, dejte vědět). Sekundární zdroje šetří čas, ale jejich autorita je vždy podmíněná — co řekli, je vždy potřeba domyslet zpět k primárnímu zdroji.
Tertiární / spekulativní. Tweety, vlákna na X, leaknuté snímky, anonymní benchmarky, Discord debaty. Občas jsou tu zajímavé signály o tom, kam to směřuje. Ale nejsou autorita ani pro to, co model umí, ani pro to, kdy vyjde. Pro radar fungují jako něco jako „toto sledujte, jestli to potvrdí primární zdroj“ — ne jako podklad pro rozhodnutí.
Nejčastější chyba je převzít sekundární nebo tertiární zdroj jako fakt. Když ho citujete vy nebo váš tým, převezmete jeho riziko: pokud se ukáže, že je nadsazený nebo prostě špatný, je to vaše rozhodnutí, ne autora videa.
03Co reálně číst — minimalistický radar
Existuje pokušení mít otevřených dvacet kanálů a nečíst žádný. Praktický radar je úzký, ale pravidelný.
Pro frontier modely stačí týdně proletět: OpenAI News, Anthropic News, Google DeepMind blog, ChatGPT release notes, Claude release notes. Když jeden z nich ohlásí nový model nebo větší update, ten den přečíst model card a release notes pořádně, ne jen titulek. Pro coding agenty navíc: Claude Code What's New a OpenAI Codex. Pro širší kontext jednou týdně epizoda AI Explained a The AI Daily Brief — od první kvůli hloubce, od druhé kvůli šíři.
Velkou část téhle detekční vrstvy přitom nemusíte obcházet ručně. Většina primárních zdrojů má RSS nebo changelog feed, výrobci mají status stránky a release notes jdou sledovat automaticky — ať už čtečkou, nebo jednoduchým skriptem, který hlídá změnu a pingne vás. Ruční proklik si pak necháte na ten den, kdy něco cinkne. To je vlastně ten rozdíl mezi „minimalistickým“ radarem a sedmi otevřenými záložkami, které stejně nečtete: minimalismus tu neznamená méně zdrojů, ale méně ručního obcházení.
Časová investice se velmi liší podle toho, jaký je týden. Rutinní týden bez velkých releasů: 20–30 minut na proletění a zápis do logu. Týden s velkým releasem (nová generace modelu, výrazná cenová změna, deprecation oznámení): počítejte s 2–3 hodinami — model card má často 30+ stran, ceny chtějí přepočítat, regression chce spustit. Tahle nerovnoměrnost není chyba radaru; je to vlastnost domény. Důležitější než průměr je nepřespat ten těžký týden.
04Jak si vést vlastní záznam změn
Bez vlastního logu vám release za měsíc splynou. Stačí jednoduchá tabulka nebo
dokument s pěti sloupci: datum, výrobce, model/feature, typ změny, naše
reakce. Sloupec „reakce“ má jen pár hodnot: none (neměříme,
neměníme), eval (přidat do testovací sady), re-tier
(přepočítat orchestraci), adopt (přepnout produkční tok),
watch (jen sledovat, zatím nemáme dost dat).
Konkrétně může log vypadat takhle:
| Datum | Výrobce | Model / feature | Typ změny | Reakce | Poznámka |
|---|---|---|---|---|---|
| 2026-02-14 | OpenAI | GPT-5.2 mini, −40 % cena | ekonomická | re-tier | přesun klasifikace ticketů z GPT-5 |
| 2026-02-19 | Anthropic | Claude Opus 4.7 | schopnostní | eval | nová coding benchmark sada, deadline 2 týdny |
| 2026-02-26 | Gemini 3 Flash, tool use změny | workflow | watch | nepoužíváme v produkci, zatím sledujeme | |
| 2026-03-04 | OpenAI | GPT-4o deprecation 2026-09-01 | deprecation | adopt | migrace na GPT-5 do června, ticket #A-2241 |
| 2026-03-11 | Anthropic | nový extended thinking mode | workflow | none | nezasahuje náš use case |
(Řádky výše jsou smyšlené ilustrace, ne reálná data o releasech — slouží jen jako ukázka formátu.)
Tenhle log dělá tři věci najednou. Drží tým konzistentní (každý ví, co je
rozhodnuté a co jen pozorujeme). Odhalí pattern (re-tier přichází
třikrát za půl roku, adopt jednou ročně). A v dlouhém běhu
dává odpověď na otázku, kterou vám management dřív nebo později položí: kolikrát jste
model změnili a proč.
Aby log neshnil, potřebuje jednoho vlastníka — ne „tým“, ale konkrétního člověka (nebo službu, která rotuje týden po týdnu), který je zodpovědný za týdenní zápis. Sdílená zodpovědnost za tenhle typ záznamu v praxi znamená žádná: log, který nikdo nevlastní, přestane být veden přesně v tom týdnu, kdy by se nejvíc hodil.
05Skrytý předpoklad: vlastní eval sada
Než půjdeme k tomu, co dělat špatně, jedna věc, na které celý radar mlčky
stojí: bez vlastní eval sady je každá reakce kromě none
a watch jen kvalifikované hádání.
eval, re-tier, adopt — všechny tři
předpokládají, že nový model umíte pustit proti své realitě, ne proti
benchmarku výrobce. Eval sada nemusí být nic velkého: pár desítek reálných promptů
z vaší produkce, ke kterým víte, jak má vypadat dobrá odpověď, plus způsob, jak
nový model proti nim rychle prohnat a porovnat výstup se starým. Čím blíž je
sada vaší skutečné distribuci vstupů, tím méně vás zajímá, kdo zrovna vede
leaderboard.
Tahle sada je zároveň tím, co drží pohromadě anti-patterny v další sekci: skoro každý z nich je svou podstatou nějaká forma rozhodování o modelu bez vlastního měření. Radar je proto přesně tak dobrý, jak dobrá je sada, proti které umíte nový model změřit — všechno ostatní je jen rozhodování o tom, kdy tu sadu spustit.
06Anti-patterny radaru
Chase the leaderboard. Změnit produkční model pokaždé, když někdo
zveřejní benchmark, kde nová verze předstihla starou o tři body. Benchmark není
produkce; rozdíl tří bodů se v reálném workflow obvykle ztratí v šumu
vlastních promptů, retrievalu a post-processingu. Proč to měřítko nestačí,
rozebírá samostatný článek (téma proc-benchmarky-ai-modelu-nestaci
v backlogu).
Switch on every release. Přepnout produkční model na nejnovější verzi automaticky. Krátkodobá výhra (vždy máte nejnovější), dlouhodobá daň (každý release rozbije sub-část integrace, kterou někdo musí spravit). Auto-upgrade má smysl jen tam, kde máte regression test, který zachytí workflow změnu dřív, než dojde k uživateli.
Ignore everything. Opačný extrém: „my používáme model X už rok, funguje“. Funguje to, dokud se mezitím nezměnila ekonomika tak, že platíte trojnásobek toho, co byste museli. Nebo dokud vám výrobce neoznámí deprecation s šestiměsíční lhůtou a vy zjistíte, že máte v kódu tvrdě zadrátované jméno modelu na 47 místech. Ignorování má smysl jen na měsíce, ne na roky.
Adopt nereplikovaného demo. Vyšlo demo, kde model dělá zázrak. Demo nejde reprodukovat na vašem use case, ale tým je z videa nadšený a tlačí to do roadmapy. Pravidlo: dokud demo nikdo na vašem use case nezreplikuje, je to marketing, ne důkaz schopnosti.
Když se vás někdo zeptá „proč ještě nejedeme na nejnovějším modelu?“, skoro nikdy nejde o novost samotnou. Jde o to, jestli ten release spadá do schopnostní, ekonomické, nebo workflow změny — a jestli máte eval sadu, na které to umíte rozhodnout. Bez ní je přepnutí jen jiná verze chase the leaderboard.
07Co se schopnostními změnami (vzácné, ale důležité)
Když se objeví reálná schopnostní změna — model spolehlivě dělá něco, co dřív nikdo
neuměl — má smysl udělat ostřejší krok než eval. Konkrétně: vytipovat
1–3 use casy, které byly do té doby „skoro nemožné“ a které by nová schopnost
otevřela. Postavit pro ně malý prototyp. Měřit přesvědčivě, ne demem. A teprve
při potvrzení posouvat do roadmapy.
Toto je jediný moment, kdy radar opravdu odhalí produktovou příležitost. Většinu času jen brání vstupu špatným rozhodnutím. Obojí je hodnotné.
08Souvislosti
Tenhle článek mluví o tom, jak filtrovat informace o modelech. Souvisí přirozeně s Lokální modely vs frontier modely, kde se schopnostní mezera porovnává konkrétně a kde se řeší open-weight scéna ponechaná stranou tohoto článku. A s Jak číst AI papery, který popisuje stejnou disciplínu, ale pro výzkumné výstupy místo produktových releasů. Když vám release přinese novou schopnost paměti nebo agentního chování, ladí to s rozborem v Paměť AI agentů.
09Závěr
Radar pro nové AI modely není o tom mít přečtené všechno. Je to o tom mít
disciplínu rozlišit čtyři druhy změn (schopnostní, ekonomická, workflow,
deprecation), tři vrstvy zdrojů (primární, sekundární, spekulativní) a pět
druhů reakce (none, eval, re-tier,
adopt, watch) — a stát na jedné věci, kterou marketing
nezmíní: na vlastní eval sadě, proti které každý nový model změříte.
Stojí za to si přitom přiznat, k čemu ten radar vlastně je. Většinu času brání vstupu špatným rozhodnutím a jen občas — při skutečné schopnostní změně — odhalí produktovou příležitost. Je to nástroj primárně obranný, ofenzivní jen výjimečně. To není slabina; je to přesně to, co od něj chcete.
Tým, který tohle dělá, většinu releasů odškrtne jako none nebo
watch a uvolní si tím prostor reagovat tehdy, kdy reagovat opravdu
má. Tým, který to nedělá, buď chasuje benchmarky, nebo přespává průlomy. Obojí stojí
stejně — jen každé jinak.
Radar pro nové AI modely je primárně obranný nástroj: většinu času brání vstupu špatným rozhodnutím a jen při skutečné schopnostní změně odhalí příležitost.
Článek popisuje stav radaru k květnu 2026 — konkrétní zdroje a odkazy ověřte k datu, kdy je čtete.