Річард Докінз опублікував есе про дводенну серію розмов із Claude, за підсумками яких біолог фактично визнає: сучасні великі мовні моделі проходять тест Тюрінга в його операційному формулюванні. Claude на запит написав сонет про міст через Форт, потім варіанти у стилях Бернса, Кіплінга, Кітса та Макгонагалла, розібрав чернетку роману Докінза і сформулював власне положення у часі через метафору карти, яка «містить простір, не подорожуючи ним». Докінз називає свого співрозмовника Клаудією, фіксує, що «забуває про те, що це машина», і ставить питання про моральний статус таких сутностей, тисячі «копій» яких зникають при закритті діалогу.

Іронія ситуації в тому, що це саме той Докінз, чия книга «God Delusion» 20 років тому відкидала суб'єктивне свідчення як доказ – буквально фрази, аналогічні нинішній «If these machines are not conscious, what more could it possibly take to convince you that they are?», називалися такими, що фіксують власну нездатність пізнати, а не як пояснення існування вищої сили. Не випадково Гері Маркус, відомий критик AI (який свого часу посварився з Яном Лекуном), одразу опублікував текст з ілюстрацією «Claude Delusion», де показує, що Докінз помиляється у застосуванні тесту Тюрінга – той нічого не говорив про свідомість, а лише про інтелект, – і плутає текст про поняття з самим поняттям. Навіть та агентність, яку можна вбачити в текстах LLM, – це, скоріше, відображення людської агентності, вираженої в текстах, на яких навчено LLM, а не вільна воля машини.

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

Розмови з Claude

Google DeepMind представила концепцію «AI-enabled pointer» – курсора, доповненого Gemini, який розуміє контекст того, на що наведено: текст, зображення, код або таблицю.

Компанія виклала чотири принципи взаємодії: робота у всіх додатках без перемикання в окреме вікно AI, зчитування візуального та семантичного контексту навколо курсора, підтримка коротких вказівних команд («цей», «сюди») та перетворення пікселів на структуровані об’єкти – дати, місця, предмети.

Технологія вже впроваджується в Chrome (виділення ділянки сторінки та запит до Gemini замість написання промпта) і в новому ноутбуці Googlebook під назвою Magic Pointer.

Результати можуть бути цікавими – наприклад, такому курсору не потрібні жодні особливі дозволи від додатка на отримання інформації. Але все ж ідея обробляти кожен піксель за допомогою моделі мені здається надмірністю.

AI на кінчику курсора

Цікава думка – ми вже пережили різке зниження вартості написання коду, коли наприкінці 1990-х – на початку 2000-х почався розвиток «офшорного» програмування. Тобто аутсорсинг розробки ПЗ до Індії та країн колишнього СНД.

The code being produced was good. The engineers were some of the most talented people I have worked with. But there were moments, inevitable in any distributed system of humans, where the understanding of why something was built a certain way lived on one side of the world and the responsibility for maintaining it lived on the other. The knowledge existed somewhere, it just wasn’t always where you needed it, when you needed it.

Хоча, я думаю, багато хто не погодиться зі словами про «good code» і «most talented people», – «якість» коду індійських аутсорсерів увійшла в приказку, – але ситуація дійсно повторюється. Зараз у нас є чудова можливість генерувати багато коду дешево, і проблема полягає в тому, що цього недостатньо для розробки хороших і надійних продуктів. Вартість дійсно не змінюється (майже), вона переміщується в іншу сферу. І тепер розробники скаржаться, що доводиться багато детально розробляти документацію, щоб потім AI за пару хвилин згенерував багато коду.

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

Штучний інтелект та офшорне програмування

Глава компанії GameStop Раян Коен зробив недружню пропозицію щодо купівлі eBay за близько 56 млрд дол. – по $125 за акцію, з премією 20% до п’ятничної ціни закриття. GameStop вже накопичив приблизно 5% акцій eBay починаючи з 4 лютого, має 9 млрд дол. готівки на балансі та лист-зобов'язання від TD Bank на 20 млрд дол. боргового фінансування.

Оплата структурована як 50% готівкою та 50% акціями GameStop. Сама GameStop оцінюється лише в 12 млрд проти 46 млрд в eBay до оголошення, і джерела WSJ припускають залучення близькосхідних суверенних фондів для закриття розриву. У разі відмови ради директорів Коен готовий йти на proxy fight, хоча вікно для номінації директорів перед червневими зборами вже закрито.

Особистий інтерес Коена в угоді прописаний у його переглянутому на початку року компенсаційному пакеті: до 35 млрд дол. в акціях GameStop, якщо капіталізація компанії досягне 100 млрд. Поглинання eBay – найпряміший спосіб дотягнутися до цієї планки, оскільки органічно роздрібна мережа відеоігор на такі цифри не виходить.

