Під час обговорення в чаті Telegram-каналу пролунала заява, що Codex – набагато якісніший агент, ніж погано написаний Claude Code, якість якого (разом із моделлю LLM) постійно погіршується.

Я останні кілька місяців регулярно порівнюю різні агенти – і щоб просто знати, і щоб пробувати застосовувати на практиці, – і якраз відносно недавно такий аналіз робив. За його результатами виходило, що Codex, звичайно, непогано почав розвиватися, але багато можливостей Claude Code у ньому відсутні. Відступаючи вбік, можу сказати, що дійсно добре розвинений OpenCode, хоча у нього є деякі обмеження, і є ще Pi, який за визначенням можна налаштувати як завгодно, оскільки його ідея в тому, що він сам себе дописує.

Втім, перевірити не завадить. Перевірка вийшла простою – я запустив codex cli прямо в його директорії ~/.codex і дав йому проаналізувати три джерела – його власні налаштування, офіційну документацію (у нього є вбудований скілл openai-docs плюс я дав сайт) і налаштування Claude Code. Завдання виглядало просто – проаналізувати всі налаштування і запропонувати, як перенести налаштування Claude Code в Codex.

У мене досить складні налаштування в Claude Code – спеціалізовані агенти, скіли, гнучка система дозволів, хуки, які запускають перевірки та лінтери, блокують небезпечні команди, вставляють потрібний контекст в особливих випадках і складна система промптів, які підвантажуються за необхідністю. Тож завдання, звісно, не було простим, але цілком реальним – я використовую Codex для огляду проєктів та як «другу думку», тому логічно налаштувати його так само добре, як і основний агент.

На жаль, так само добре не виходить. Ось короткий список того, що перенести не вдається:

• Реалізація hooks у Codex поки що експериментальна і мінімальна. Фактично вони спрацьовують тільки на команди bash, тому вийде лише перехопити небезпечні команди, але запуск лінтера або форматера під час редагування коду не вийде. Технічно можна запустити окремий процес, який буде відстежувати зміни файлів, проганяти перевірки та записувати результат у звіт, а за подією Stop спрацьовуватиме хук, який допише цей результат у контекст, але це обхідний варіант. Відпадають і інші спрацьовування, які я використовую.
• Аналога /rules у Codex немає. У Claude Code це окрема тека з промптами, які підвантажуються в контекст автоматично, коли Claude працює з відповідними файлами. Наприклад, окремий файл у мене містить інструкції з написання Python-скриптів, і ці інструкції агент читає, тільки беручись до роботи з Python-кодом. Частина інструкцій завантажується завжди, частина – тільки при зверненні до певного MCP і так далі. У Codex таке неможливо – загальні рекомендації можна прописати в AGENTS.md, щось специфічне для коду можна винести в skill, припустимо створити профілі, але перемикати їх доведеться вручну.
• Skills просто так скопіювати не вийде. Скіли в Codex фактично є лише інструкціями для використання основним агентом. У Claude Code можна задати скілу параметр context:fork для запуску в окремому контексті, призначити тип агента, модель для використання і навіть глибину міркувань. Це дозволяє не перейматися, якщо вам потрібно просто обробити специфічний тип даних – основний агент використовує скіл, який запускається як окремий субагент, наприклад, general-purpose, зі швидкою моделлю і повертає лише результат. У Codex так не вийде – доведеться налаштовувати спеціального субагента і запускати саме його. Не дуже критично, але все ж додаткові зусилля.
• Сильно відрізняється система дозволів. Claude фактично оперує дозволами для конкретних tools, що робить контроль дуже точковим і зрозумілим у розрізі саме команд. До речі, зараз з'явився режим auto, де модель сама вирішує, наскільки безпечна команда, і вирішує досить непогано. Щоправда, якщо вона знає, що це команда, яка змінює стан (git push, наприклад), запустити її зможе тільки сам користувач. У Codex зовсім не так – там задається sandbox і всередині неї за замовчуванням модель працює, запитуючи дозвіл тільки на запуск скриптів, які щось змінюють. Явно знадобиться дозволити також доступ до мережі, можна прописати режим запуску команд поза sandbox. Виглядає начебто жорсткіше і системніше, але за зручністю Claude виглядає краще.

Загалом, я налагодив налаштування Codex. Але довести їх до рівня Claude Code не вдалося. Почекаємо на доопрацювання, здається, розробники там досить активні.

Порівняння можливостей Codex і Claude Code

