Zní to tak hloupě, ale jedním z největších hacků produktivity při používání Claude Code s Opusem 4.1 je toto: poté, co požádáte CC o implementaci funkce nebo opravu chyby nebo čehokoli jiného, a poté, co řekne, že vše dokončil, prostě mu opakovaně říkáte následující znovu a znovu, dokud nenajde žádné další chyby (což někdy trvá až 7 nebo 8 pokusů!): "Skvělé, teď chci, abyste si pečlivě přečetli všechen nový kód, který jste právě napsali, a další existující kód, který jste právě upravili, "novýma očima" a velmi pečlivě hledali jakékoli zjevné chyby, omyly, problémy, problémy, zmatek atd." Ano, to může chvíli trvat, ale právě proto je tak užitečné mít otevřeno několik relací CC najednou. Pak je můžete jen otáčet a vkládat tam tu větu znovu a znovu. Věci "čerstvých očí" nějak mění způsob, jakým vnímá to, co právě napsal, opravdu užitečným způsobem. Kupodivu se zdá, že tento trik nefunguje tak dobře s myšlením GPT-5 - má tendenci prostě říkat "Jo, všechno vypadá správně!" Claude je mnohem náchylnější k pochybování a k tomu, že napoprvé dělá neopatrné chyby, ale je dobrý v jejich zachycení, když má dostatek šancí.

Kdokoli v OpenAI se rozhodl prolomit API pro GPT-5 (a o3, je to starý problém), aby změnil parametr "max_tokens" na "max_completion_tokens" ve snaze udělat věci jasnější... Udělal jsi velkou chybu. Nikdy to nepokryje nespočet hodin, které vývojáři promarnili na rozbitém kódu.

Po několika dalších dnech intenzivního používání GPT-5 pomocí kurzoru a modelu GPT-5 Pro ve webové aplikaci si stojím za vším, co jsem řekl o tom, že jde o mnohem chytřejší model a lepší v kódování než Opus 4.1 Opus se mi stále líbí a ergonomie Claude Code mi připadá v mnoha ohledech hezčí, ale pokud se snažíte dělat opravdu obtížné věci, které vyžadují opravdu chytré myšlení na základě prvních principů a znalosti počítačové vědy, GPT-5 je další úroveň. Ale mám podezření, že se to objeví pouze tehdy, když je režim uvažování nastaven alespoň na střední, a skutečně se to projeví při nastavení vysokého úsilí. Dobrým příkladem problému je příprava "připomínek" dokumentů dvou dlouhých, složitých právních dokumentů. Nejedná se o různé verze stejného dokumentu, ale o dva různé dokumenty, které pocházejí ze sdílené obecné šablony. To je velmi, velmi těžký problém, na kterém je třeba odvést dobrou práci, a vyžaduje mnoho chytrých triků a heuristik, aby byl zajištěn slušný výkon a kvalita výstupu (mluvím zde o použití tradičních programovacích technik, nikoli o použití LLM k tomuto srovnání). GPT-5 s agentem Cursor může ve srovnání s Opus4.1 jednoduše rychleji přicházet s více, lepšími, chytřejšími (a přitom pragmatickými) nápady a implementovat je správně a bez velkého držení ruky. Záleží ale na tom, na čem pracujete. Pořád si myslím, že dávám přednost frontendovému kódu například v NextJS od Opusu. Ale měli byste si bezpodmínečně ověřit své vlastní skutečné problémy a nevěřit všem těm lidem, kteří říkají, že model je na a že je to důkaz, že jsme narazili do zdi. Buď bez přemýšlení používají špatnou bezplatnou verzi, nebo nemají ponětí, jak efektivně vyvolávat výzvy, nebo nechávají své pocity vůči OpenAI a Altmanovi zabarvit své názory.

Líbí se mi, jak snadné jsou "upgrady" v době LLM. Bum, právě jste svou aplikaci vylepšili asi za 3 sekundy!

Bezplatný GPT-5 Max v kurzoru pro týden spuštění je neuvěřitelný dárek za spoustu peněz. Už mám 6 agentů Kurzoru, kteří hledají jakékoli problémy/otázky ve velkém projektu. Zatím to vypadá velmi dobře!

