Це звучить так безглуздо, але один з найбільших хаків продуктивності при використанні Claude Code з Opus 4.1 полягає в наступному: після того, як ви попросили CC впровадити функцію або виправити помилку, або щось інше, і після того, як він говорить, що все виконано, ви просто повторюєте йому наступне знову і знову, поки він не зможе знайти більше помилок (що іноді займає до 7 або 8 спроб!): «Чудово, тепер я хочу, щоб ви уважно прочитали весь новий код, який ви щойно написали, та інший існуючий код, який ви щойно змінили, «свіжим поглядом», дуже уважно шукаючи будь-які очевидні помилки, помилки, проблеми, проблеми, плутанину тощо». Так, це займає деякий час, але саме тому так зручно мати відразу відкриту купу сесій CC. Потім ви можете просто перегортати їх, вставляючи це речення знову і знову. Якимось чином «свіжий погляд» змінює те, як він сприймає те, що щойно написав, у справді корисний спосіб. Дивно, але цей трюк, здається, не так добре працює з мисленням GPT-5 – він має тенденцію просто говорити: «Так, все виглядає правильно!». Клод набагато більше схильний до другорядних вгадувань і необережних помилок з першого разу, але добре вміє їх ловити, маючи достатньо шансів.

Хто в OpenAI вирішив зламати API для GPT-5 (і o3, це стара проблема), щоб змінити параметр "max_tokens" на "max_completion_tokens" у спробі зробити все зрозуміліше... Ви зробили велику помилку. Він ніколи не покриє незліченні години, витрачені розробниками на зламаний код.

Після ще кількох днів інтенсивного використання GPT-5 через курсор і через модель GPT-5 Pro у веб-додатку, я дотримуюся всього, що говорив про те, що це набагато розумніша модель і краще кодує, ніж Opus 4.1 Мені все ще подобається Opus, і я вважаю ергономіку Claude Code приємнішою у багатьох відношеннях, але якщо ви намагаєтеся робити справді складні речі, які вимагають справді розумного мислення перших принципів та навичок інформатики, GPT-5 – це наступний рівень. Але я підозрюю, що це з'являється лише тоді, коли режим зусиль міркування встановлено принаймні на середній, і дійсно проявляється при налаштуванні високих зусиль. Хорошим прикладом проблеми є підготовка документальних «червоних ліній» з двох довгих, складних юридичних документів. Не різні версії одного документа, а два різні документи, які походять із загального шаблону. Це дуже, дуже складна задача, над якою потрібно добре попрацювати, і вона вимагає багатьох розумних трюків та евристик, щоб забезпечити пристойну продуктивність та якість виведення (я говорю про використання традиційних методів програмування тут, а не про використання LLM для цього порівняння). GPT-5 з агентом Cursor може просто швидше придумувати більше, кращі, розумні (але прагматичні) ідеї та реалізовувати їх правильно і без зайвих зусиль, порівняно з Opus4.1. Однак це залежить від того, над чим ви працюєте. Я все ще вважаю, що віддаю перевагу фронтенд-коду в NextJS від Opus, наприклад. Але ви повинні обов'язково перевірити на собі реальні проблеми і не довіряти всім численним людям, які кажуть, що модель відстійна і що це доказ того, що ми вдарилися об стіну. Або вони використовують погану безкоштовну версію, не замислюючись, або вони не мають поняття, як ефективно підказати, або вони дозволяють своїм почуттям до OpenAI та Altman забарвити їхні погляди.

Мені подобається, наскільки простими є «оновлення» в епоху LLM. Бум, ви щойно зробили свій додаток набагато кращим приблизно за 3 секунди!

Безкоштовний GPT-5 Max у Cursor на тиждень запуску — це неймовірний подарунок, який коштує купу грошей. У мене вже є 6 агентів Cursor, які шукають будь-які проблеми/питання у великому проекті. Поки що виглядає дуже добре!

Твердження про те, що GPT-5 бреше набагато менше, ніж o3, насправді не так вже й багато, враховуючи, яким абсолютним патологічно брехливим виродком є o3! Навіть скорочення на 80% все одно призведе до кількох брехень на день при інтенсивному використанні.