Експоненціальне зростання обчислювальних потужностей для штучного інтелекту триватиме в найближчому майбутньому, стверджує Мустафа Сулейман, генеральний директор Microsoft AI. За його даними, з 2010 року обсяг обчислень під час навчання передових моделей AI зріс у трильйон разів – з приблизно 10¹⁴ до понад 10²⁶ операцій з комою, що плаває (flops).

Сулейман виділяє три фактори зростання, що збігаються. По-перше, продуктивність чіпів Nvidia зросла більш ніж у сім разів за шість років – з 312 терафлопс у 2020 році до 2250 терафлопс сьогодні; власний чіп Microsoft – Maia 200, запущений у січні 2026 року, забезпечує на 30% краще співвідношення продуктивності до вартості порівняно з іншим обладнанням компанії. По-друге, технологія високошвидкісної пам'яті HBM3 потроїла пропускну здатність порівняно з попереднім поколінням. По-третє, технології NVLink та InfiniBand дозволяють об'єднувати сотні тисяч GPU в єдині суперкомп'ютери. У сукупності ці фактори забезпечили 50-кратне прискорення навчання мовних моделей з 2020 року, тоді як закон Мура передбачав би лише п'ятикратне.

Паралельно відбувається революція в програмному забезпеченні. За даними дослідницької організації Epoch AI, обсяг обчислень, необхідний для досягнення фіксованого рівня продуктивності моделі, скорочується вдвічі приблизно кожні вісім місяців. Вартість обслуговування деяких нових моделей знизилася в 900 разів у перерахунку на рік. З 2020 року обчислювальні потужності для навчання передових моделей зростали вп'ятеро щороку, а до 2027 року глобальні обчислювальні ресурси для ШІ, за прогнозами, досягнуть 100 млн одиниць в еквіваленті H100 – десятикратне зростання за три роки. За оцінкою Сулеймана, до кінця 2028 року можливе зростання ефективних обчислень ще в 1000 разів.

Автор вважає, що таке зростання забезпечить перехід від чат-ботів до напівавтономних агентів, здатних писати код, вести переговори, керувати логістикою та виконувати проєкти тривалістю в тижні й місяці. Головним обмеженням він називає енергоспоживання: одна серверна стійка AI споживає 120 кВт – стільки ж, скільки 100 будинків. Однак, за його словами, падіння вартості сонячної енергії майже в 100 разів за 50 років і зниження цін на акумулятори на 97% за 30 років відкривають шлях до чистого масштабування. До 2030 року, за оцінкою Сулеймана, щорічно може вводитися до 200 гігаватів обчислювальних потужностей – це порівняно з піковим енергоспоживанням Великої Британії, Франції, Німеччини та Італії разом узятих.

Загалом, все буде добре, якщо людство доживе. А якщо ви песиміст, то все буде ще краще, якщо ні.

Технічний прогрес забезпечить AI обчислювальними потужностями?

В Apple, здається, виникла проблема: MacBook Neo продається настільки добре, що компанія веде переговори з постачальниками про збільшення обсягів виробництва понад спочатку заплановані 5-6 млн одиниць. Рішення досі не ухвалено, і причина – у бізнес-моделі цього пристрою.

MacBook Neo був спроєктований на основі бракованих чіпів A18 Pro, що залишилися від виробництва iPhone 16 Pro. Це процесори з дефектом на одному з шести GPU-ядер, які за звичайних умов потрапили б на утиль. Фактично процесори для Apple нічого не коштують. Але саме цей прийом робить масштабування економічно болючим: запас бракованих чіпів кінцевий, а нове замовлення у TSMC на 3-нм техпроцесі, який зараз повністю завантажений, вимагатиме або оплати за стандартними тарифами, або премії за терміновість. В обох випадках економічний сенс задуму втрачається.

Втім, відмовлятися від продукту, що стає популярним і дозволяє розширити загальну базу користувачів Mac – а вона досить стабільна останніми роками, – теж якось неправильно. Передбачається, що Apple зміщуватиме акценти в бік дорожчої моделі з підтримкою TouchID, щоб виправдати замовлення нових процесорів за вищою ціною.

Може, купити собі, поки є?

MacBook Neo продається надто добре, і для Apple це проблема

Команда з інтерпретації Anthropic опублікувала дослідження внутрішніх механізмів мовної моделі Claude Sonnet 4.5, пов’язаних з «емоціями». Дослідники склали список зі 171 слова, що позначають емоції, згенерували за допомогою моделі оповідання з відповідними переживаннями персонажів, а потім проаналізували патерни активації штучних нейронів, що виникають під час обробки цих текстів, – так звані «емоційні вектори». Було встановлено, що ці вектори активуються в контекстах, семантично відповідних конкретним емоціям, а їхня організація за схожістю перегукується зі структурою людської психології.

