Myslím, že jsem byl příliš odmítavý k novému kódování LLM Composer-1 od Cursoru. Jistě, je to striktně horší než GPT-5 High Effort a GPT-5-Codex, a tak v tomto smyslu, když navrhuji a implementuji důležité projekty kódu, nevidím pro to ve svých pracovních postupech místo. Na druhou stranu je extrémně rychlý (zajímalo by mě, jak to udělali; používají hardware Groq nebo Cerebras? je to proto, že model je tak malý a efektivní? nejsem si jistý) a to samo o sobě odemyká spoustu nových pracovních postupů a pracovních technik pro případy, kdy kód není tak kritický, nebo když začínáte nový projekt a nemusíte se bát, že rozbijete stávající kód. Je to také mnohem, mnohem levnější ve srovnání s jakoukoli příchutí GPT-5. Kombinace mnohem rychlejšího a mnohem levnějšího vytváří určitý kvalitativní rozdíl v tom, jak můžete model používat, který jsem dříve plně nedocenil. Když jsou náklady na iteraci tak nízké z hlediska času i peněz, můžete iterovat mnohem vícekrát. To snižuje hodnotu "jednorázové správnosti"; tedy schopnost modelu, jako je GPT-5 Pro, zvládnout i složitý kódovací úkol správně hned napoprvé bez chyb (i když i tento model v tomto velmi přísném testu často selhává). Pokud však dokážete uzavřít ladicí smyčku a rychle vrátit chyby/varování zpět do modelu a každé iterační kolo trvá 20 sekund až minutu (namísto 5 až 10krát tak dlouhého alespoň při použití GPT-5 s velkým úsilím), pak můžete rychle vyřešit všechny nedbalé chyby, které dělá napoprvé (nebo dokonce podruhé, potřetí, nebo počtvrté) a stále skončíte s funkčním kódem dříve, než byste mohli s GPT-5. Pokud něco vyvíjíte v prohlížeči, můžete nyní skutečně uzavřít smyčku úplně pomocí nové karty prohlížeče Cursoru, což je zdaleka nejlepší implementace tohoto druhu věcí, kterou jsem viděl v jakémkoli kódovacím nástroji (je to na míle daleko před použitím Playwright MCP z Codexu nebo Claude Code!). Dnes jsem s velkým efektem použil tuto výzvu: "Pomocí karty prohlížeče můžete systematicky prozkoumávat tuto aplikaci a používat rozhraní přirozeným způsobem; zatímco se to děje, sledujte PŘÍPADNÁ varování nebo chyby v konzoli pro vývojáře. Když se zobrazí, začněte interaktivně a iterativně diagnostikovat a opravovat chyby a problémy a poté aplikaci aktualizujte a ověřte, zda je chyba nebo upozornění zcela vyřešeno. Při opravě věcí se zaměřte na určení skutečné základní hlavní příčiny chyby a neaplikujte falešné "náplasti"! Kde se však tento přístup skutečně rozpadá, jsou koncepční a plánovací fáze, kdy zjišťujete, co udělat a jaký je nejlepší způsob, jak to implementovat na vysoké úrovni. Tam vás nedostatek hlubokého přemýšlení a zkoumání může nasměrovat na špatnou cestu, ze které je těžké se vzpamatovat. To je mnohem patrnější, když se úloha, na které pracujete, odklání daleko od "datové rozmanitosti" běžných kódovacích úloh. Pokud vytváříte další jednoduchý web CRUD, pak si toho pravděpodobně moc nevšimnete. Pokud se snažíte vstoupit na novou půdu v umělé simulaci života nebo něčem podobném, hodně si toho všimnete. Existuje však pěkný hybridní přístup, který funguje opravdu dobře: kombinace nejchytřejšího modelu pro plánování s těmito rychlými a levnými modely pro vytváření iterací. Použijte tedy GPT-5 Pro v aplikaci prohlížeče, abyste přišli se svým plánem a počáteční implementací, poté je vložte do Kurzoru a začněte iterovat, opravovat a vylepšovat. Je mnohem lepší v modifikaci existujícího pevného základu, než v položení samotného základu. To vše skutečně září, když si hrajete a objevujete s něčím zábavným, v novém projektu, kde nejsou žádné termíny ani očekávání. V tomto kontextu je rychlost skutečnou změnou hry. Připomíná mi to starý výzkum provedený společností IBM na počátku 80. let, který se zabýval latencí počítačových systémů a zjistil, že když se latence dostane pod nějakou magickou úroveň, například 50 ms, dojde k velké změně v chování, protože lidský mozek vnímá, že má co do činění s "živým systémem". A naopak, když latence překročí i překvapivě skromnou úroveň, jako je 500 ms, získáte mnohem menší zapojení a je to psychicky náročné a frustrující. Když se latence zvýší na několik sekund nebo více, lidé mají tendenci se mentálně odhlásit a je obtížné zůstat zapojeni. Vidět, jak kódovací model reaguje během několika sekund a provede smršť 10 úprav za méně než 15 sekund, je úplně jiný zážitek, než čekat 5 minut, než GPT-5 s vysokým úsilím něco metodicky prorazí. Každopádně je neuvěřitelně zábavné si s touhle věcí hrát. Je to pro mě zábavnější a poutavější, než by kdy mohla být jakákoli videohra.