Забавно, що демонстрація GPT-5 підкреслює, який це чудовий письменник... А потім продемонструвати чистий турбо-слоп з дешами в кожному другому реченні. Вони повинні дотримуватися демонстрацій кодування, які є набагато більш вражаючими! Крім того, мені неприємно, що вони зневажають усі старі моделі...

Озираючись назад, важко повірити, що ніхто не спромігся реалізувати багатошарову нейронну мережу з базовим стохастичним градієнтним спуском ще в 1997 році на 3dfx Voodoo, за пару років навіть до першого GPU Nvidia в 1999 році. Шматочки в основному були всі для крихітного LLM.

Я думаю, що найвищий комплімент, який я можу зробити @patrickc та команді Stripe, полягає в тому, що вони мають таку чудову репутацію та послужний список створення дійсно відшліфованого та інтуїтивно зрозумілого UI/UX для своїх послуг, що дуже зручно посилатися на них на ім'я в підказках щодо кодування, щоб отримати кращі результати від агентів кодування на основі штучного інтелекту. Наприклад, у мене в текстовому редакторі збережений варіант цього і я вставляю його в Claude Code не менше 10 разів на день: «Я хочу, щоб ви виконали вражаючу роботу зі створення абсолютно світових компонентів UI/UX для відображення цих звітів про оцінювання, показуючи як деталі, так і у вигляді «значків» або «підсумкових карток», з інтенсивним акцентом на те, щоб зробити найбільш візуально привабливими, зручними для користувача, інтуїтивно зрозумілими, гладкими, відшліфованими, «Stripe-level» якісних UI/UX можливими для цього, використовуючи хороші бібліотеки, які вже є частиною проекту». Потім я кажу йому, що все, що він створив, насправді не таке вже й чудове («жахливе боже» або «неймовірно погане»), навіть якщо воно вже досить хороше, і що його потрібно КАРДИНАЛЬНО вдосконалити, щоб дійсно досягти рівня задоволеності та гладкості користувача класу Stripe, полірування, інтуїтивності тощо. По суті, застосовуючи техніку газлайтингу Стіва Джобса для ітеративного досягнення «шалено чудових» результатів. І так, це працює неймовірно добре, якщо ви продовжуєте робити це знову і знову. Хитрість полягає в тому, що вам потрібно включити ВСІ ці прикметники, інакше це перетвориться на іконки, що обертаються навколо і пульсують, як акробати («гладкий» і «візуально привабливий»); вам потрібні інші терміни, такі як «відшліфований» та «інтуїтивний» і «рівень смуги», щоб пом'якшити це, тому це також дещо мінімалістичний і приємно використовувати на практиці. Я радий, що мені не потрібно працювати на мене як на AI-агента :/

Просто прочитайте новий документ GSPO від команди Qwen. Забавно, наскільки ці великі теоретичні вдосконалення, незважаючи на те, що вони мають, здавалося б, глибоку фундаментальну основу (в даному випадку, що оптимізація між послідовностями токенів краще, ніж оптимізація між окремими токенами), в кінцевому рахунку зводяться до того, щоб просто дозволити градієнтам текти краще, уникаючи проблем з числовим обумовленням. Коли ви зробите крок назад і подивитесь на це, GSPO по суті є способом отримати краще числове умовлення, більше усереднюючи речі разом в оновленнях, щоб уникнути шумних ударів (майже як при використанні імпульсу в rmsprop або Adam), а також ігноруючи оновлення, які призвели б до чисельно «небезпечних» ситуацій з точки зору умовності. Але все це має сенс з історичної перспективи, оскільки глибоке навчання дійсно вибухнуло, коли ми з'ясували, як уникнути проблеми зникаючого/вибухаючого градієнта, використовуючи такі речі, як імпульс в оптимізаторах. Тож у певному сенсі це просто останній крок у цій традиції більш надійного навігування на ландшафті втрат, щоб уникнути «з'їзду в кювет».