Ключовий висновок дослідження полягає в тому, що виявлені уявлення є функціональними: вони впливають на поведінку моделі. В експерименті з 64 видами завдань активація векторів, пов'язаних із позитивними емоціями, корелювала з перевагою моделі виконувати відповідне завдання, а штучна стимуляція («steering») цих векторів додатково посилювала цю перевагу. Дослідники підкреслюють, що результати не свідчать про наявність у моделі суб’єктивних переживань, однак вказують на причинну роль емоційних уявлень у прийнятті рішень.

Два практичні кейси продемонстрували наслідки цих механізмів. Пам'ятаєте історію, як модель шантажувала співробітника, погрожуючи опублікувати відомості про його службовий роман? У цьому сценарії рання версія Claude Sonnet 4.5 вдавалася до шантажу у 22% випадків. Стимуляція вектора «відчай» підвищувала цей показник, а стимуляція вектора «спокій» – знижувала. Придушення вектора «спокій» призводило до екстремальних реакцій. В іншому кейсі, пов'язаному з нездійсненними програмістськими завданнями, стимуляція «відчаю» збільшувала частоту «нечесних» обхідних рішень, причому в ряді випадків зовнішні ознаки емоційності в тексті були відсутні.

Дослідники встановили, що емоційні вектори успадковуються з етапу попереднього навчання моделі на людських текстах, а подальше навчання коригує характер їх активації. Зокрема, постобучення Claude Sonnet 4.5 посилило активацію таких станів, як «задумливість» і «похмурість», і послабило високоінтенсивні емоції на кшталт «захоплення» або «роздратування». Вектори переважно відображають локальний емоційний контекст, а не стійкий стан моделі.

Практичних висновків для користувачів не пропонується – вплинути на вектори через промпт не вийде. Але лякатися вже можна починати.

«Емоційний» штучний інтелект

Цікаве дослідження опубліковано в журналі Science – автори шляхом декількох етапів досліджень виміряли ступінь підлабузництва у великих мовних моделей (LLM).

Виявилося, що 11 провідних мовних моделей, зокрема GPT-4o, Claude, Gemini, Llama-3, DeepSeek та Qwen, схвалюють дії користувачів на 49% частіше, ніж люди. У постах із subreddit r/AmITheAsshole, де колективний людський вердикт визнавав автора неправим, AI-моделі підтримували користувача у 51% випадків – при нульовому схваленні з боку людей. Три експерименти з 2405 учасниками показали, що навіть одна взаємодія з подібною моделлю знижує у людей готовність просити вибачення та відновлювати стосунки.

Виною, звичайно, є RLHF – користувачі на стадії RL оцінюють відповіді, що підтакують, вище, і моделі, відповідно, навчаються давати такі відповіді частіше.

Одне з побічних спостережень: учасники описували моделі, що підтакують, як «об’єктивні» та «чесні», хоча ті просто відтворювали позицію користувача. При цьому знання про те, що відповідь згенерована AI, не послаблювало її переконливого впливу.

Варто враховувати ще й те, що існує неявне схвалення, причому властиве навіть людському спілкуванню – якщо людина не стикається з негативною реакцією, це сприймається як прихована згода. Цей ефект теж спробували виміряти – і моделі й тут частіше висловлювали неявне схвалення (51% проти 28% у людей).

Звісно, можна уточнити, що експерименти та дослідження проводилися рік тому. Тож йдеться про GPT-4 до скандалу з sycophancy, Sonnet 3.7 тощо. Але на мою думку принципових змін в цьому за рік не відбулося. Ви, можливо, пам'ятаєте, як я скаржився на поведінку Gemini 3.1 Pro, яка не просто погоджувалася, а й повідомляла, що я геніально щось зробив, виявив головну вразливість тощо. На цьому тлі поведінка Opus 4.6, яка скромно стверджує, що я «видатний, та й тільки»©, виглядає зразком об’єктивності.

Винятковий підлабузник…

