Мені здається, що я занадто зневажливо поставився до нового кодування Composer-1 від Cursor LLM. Звичайно, це строго гірше, ніж GPT-5 High Effort і GPT-5-Codex, і тому в цьому сенсі, коли я архітектурую і впроваджую важливі кодові проекти, я не бачу для цього місця в своїх робочих процесах. З іншого боку, він надзвичайно швидкий (цікаво, як вони це зробили; вони використовують обладнання Groq або Cerebras? це тому, що модель така маленька і ефективна? не впевнений), і тільки це відкриває безліч нових робочих процесів і робочих технік, коли код не настільки критично важливий, або коли ви починаєте новий проект і вам не потрібно турбуватися про те, що ви зламаєте існуючий код. Це також набагато, набагато дешевше в порівнянні з будь-яким смаком GPT-5. Поєднання набагато швидшого та набагато дешевшого створює деяку якісну різницю в тому, як можна використовувати модель, яку я раніше не до кінця оцінив. Коли вартість ітерації настільки низька як з точки зору часу, так і з точки зору грошей, ви можете повторювати ітерації набагато більше разів. Це знижує значення «одноразової правильності»; тобто здатність такої моделі, як GPT-5 Pro, правильно виконати навіть складне завдання кодування з першого разу без багів (хоча навіть ця модель часто зазнає невдачі на цьому дуже жорсткому тесті). Але якщо ви можете замкнути цикл налагодження та швидко передати помилки/попередження назад у модель, а кожен раунд ітерації займає від 20 секунд до хвилини (замість 5-10 разів довше, принаймні використовуючи GPT-5 з великими зусиллями), то ви зможете швидко вирішити всі недбалі помилки, які він робить з першого разу (або навіть другого, третій, або четвертий раз) і все одно закінчити з робочим кодом швидше, ніж ви могли б з GPT-5. Якщо ви розробляєте щось у браузері, ви тепер дійсно можете замкнути цикл за допомогою нової вкладки браузера Cursor, яка, безумовно, є найкращою реалізацією такого роду речей, яку я бачив у будь-якому інструменті кодування (вона на багато миль випереджає використання Playwright MCP від Codex або Claude Code!). Сьогодні я з великим ефектом використовую цю підказку: «Використовуйте вкладку браузера, щоб систематично досліджувати цю програму та використовувати інтерфейс природним чином; поки це відбувається, стежте за БУДЬ-ЯКИМИ попередженнями або помилками в консолі розробника. Коли ви побачите один, почніть інтерактивну та ітеративну діагностику та виправлення помилок і проблем, а потім оновіть програму та переконайтеся, що помилку або попередження повністю вирішено. Виправляючи речі, зосередьтеся на визначенні справжньої основної причини помилки, а не на застосуванні фальшивих «пластирних» виправлень!» Однак цей підхід дійсно зазнає невдачі на етапах концепції та планування, коли ви з'ясовуєте те, що зробити та як найкраще реалізувати це на високому рівні. Там відсутність глибокого мислення та дослідження може відправити вас на поганий шлях, з якого важко оговтатися. Це стає набагато очевиднішим, коли завдання, над яким ви працюєте, далеко відхиляється від «різноманіття даних» звичайних завдань з кодування. Якщо ви створюєте ще один простий сайт CRUD, то ви, швидше за все, його не помітите. Якщо ви намагаєтеся ступити на новий ґрунт у симуляції штучного життя або чогось дивного на кшталт цього, ви часто це помітите. Але є хороший гібридний підхід, який працює дуже добре: поєднання найрозумнішої моделі для планування з цими швидкими та дешевими моделями для прокручування ітерацій. Отже, використовуйте GPT-5 Pro в програмі браузера, щоб придумати свій план і початкову реалізацію, а потім вставте це в Cursor і почніть ітерувати, виправляти та вдосконалювати. Він набагато краще модифікує існуючий міцний фундамент, ніж викладає сам фундамент. Де все це дійсно яскраво, так це коли ви граєте та досліджуєте щось веселе в новому проекті, де немає дедлайнів чи очікувань. У цьому контексті швидкість дійсно змінює правила гри. Це нагадує мені старе дослідження, проведене IBM на початку 80-х, в якому розглядалася затримка в комп'ютерних системах, які виявили, що коли затримка опускається нижче якогось магічного рівня, наприклад, 50 мс, ви отримуєте великі зміни в поведінці, тому що людський мозок сприймає, що він має справу з «живою системою». І, навпаки, коли затримка перевищує навіть напрочуд скромний рівень, наприклад, 500 мс, ви отримуєте набагато менше залучення, і це психологічно обтяжує та засмучує. Коли затримка зростає до кількох секунд або більше, люди, як правило, подумки перевіряють, і їм стає важко залишатися залученим. Бачити, як модель кодування реагує за лічені секунди і робить шквал із 10 редагувань менш ніж за 15 секунд, — це зовсім інший досвід, ніж чекати 5 хвилин, поки GPT-5 докладає великих зусиль, щоб методично щось прокрутити. У будь-якому випадку, погратися з цією річчю неймовірно весело. Для мене це веселіше та захоплююче, ніж будь-яка відеогра.