Stačí si přečíst nový článek LeJEPA od Yanna LeCuna a Randalla Balestriera. Byl jsem zvědavý, na čem Yann v poslední době pracuje, zejména s ohledem na všechny jeho kritiky LLM (s čímž nesouhlasím, protože si myslím, že LLM se budou neustále zlepšovat a poměrně brzy nás dovedou k ASI). Každopádně, na X je již několik vláken o článku a o tom, co představuje. Zkrácená verze je, že jde o principiální, teoreticky zdůvodněný a úsporný přístup k učení pod vlastním dohledem, který nahrazuje složitý mišmaš ad-hoc, hacknutých heuristik pro prevenci kolapsu režimu, což je prokletí učení pod vlastním dohledem. To je okamžik, kdy model pokazí a začne mapovat všechny vstupy na téměř identické vnoření nebo na úzký podprostor vnoření, čímž zhroutí veškerou bohatost problému do patologicky jednoduché a nesprávné korespondence. Prvním pilířem nového přístupu je důkaz, že izotropní Gaussova rozdělení jedinečně minimalizují riziko nejhoršího možného predikce v downstreamu. Jakmile jsem si to přečetl, okamžitě mě napadlo CMA-ES, nejlepší dostupný optimalizační algoritmus černé skříňky pro případy, kdy nemáte přístup k gradientu funkce, kterou se snažíte minimalizovat, ale můžete provádět pouze (drahé/pomalé) vyhodnocení funkce. Nikolaus Hansen pracuje na CMA-ES od jeho představení v roce 1996. Vždy jsem byl fascinován tímto přístupem a v roce 2011 jsem jej s velkým úspěchem používal k efektivnímu prozkoumání hyperparametrů hlubokých neuronových sítí namísto neefektivního prohledávání mřížky. Každopádně, důvod, proč to zmiňuji, je ten, že existuje pozoruhodná paralela a hluboké spojení mezi tímto přístupem a jádrem LeJEPA. CMA-ES říká: Začněte s izotropním Gaussovem, protože je to distribuce maximální entropie (nejméně vychýlená) za předpokladu pouze omezení rozptylu. Poté upravte kovarianci tak, abyste se naučili geometrii problému. LeJEPA říká: Udržujte izotropní Gaussovskou distribuci protože je to distribuce maximální entropie (nejméně zkreslená) pro neznámé budoucí úlohy. Oba uznávají, že izotropie je optimální za neurčitosti ze tří důvodů: Princip maximální entropie; Mezi všemi distribucemi s pevným rozptylem má izotropní Gaussův systém maximální entropii; Tj. dělá nejméně předpokladů. Neexistuje žádná směrová zaujatost; Stejná odchylka ve všech směrech znamená, že se předem nezavazujete k žádné konkrétní struktuře problému. Získáte optimalitu v nejhorším případě; Minimalizujte maximální lítost ve všech možných geometriích problémů. Jaký je tedy rozdíl? Záleží na načasování adaptace. CMA-ES se může přizpůsobit během optimalizace; Začíná izotropně, ale poté se stane anizotropním, protože se učí specifické optimalizační prostředí. Naproti tomu LeJEPA musí zůstat izotropní, protože se připravuje na neznámé navazující úkoly, které dosud nebyly pozorovány. Tato paralela naznačuje, že LeJEPA aplikuje základní princip od teorie optimalizace k reprezentačnímu učení. V podstatě říká: "Optimální distribuce vyhledávání pro optimalizaci černé skříňky je také optimální distribucí vkládání pro přenosové učení." To dává smysl, protože oba problémy zahrnují navigaci v neznámých krajinách; pro CMA-ES je to neznámé optimalizační prostředí; pro LeJEPA je to neznámý prostor navazujících úkolů. Tento rozdíl mě pak nutí přemýšlet: mohli bychom mít "adaptivní LeJEPA", která začíná izotropně, ale přizpůsobuje svou distribuci vnoření, jakmile známe následnou úlohu, podobně jako se CMA-ES přizpůsobuje během optimalizace? To by bylo jako meta-učení správné anizotropie pro konkrétní skupiny úloh. Každopádně jsem si myslel, že se s vámi podělím o své názory na toto. Je fascinující vidět souvislosti mezi těmito různými oblastmi. Komunita optimalizace černých skříněk byla vždy dost oddělená a odlišná od komunity hlubokého učení a nedochází k velkému vzájemnému ovlivňování. To dává smysl, protože pokud máte přechod, byli byste blázen, kdybyste ho nepoužili. Existují však silné vazby.

Můžete se dostat asi na 95 % cesty k opravdu pěkné, úhledné a fungující aplikaci pro iOS napsané nativně ve Swiftu pomocí codexu a GPT-5. Ale pak se dostanete do bodu, kdy to chcete dát do AppStore, takže potřebujete nastavit certifikáty pro podepisování a všechny tyto další věci. V tu chvíli přestanete být schopni dělat vše z příkazové řádky programově a musíte si začít pohrávat s grafickým uživatelským rozhraním v Xcode a je to prostě absolutní noční můra. Prostě beznadějně špatné vzory uživatelského rozhraní a musíte odhadnout, kde co je. I když vám umělá inteligence krok za krokem říká, co máte dělat, je to obrovská kognitivní zátěž vůbec najít věci v matoucím a hrozném rozhraní. Apple by měl skutečně pozastavit práci na všech ostatních vývojářských nástrojích, dokud nebude mít zcela kompletní, dobře zdokumentovaný (v jediném souboru markdown!) CLI a API, které mohou agenti kódování AI používat komplexně pro vše, co souvisí s vytvářením a publikováním aplikace.