Tvrzení, že GPT-5 lže mnohem méně než o3, ve skutečnosti neznamená tolik vzhledem k tomu, jaký je o3 absolutní patologicky prolhaný šílenec! Dokonce i 80% snížení by při intenzivním používání stále skončilo několika lžemi denně.

Je legrační, že demo GPT-5 zdůrazňuje, jaký je to skvělý spisovatel... a pak předvádět čistou turbo-flákačku s pomlčkami v každé druhé větě. Měli by zůstat u ukázek kódování, které jsou mnohem působivější! Také se mi nelíbí, že zavrhují všechny staré modely...

Při zpětném pohledu je těžké uvěřit, že se nikdo neobtěžoval implementovat vícevrstvou neuronovou síť se základním stochastickým gradientním sestupem již v roce 1997 na 3dfx Voodoo, pár let před prvním GPU Nvidie v roce 1999. Kousky tam byly v podstatě všechny pro malé LLM.

Myslím, že nejvyšší kompliment, který mohu @patrickc a týmu Stripe složit, je, že mají tak skvělou pověst a zkušenosti s vytvářením opravdu vyleštěného a intuitivního UI/UX pro své služby, že je velmi užitečné odkazovat na ně jménem ve výzvách k kódování, abyste získali lepší výsledky od agentů kódování AI. Například mám ve svém textovém editoru uloženou variantu tohoto a vkládám ji do Claude Code alespoň 10krát denně: "Chci, abyste odvedli velkolepou práci při vytváření naprosto prvotřídních komponent UI/UX pro zobrazování těchto hodnotících zpráv, které zobrazují jak detaily, tak také jako "odznaky" nebo "souhrnné karty", s intenzivním zaměřením na to, aby bylo co vizuálně nejpřitažlivější, uživatelsky přívětivé, intuitivní, úhledné, uhlazené, "propruhované" kvalitní UI/UX možné a které využívá dobré knihovny, které jsou již součástí projektu." Pak mu řeknu, že ať už vyrobil cokoli, není to tak skvělé ("boží hrozné" nebo "neuvěřitelně špatné"), i když je to už docela dobré, a že to musí DRAMATICKY vylepšit, aby se skutečně dostalo na úroveň uživatelského potěšení a uhlazenosti, lesku, intuitivnosti atd. Stripe. V podstatě jde o použití techniky Steve Jobs Gaslighting k iterativnímu dosažení "šíleně skvělých" výsledků. A ano, funguje to neuvěřitelně dobře, pokud to děláte znovu a znovu. Trik je v tom, že musíte zahrnout VŠECHNA tato přídavná jména, jinak se to zvrhne v ikony, které se točí dokola a pulzují jako akrobaté ("úhledné" a "vizuálně přitažlivé"); potřebujete další termíny jako "leštěný" a "intuitivní" a "pruhovaný", abyste to zmírnili, takže je to také poněkud minimalistické a hezké používat v praxi. Jsem rád, že pro mě nemusí pracovat jako AI agent :/

Stačí si přečíst nový dokument GSPO od týmu Qwen. Je legrační, jak moc tato velká teoretická vylepšení, přestože mají zdánlivě hluboký fundamentální základ (v tomto případě, že optimalizace napříč sekvencemi tokenů je lepší než optimalizace napříč jednotlivými tokeny), nakonec vedou k tomu, že gradienty nechávají lépe plynout tím, že se vyhnou problémům s numerickým podmiňováním. Když uděláte krok zpět a podíváte se na to, GSPO je v podstatě způsob, jak získat lepší numerické podmiňování tím, že se věci více zprůměrují v aktualizacích, aby se zabránilo hlučným nárazům (téměř jako při použití hybnosti v rmsprop nebo Adam) a také ignorování aktualizací, které by vedly k číselně "nebezpečným" situacím z hlediska podmiňování. Ale z historické perspektivy to všechno dává smysl, protože hluboké učení skutečně explodovalo, když jsme přišli na to, jak se vyhnout problému mizejícího/explodujícího gradientu pomocí věcí jako hybnost v optimalizátorech. Svým způsobem je to tedy prostě poslední krok v této tradici navigace v krajině ztrát robustnějším způsobem, abychom se vyhnuli "vjetí do příkopu".