Просто прочитайте нову статтю LeJEPA Янна Лекуна та Рендалла Балестрієро. Мені було цікаво дізнатися, над чим Янн працює останнім часом, особливо з огляду на всю його критику LLM (з чим я не згоден, оскільки я думаю, що LLM продовжуватимуть вдосконалюватися і досить скоро приведуть нас до ASI). У всякому разі, на Х вже є кілька ниток про папір і про те, що він вводить. Коротка версія полягає в тому, що це принциповий, теоретично обґрунтований і стриманий підхід до самоконтрольованого навчання, який замінює складну мішанину ситуативних, хакерських евристик для запобігання колапсу режиму, який є прокляттям самоконтрольованого навчання. Ось тут модель закручується і починає відображати всі вхідні дані на майже ідентичні вкладення або на вузький підпростір вкладень, згортаючи все багатство проблеми в патологічно просту і неправильну відповідність. Першим стовпом нового підходу є їх доказ того, що ізотропні розподіли Гаусса однозначно мінімізують ризик прогнозування в найгіршому випадку. Як тільки я прочитав це, я відразу ж подумав про CMA-ES, найкращий доступний алгоритм оптимізації чорного ящика, коли у вас немає доступу до градієнта функції, яку ви намагаєтеся мінімізувати, але ви можете виконувати лише (дорогі/повільні) оцінки функцій. Ніколаус Хансен працює над CMA-ES з того часу, як представив його ще в 1996 році. Я завжди захоплювався цим підходом і використовував його з великим успіхом для ефективного дослідження гіперпараметрів глибоких нейронних мереж ще у 2011 році замість того, щоб виконувати неефективні пошуки по сітці. У будь-якому випадку, причина, чому я піднімаю це питання, полягає в тому, що існує разюча паралель і глибокий зв'язок між цим підходом і суттю LeJEPA. CMA-ES говорить: Почніть з ізотропного гаусса, оскільки це розподіл максимальної ентропії (найменш зміщеного) за наявності лише дисперсійних обмежень. Потім адаптуйте коваріацію, щоб вивчити геометрію задачі. LeJEPA говорить: Підтримуйте ізотропний Гаусс, оскільки це максимальний ентропійний (найменш зміщений) розподіл для невідомих майбутніх завдань. Обидва визнають, що ізотропія є оптимальною в умовах невизначеності з трьох причин: Принцип максимальної ентропії; Серед усіх розподілів з фіксованою дисперсією ізотропний гауссів має максимальну ентропію; Тобто він робить найменшу кількість припущень. Немає спрямованого зміщення; Однакова дисперсія у всіх напрямках означає, що ви не зобов'язуєтеся заздалегідь дотримуватися якоїсь конкретної структури проблеми. Ви отримуєте оптимальність у найгіршому випадку; Мінімізуйте максимум шкоди у всіх можливих геометріях проблеми. Так в чому ж тоді різниця? Все зводиться до термінів адаптації. CMA-ES може адаптуватися під час оптимізації; Він починає ізотропно, але потім стає анізотропним, вивчаючи конкретний ландшафт оптимізації. На противагу цьому, LeJEPA має залишатися ізотропним, оскільки він готується до невідомих завдань, які ще не були помічені. Ця паралель свідчить про те, що LeJEPA застосовує фундаментальний принцип від теорії оптимізації до навчання представлення. По суті, це говорить про те, що: «Оптимальний розподіл пошуку для оптимізації «чорного ящика» також є оптимальним розподілом вбудовування для трансферного навчання». Це має сенс, оскільки обидві проблеми пов'язані з навігацією невідомими ландшафтами; для CMA-ES це невідомий ландшафт оптимізації; для LeJEPA це невідомий простір подальших завдань. Ця різниця змушує мене задуматися: чи можемо ми мати «адаптивний LeJEPA», який запускає ізотропний, але адаптує свій розподіл вбудовування, як тільки ми знаємо подальшу задачу, подібно до того, як CMA-ES адаптується під час оптимізації? Це було б схоже на мета-навчання правильної анізотропії для конкретних сімейств завдань. У всякому разі, я подумав, що поділюся своїми думками з цього приводу. Захоплююче спостерігати за зв'язками між цими різними сферами. Спільнота оптимізації чорного ящика завжди була досить відокремленою та відмінною від спільноти глибокого навчання, і там не так багато перехресного запилення. Це має сенс, тому що якщо у вас є градієнт, ви були б божевільними, якби не використовували його. Але є міцні зв'язки.

Ви можете отримати приблизно 95% шляху до дійсно приємного, гладкого, робочого додатку для iOS, написаного на Swift за допомогою codex і GPT-5. Але потім ви доходите до точки, коли хочете викласти його в AppStore, тому вам потрібно налаштувати сертифікати для підпису та все таке інше. У цей момент ви перестаєте робити все з командного рядка програмно, і вам потрібно почати возитися з графічним інтерфейсом в Xcode, і це просто абсолютний кошмар. Просто безнадійно погані патерни інтерфейсу, і потрібно вгадувати, де що знаходиться. Навіть коли штучний інтелект крок за кроком каже вам, що робити, це величезне когнітивне навантаження навіть знайти речі в заплутаному та жахливому інтерфейсі. Apple дійсно повинна призупинити роботу над усіма іншими інструментами для розробників, поки вони не отримають повністю повний, добре задокументований (в одному файлі Markdown!) CLI та API, які можуть бути наскрізно використані агентами кодування штучного інтелекту для всього, що пов'язано зі створенням та публікацією програми.