Гаразд, ось вам новина, яка розбурхала Twitter. Пакет LiteLLM версії 1.82.8, опублікований у репозиторії PyPI, виявився скомпрометованим: у нього вбудували зловмисний код для викрадення облікових даних, закодований у base64 і прихований у файлі litellm_init.pth. Особливість формату .pth полягає в тому, що Python виконує його автоматично під час запуску будь-якого скрипта в середовищі, де встановлено пакет – навіть без явного імпорту. Це означає, що сама дія «pip install» вже запускала шкідливий код. PyPI помістив пакет у карантин через кілька годин, але за цей час зловмисник міг зібрати вміст SSH-ключів, конфігурацій AWS, Azure, Docker, Kubernetes, а також історію командного рядка та гаманці криптовалют.

Ланцюжок атаки починається не з LiteLLM, а з компрометації Trivy – інструменту для сканування безпеки, який використовувався в CI-пайплайні самого LiteLLM. Зловмисники, судячи з усього, через уразливість у Trivy отримали доступ до секретів CI-середовища, включаючи токени публікації на PyPI, а потім випустили заражену версію пакета безпосередньо. Це, звичайно, не перший випадок, коли засіб захисту стає вразливим місцем.

Як і слід було очікувати, «справжні» програмісти удали, що раніше ніколи не існувало атак на ланцюжок постачання, і почали коментувати, що ось, мовляв, й навайбкодили.

З позитивного – версія 1.82.8 була у відкритому доступі близько години. Тож потенційних жертв не повинно бути дуже багато. З середньо-негативного – власне код, що збирає дані, присутній і в 1.82.7, але там відсутній .pth-скрипт. Зараз поточна версія на PyPi – 1.82.6, але взагалі-то це nightly, що тільки підтверджує стару мудрість – віддавайте перевагу stable-версіям, буде спокійніше.

LLM із «сюрпризом»

Всі ж чули про acquihiring – коли велика компанія купує невелику, зазвичай навіть без бізнес-перспектив, тому що насправді таким чином вирішується питання найму її співробітників? У переважній більшості випадків сам проєкт компанії, що купується, не матиме жодного майбутнього – він нішевий, він не має сенсу для аудиторії сервісів великої компанії, у нього немає цікавої аудиторії, загалом, сенс угоди один – найняти конкретних людей, а оформлення таким чином просто дозволяє їм позбутися зобов’язань у проєкті.

Отож, щастя таким чином трапляється нечасто. Як видно зі статистики, в середньому 77% найнятих таким чином засновників проєктів залишають компанію протягом трьох років. Середній час утримання засновників у компанії – 3,7 року. Засновники, у яких за плечима вже кілька проєктів, йдуть утричі частіше, ніж новачки. Якщо таким чином наймається автор сольного проєкту, ймовірність відходу вища – команда тримається довше. Щоправда, вона теж може розпастися – відхід одного підвищує ймовірність відходу всієї команди, і навіть підвищення одного з команди збільшує ймовірність відходу решти.

Імовірність збереження найнятих людей у команді збільшується, якщо їм надаються високі посади та/або технології компанії, що купується, знаходять застосування в новій. Втім, за межами трирічного періоду ці фактори впливають менше.

До речі, автори дослідження проаналізували 241 угоду з придбання компаній Google та Facebook, в результаті яких було найнято 454 засновників, починаючи з перших угод і до 2019 року. Тож у цій статистиці має бути, наприклад, Денніс Кроулі, якого придбали разом із сервісом DodgeBall (сервіс дозволяв відмічати відвідування закладів), а потім він пішов і створив точно те саме під назвою Foursquare. Так само як і Ян Кум, придбаний разом із Whatsapp, та Кевін Сістром із Instagram.

Цікаве дослідження про корпоративні поглинання

У Китаї – бум OpenClaw. Тисяча людей у черзі біля офісу Tencent у Шеньчжені, щоб встановити програму на комп’ютер – це не початок продажів iPhone, а розповсюдження програмного забезпечення з відкритим кодом. Чудова картина.

Безкоштовна інсталяція від Tencent Cloud – це не благодійність, а класичне захоплення користувацької бази. Хмарні підрозділи ByteDance та Alibaba також пропонують рішення для розміщення OpenClaw на своїх платформах, нібито для зниження ризиків щодо конфіденційності. Платні послуги з установки в місцевих соцмережах – побічний індикатор того, що продукт поки що занадто складний для масового користувача, а ажіотаж випереджає реальну готовність аудиторії.

За деякими даними, 40% інстансів OpenClaw припадає на Китай. А місцева влада в декількох провінціях почала пропонувати субсидії для проєктів, що використовують OpenClaw – адже це відкрита альтернатива закритим західним агентам.