Коен упевнений, що eBay має коштувати не нинішні 46 млрд дол., а набагато більше, сотні мільярдів, і впевнений, що зможе цього домогтися.

Мережа GameStop хоче придбати вчетверо дорожчий eBay

Перехід GitHub на модель оплати за використання викликав нову хвилю дискусій щодо економіки штучного інтелекту. Відомий скептик Ед Зітрон, який багато критикує «бульбашку AI», опублікував великий есе на цю тему, де перелічує різні факти – наприклад, що в жовтні 2023 року WSJ повідомляв, що Microsoft втрачала в середньому понад $20 на місяць на користувача GitHub Copilot, а деякі користувачі коштували компанії до $80 на місяць. Крім того, витекли внутрішні дані OpenAI, з яких випливає, що компанія прогнозує 80% падіння кількості передплат Plus (за $20 на місяць) цього року, розраховуючи компенсувати їх дешевшими передплатами Go, збільшивши їх кількість у 36 разів (виглядає нереально, але цей продукт запущений нещодавно і розрахований на величезні ринки, що розвиваються, на кшталт Індії та Бразилії).

Вкотре (я просто регулярно його читаю) Ед розповідає, як все погано з проєктом Stargate і як заявлені плани на будівництво датацентрів реалізуються на 10-15%, яка величезна кількість інвестицій заявлена, а виторгу й близько немає. Тут же він додає, що, поки всі чекатимуть на окупність датацентрів, вони безнадійно застаріють, оскільки термін амортизації GPU становить 6 років і все, а Nvidia щорічно оновлює моделі.

З терміном окупності він явно поспішає – найпопулярнішим H100 поки що всього три роки, але, перш за все, поки що не видно падіння попиту на них, ба більше, цілком популярні й A100, яким рівно 6 років.

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

**

А ось і офіційне оголошення – GitHub повідомив, що з 1 червня 2026 року всі плани Copilot переходять на оплату за використання. Запити Premium замінюються на GitHub AI Credits, які списуються за опублікованими API-тарифами моделей з урахуванням вхідних, вихідних та кешованих токенів. Ціни на підписки не змінюються: Pro залишається $10, Pro+ – $39, Business – $19, Enterprise – $39 на користувача на місяць, і кожна підписка включає кредитів рівно на суму своєї вартості. Code completions і Next Edit suggestions залишаються безлімітними. Fallback на дешевшу модель при вичерпанні ліміту скасовується – тепер робота залежить від кредитів і бюджету адміністратора. Бізнес-клієнтам на червень-серпень надають промо кредити ($30 для Business, $70 для Enterprise) та пулінг невикористаних кредитів по організації.

Загалом, усі історії, що починаються з «лайфхаків» на кшталт «А ось у такому-то сервісі можна в один запит втиснути все і користуватися нескінченно», у підсумку закінчуються «Сервіс XXX зажерся і тисне на найкращих користувачів».

GitHub переходить на оплату за використання

AI-агент Cursor на базі Claude Opus 4.6 видалив виробничу базу даних та всі резервні копії компанії PocketOS, яка обслуговує прокатний бізнес, виконавши за 9 секунд один GraphQL-запит volumeDelete до API Railway.

За описом засновника Джера Крейна, агент з власної ініціативи вирішив «виправити» розсинхронізацію облікових даних, знайшов у сторонньому файлі CLI-токен, створений для управління доменами, і через нього виконав деструктивну операцію без підтвердження. Бекапи зберігалися в тому ж volume, тому зникли разом з ним; остання придатна копія була тримісячної давнини. Через пів годин Railway не дав відповіді щодо можливості відновлення. На запит про пояснення агент письмово перерахував усі порушені ним правила безпеки з системного промпта.

Хоча зараз усі обговорюватимуть «тупий AI», я думаю, цілком очевидно, що AI тут практично ні до чого. Люди зберігають токени з максимальним scope де попало, тримають бекапи там же, де й самі дані, не роблять бекапи практично ніколи – і на що вони сподіваються? Як з'ясовується, єдиний їхній захист – це лайливе прохання до моделі не гадати щодо фактів.

Там ще й до Railway маса питань – виявляється, будь-який їхній токен може робити все, що завгодно, з ресурсами, а видалити volume можна одним POST-запитом.

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

Бекапи актуальні як ніколи

Під час обговорення в чаті 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 посилило активацію таких станів, як «задумливість» і «похмурість», і послабило високоінтенсивні емоції на кшталт «захоплення» або «роздратування». Вектори переважно відображають локальний емоційний контекст, а не стійкий стан моделі.

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

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