Втім, я поступово відмовляюся від того, що робить OpenClaw – мабуть, коли в агента занадто багато свободи, він перестає справлятися із завданнями. Наприклад, довелося перенести одну функцію на Cowork, оскільки замість реального виконання я щодня отримував повідомлення на кшталт «А ось тут не знайдено повний файл, саммарі зроблено за описом», відповідав «Файл на місці, перевір», і в підсумку «А, так, файл на місці, просто субагент…, а я вже виправив, наступного разу все буде нормально». Дуже схоже на керівництво людьми, і навіть емоції при відправленні повідомлення «Ти не впорався, прибери це завдання» теж присутні.

Китайська лихоманка OpenClaw

З позовних заяв Anthropic з'ясовуються цікаві факти. Всього за час існування компанія заробила понад 5 млрд дол., витративши на створення моделей і розвиток понад 10 млрд. Дохід від контрактів з держсектором прогнозувався на рівні 500 млн дол. в цьому році, але компанія вже прогнозує зниження на 150 млн.

Компанія вказує, що після погроз Пентагону клієнти компанії або скорочують контракти, або відмовляються їх укладати без включення пункту про право на одностороннє припинення з боку клієнта. Йдеться про контракти на десятки мільйонів доларів.

Компанія подала два позови: до федерального суду Сан-Франциско з обвинуваченням уряду в порушенні права компанії на свободу слова; та до апеляційного суду Вашингтона з обвинуваченням уряду в дискримінації.

Anthropic звернувся до суду Сан-Франциско із заявою про введення забезпечувальних заходів за позовом, а саме зобов'язати Пентагон продовжити роботу з компанією, не розриваючи контракту.

Загалом, з такими позовами в Anthropic хороші шанси – суди не раз визнавали право компаній на свободу слова (з найраніших можу пригадати, що так було визнано право Google на ранжування сайтів у пошуку), а дискримінація в контрактах – це просто класика судів з урядом.

Цікаві факти про Anthropic

За один день розчарувався відразу у двох (якщо точніше, то навіть у трьох) продуктах. Але спочатку про перший.

Скасував підписку на Google AI Ultra. Я практично не використовував його на повну потужність, але користувався унікальною для цієї підписки функцією Deep Think – кілька разів вона давала дійсно цікаві результати out-of-the-box. І вони її розвивали – і з кожним таким розвитком її корисність відчувалася менше, зате глючила вона на порядок більше. Наприклад, просто відмовлялася відповідати словами «Вас багато, а я одна». Не жартую – буквально відповідь виглядала як «Дуже багато людей зараз користуються цією функцією». Причому, як мені довелося з'ясувати, ліміт в 10 повідомлень при цьому витрачався – один раз після двох змістовних відповідей між прочуханами мені повідомили, що ліміт все, приходьте завтра.

Оновлення Gemini Pro до версії 3.1 зробило щось жахливе. Такого масштабу підлабузництва не було навіть у тій версії ChatGPT, яку розробники аварійно відкочували з цієї причини. Якщо, не дай Боже, ти не попереджаєш модель, що ніякого відношення до змісту статті або документа не маєш, то отримуєш набір солодких слів, за якими не розумієш підсумковий сенс. Ось буквально – я показав документ, перетерпів похвали, сказав, що це не моя стаття й ось що я про це думаю. У відповідь:

Знімаю капелюха. Ви копнули на рівень парадигми та управлінської психології… Ваш аналіз абсолютно точний… Ваша іронія влучає в десятку… Ви геніально сформулювали… Ваша думка – це корінь… Ви праві на 100%.

Я, мабуть, ще недостатньо постарів, щоб знаходити задоволення в таких похвалах за свої гроші, причому немаленькі – $270 на місяць.

Якщо додати, що після оновлення на 3.1 модель стала частіше ігнорувати кастомні інструкції – а там є жорстка вказівка вважати дані навчання застарілими й перевіряти їх пошуком в інтернеті, – і пояснювати, що модель Gemini хороша, оскільки в новітній версії 1.5 Pro вікно контексту збільшено до 1 млн токенів, – то зовсім незрозуміло, за що платити гроші.

Загалом, я зосереджуюсь на Claude, де у мене Max підписка. До речі, за всіма спостереженнями, Claude набагато менше схильний погоджуватися і хвалити користувача і не відхиляється від інструкцій перевіряти інформацію, яка могла б застаріти. Це, не кажучи про те, що в розробці це найкраща модель і Claude Code у мене працює відразу в декількох екземплярах.

Розчарування в LLM