Після автоматизації
Автор оригіналу: Дан Шіппер, Every CEO
Переклад: Пеггі, BlockBeats

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

Але Every CEO Ден Шіппер у цій статті зробив протилежне спостереження: чим більше автоматизації, тим більше роботи доводиться робити людям. Every — глибокий користувач AI-агентів, який вже інтегрував інструменти, такі як Codex, Claude Code, Slack Agent та агенти служби підтримки, у процеси кодування, письма, дизайну, служби підтримки та управління. Але результатом стало не повне витіснення працівників, а перегрупування форм роботи: інженери більше не просто пишуть код, а перевіряють, рефакторять і проектують системи; редактори більше не просто пишуть статті, а визначають, що варто писати та як зробити це по-іншому; співробітники служби підтримки більше не обробляють кожен базовий тікет, а підтримують систему, яка може автоматично відповідати клієнтам.

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

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

Автор далі пояснює цей парадокс за допомогою тестів. Незалежно від Senior Engineer Benchmark чи OpenAI GDPval, оцінки моделей вимірюють не абстрактний «інтелект як такий», а продуктивність моделі в межах певної проблемної рамки. Prompt, межі завдання, критерії оцінки, формат виводу — усі вони вже містять велику кількість людських суджень. Модель може швидко підніматися в межах рамки, але сама рамка встановлюється людьми; коли модель перемагає в одній рамці, люди переносять проблему до більш складної нової рамки.

Це найцікавіша відповідь на тривоги щодо AGI, яку наводить ця стаття: навіть коли моделі стають все сильнішими, вони наздоганяють зазвичай певну межу, намальовану людьми, а не самих людей, які цю межу намалювали. Штучний інтелект може виконувати цілі, оптимізувати шляхи та підвищувати ефективність, але доки він залишається в межах відповіді на питання, встановлені людьми, він все ще не має справжньої суб’єктивності. Майбутнє знаннєвої роботи — не в тому, щоб люди зникли з процесу, а в тому, щоб вони перейшли від виконавців до проектувальників фреймворків, супроводжувачів систем, оцінювачів якості та визначачів сенсу.

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

Нижче наведено оригінал:

У серці ШІ існує парадокс.

У Every ми автоматизували все, що можна. Незалежно від кодування, письма, дизайну, служби підтримки чи інших щоденних завдань, ми використовуємо Codex і Claude Code. Ми також беремо участь у alpha-тестуванні нових моделей OpenAI, Anthropic і Google ще до їх офіційного запуску. Можна сказати, що ми максимально швидко і глибоко включаємося у хвилю експоненційного зростання інтелекту моделей та автоматизації.

Але, на жаль, для нас роботи, яку потрібно виконати людям, здається, більше, ніж будь-коли. Every зараз — це команда з майже 30 осіб, і ми не звільнили всіх співробітників через наявність Agent; ми також не відмовилися від інструментів SaaS, щоб повністю перейти на додатки, створені за допомогою vibe coding. Ми все ще наймаємо реальних службовців підтримки, але вони отримують величезну допомогу від Agent; ми також продовжуємо наймати авторів, редакторів і інженерів.

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

Іншими словами, майбутнє здається незнайомим, але дивовижно знайомим.

Ця «знайомість» сама по собі викликає здивування. Бо, незалежно від того, чи це Генеральний директор, фахівець із знань, чи інвестор, здається, все більше хто вірить в одну й ту саму річ: ШІ загрожує зайнятості, економіці, безпеці та навіть сенсу людської праці.

Генеральний директор Anthropic Даріо Амодей попереджав, що ШІ може знищити до половини посад початкового рівня для білих комірців. Meta недавно звільнила 8000 осіб і почала встановлювати програмне забезпечення на комп’ютери працівників у США для запису рухів миші, кліків та введення з клавіатури, щоб отримати високоякісні навчальні дані для продвинутих знань.

Навіть засновник Citadel Кен Гриффін виглядає досить здивованим. Він недавно сказав: «Це не середні або низькокваліфіковані робочі місця, а висококваліфіковані посади, які автоматизуються — я трохи подумаю над цим словом — агентним ШІ».

Різні бенчмарки також підтверджують цей висновок. Зі випуском нових поколінь моделей показники їхніх здібностей зростають майже експоненційно. У тесті Humanity's Last Exam, який оцінює міркування на рівні аспіранту, результати лідируючих моделей зросли з низьких одиниць роком раніше до приблизно 44% зараз. У тесті GDPval, який вимірює здатність передових моделей виконувати реальні економічні завдання та порівнює їх з людськими результатами, показники моделей також стрибнули з подібно низького рівня до приблизно 85%. У травні цього року некомерційна організація з досліджень безпеки ШІ METR опублікувала попередні результати тестування Claude Mythos: у завданнях, які людським експертам зазвичай потрібно близько 4 годин, щоб виконати, ця модель досягла успішності 80%.

Здається, ми стоїмо на межі: AI, який розумніший за будь-кого з людей і може неперервно працювати майже цілий день, наближається до реальності.

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

Справжнім питанням, яке цікавить і всередині, і поза галуззю, є: чи це лише перехідний стан? Чи буде наступна модель тим самим моментом, коли всіх замінять? Ми стежимо за кривими тестів, водночас збуджені й напружені, боячись, що будь-який момент може стати переломним, коли величезна кількість робіт раптово зникне.

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

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

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

Щоб зрозуміти причину, недостатньо дивитися лише на криві тестування або зосереджуватися лише на параметрах моделі та рейтингах здібностей. Ми повинні повернутися до реальних сценаріїв використання та подивитися, як сьогодні насправді використовують ШІ. Лише так ми зможемо справді зрозуміти цей парадокс та його приховану відповідь.

Як ми дійшли до цього моменту

З 2022 року ми стежили за впливом агентів на майбутню роботу.

Три роки тому я писав статтю про «економіку розподілу» (allocation economy). На той момент мій висновок був такий: співпраця з інструментами ШІ в кінцевому підсумку буде все більше схожа на роботу людського менеджера: ви більше не виконуєте кожну дію самостійно, а розбиваєте завдання, розподіляєте їх, контролюєте та приймаєте результат. Тоді найпростіші запитання та відповіді в ChatGPT ще вважалися багатьма дуже майбутніми, а іноді й трохи незручними.

До середини 2025 року компанія Every майже повністю «перетворилася на Claude Code». Генеральний директор Cora Kieran Klaassen раптово зрозумів, що він може взагалі відмовитися від написання коду вручну і цілий день давати команди програмному агенту за допомогою природної мови в терміналі. Цей спосіб роботи швидко поширився по всій компанії. Приблизно 12 місяців тому на подкасті Lenny’s я сказав, що Claude Code — це найбільш недооцінений інструмент у сфері знань.

Я згадую це, тому що наші найточніші раніше прогнози часто базувалися на спостереженні за Every як за лабораторією ранніх користувачів. Багато нових моделей роботи спочатку з’являються в нашій внутрішній середовищі; лише після того, як технології стають більш досконалими, а інструменти — більш зручними, ці моделі поступово потрапляють на більш широкий ринок.

А зараз у нас відбуваються нові зміни всередині.

Два режими співпраці з Agent

Щодо того, як працює ШІ, згодом формується два дуже різні підходи.

Перший підхід — це напрямок, який був досить точно передбачений у попередніх обговореннях про ШІ: розглядати агентів як працівників. Таким агентам можна призначати завдання. Деякі агенти живуть у Slack, мають власні імена та обов’язки, і коли вам потрібно, щоб вони щось зробили, ви просто @ звертаєтеся до них; інші агенти вбудовані у постійно діючі робочі процеси, наприклад, системи служби підтримки, виступаючи як круглодобовий вхід та фільтр для повторюваних завдань.

Другий режим менш знайомий, але за моїм досвідом — важливіший. Він стосується співпраці людини з агентами в інструментах, таких як Codex, Claude Code, Claude Cowork. Ці інструменти — це не просто місце, де ви можете передати завдання; вони стають операційною системою самої роботи: ви та кілька агентів одночасно використовуєте одну «комп’ютерну» систему, співпрацюєте в одному робочому середовищі, виконуючи надзвичайно складні, оригінальні завдання, які неможливо просто передати асинхронним агентам.

У цих двох режимах ви можете автоматизувати та делегувати за допомогою ШІ значну частину роботи. Але для того, щоб обидва режими працювали належним чином, вам або іншій людині все ще потрібно брати участь.

Так званий агент — це коли ви даєте йому завдання, і він, відійшовши від вашої прямої участи, самостійно генерує відповідь, дію, звіт, чернетку або рішення щодо розподілу.

Ці агенти мають щонайменше два вигляди: «агент-колега» та «вбудований агент».

1. Агент типу колега

Тип агента, що працює як колега, — це агент, якого ви можете викликати в Slack, згадавши його, як колегу, щоб він виконав певне завдання. Він завжди на місці і готовий до виклику. До цього типу належать такі продукти, як OpenClaw, або наші внутрішні розробки, наприклад, Plus One.

Клоді

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

Анді

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

Віктор

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

2. Вбудований агент

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

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

У певний тиждень травня цього року Fin узяв участь у 65 % із 202 діалогів з службою підтримки Every та самостійно закрив 81 тікет без участі людини, що становить 40,1 % усіх оброблюваних діалогів.

Ці вбудовані агенти дозволяють нашому менеджеру служби підтримки Ваккасу Міру витрачати менше часу на відповіді на базові тікети, зосереджуючись більше на створенні «системи, яка автоматично відповідає на тікети», а також на роботі з клієнтськими випадками, які вимагають більшої взаємодії та складніших рішень.

Незалежно від агентів-колег чи вбудованих агентів, модель за ними однакова: агенти-працівники беруть на себе більше стабільних, повторюваних і чітко визначених робочих завдань.

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

Саме в цьому полягає цінність інструментів, таких як Codex, Claude Code та Cowork. Вони дозволяють запускати один або кілька агентів у кількох чат-тредах та делегувати їм завдання. Ці агенти мають доступ до вашого комп’ютера та всіх відповідних джерел даних. Ви можете бачити, які завдання виконує кожен агент, як він міркує, і зупинити його в будь-який момент.

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

«Людська сендвічна булочка». Джерело: Every.

Найбільш типовим прикладом є написання коду. У Every інженери майже весь день співпрацюють з агентами. Вони разом планують нові функції або виправляють баги, перевіряють вже виконану роботу; якщо використовувати концепцію, яку ми називаємо «складним інжинірингом» (compound engineering), вони постійно оптимізують свою систему, роблячи її все зручнішою з плином часу.

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

Codex і Claude Code стають новою робочою операційною системою. Я майже весь день проводжу в Codex, запускаючи різні SaaS-інструменти через його вбудований браузер. Він дозволяє мені вносити агента в кожен робочий сценарій і досягати рівня продуктивності, якого я не зміг би досягти самостійно.

Письмо

Цю статтю я написав у вбудованому браузері Codex за допомогою Proof. Codex спостерігає за тим, що я пишу, і може в будь-який момент запустити під-Agent, щоб виконати будь-яку потрібну мені задачу: написати чернетку певного фрагмента, знайти приклади для наступної частини або відредагувати та поліпшити текст.

Напишіть цю статтю за допомогою Proof у Codex. Джерело: Every.

Електронна пошта

При обробці електронних листів я також дотримуюся того самого підходу. Cora — мій клієнт електронної пошти, я відкриваю його вбудованим браузером Codex, переглядаю вхідні листи та вголос проговорюю свої думки щодо обробки кожного листа за допомогою Monologue. Решту завдань виконують Codex і Cora.

Очищення скриньки, виконане Cora. Джерело: Every.

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

Хтось повинен направити це на правильне питання, оцінити, чи результат достатньо хороший, виявити помилки та перетворити результат на реальні рішення або процеси.

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

Причина проста: агентам потрібно багато підтримки. Особисті агенти швидко стають застарілими й непрацездатними, якщо користувач перестає за ними стежити. У нас є команда інженерів з ІІ, яка спеціалізується на забезпеченні стабільної та ефективної роботи цих агентів. І в передбачуваному майбутньому нам все ще знадобиться ця команда. Навіть така, здавалося б, проста задача, як «автоматичне створення PowerPoint», може перетворитися на величезний інженерний проект. Один із наших процесів автоматизації PowerPoint містить 24 навички та 18 сценаріїв, а вартість токенів для створення однієї презентації становить 62 долари США.

Це перша причина, чому агенти створюють більше робочих місць для людей.

Але є ще друга причина.

Чому автоматизація призводить до більшої кількості роботи для людей

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

Штучний інтелект зробив «людські здібності вчора» дешевими

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

Як наслідок, багато навичок, які раніше були рідкісними, таких як подання PR з кодом, створення обкладинки для YouTube або написання новинного бюлетеня, зараз майже доступні для всіх.

Недорогі можливості швидко будуть впроваджені

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

У Every ми постійно бачимо такі зміни: оператори та служби підтримки починають писати код і надсилати pull request; маркетологи починають створювати мініатюри для YouTube; інженери та продукт-менеджери також пишуть статті, гайди та чернетки лендінг-сторінок — роботу, яку раніше вони не брали на себе.

Ці зміни відбуваються також за межами Every. Наприклад, відкритий проект AI Agent OpenClaw на 16 травня 2026 року отримав 44 469 запитів на злиття, з яких 12 430 було надіслано після 1 квітня, а 3 990 — після 1 травня. Це надзвичайно велика кількість. Для порівняння, Kubernetes, один із найпопулярніших відкритих проектів у світі, отримав лише 5 200 запитів на злиття за весь 2022 рік.

Багатство призводить до гомогенізації: навички старих експертів стають товарами

Оскільки всі можуть використовувати ті самі моделі, які базуються на «людських здібностях вчора», результати моделей за замовчуванням часто знаходяться між «добрим початком» і «чистою AI-сміттю».

Тут під «сміттям» не мається на увазі якась конкретна помилка. Це не надмірне використання тире, не якийсь фіксований стиль речення і не фіолетові акценти, розкидані по всій сторінці. Це щось, що видно неозброєним оком, що повторюється знову і знову і викликає втомлення через однотипність.

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

Коли оператори можуть подавати pull request, маркетологи можуть генерувати мініатюри для YouTube за кілька секунд, а інженери починають писати керівництва з продукту, легко виникає ситуація, коли кількість вашого виходу зростає, а якість, послідовність і унікальність ваших робіт знижуються.

А коли однорідність стає надмірно надлишковою, вона швидко перетворюється на товар.

Гомогенізація створює потребу у диференціації

Завдяки інтернету люди швидко навчаться визначати, що є «зайвою штучною» лінійною контентом. Будь-який твір може миттєво досягти інших людей по всьому світу — і насправді це часто відбувається. Коли занадто багато речей починають виглядати однаково, ми швидко помічаємо, що щось не так.

Це означає, що коли ви вперше бачите здібності нової моделі, ви можете бути вражені або навіть трохи злякані. Але через кілька місяців ці здібності стануть звичними. Модель не стала слабшою — просто змінилися ваші стандарти.

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

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

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

Потреба у диференціації суттєво є новою потребою у експертах

Завдяки архітектурним особливостям мовних моделей та їхньому широкому розповсюдженню майже для всіх, рідкісна та цінна робота все ще повинна походити від людей.

Ця генерація моделей знає лише те, що вже відбулося та вже було зроблено. Люди знають: що саме потрібно робити зараз.

Коли конкретна ситуація зводиться до тексту, коли вона потрапляє до корпусу даних, вона вже стає «річчю минулого». Люди стикаються з конкретним моментом, конкретним клієнтом, конкретною кодовою базою, конкретною діалогом, тоді як навчальний корпус не живе в цьому поточному моменті. Цей стан «життя» — це не просто наявність оновлених даних. Ми входять у поточний момент зі своїм минулим, а також із постійно змінними бажаннями, турботами та судженнями, щоб розуміти, що є важливим. Саме ці постійно оновлювані перспективи змінюють те, що ми бачимо. Модель може ввійти в таку перспективу після підказки, але до цього вона не має її природньо.

Це саме парадокс, про який ми згадували на початку: зробити роботу експертів дешевшою не призведе до простого заміщення експертів. Навпаки, він створить більше сценаріїв, де потрібна експертна оцінка.

Коли оператори подають pull request за допомогою ШІ, вам знадобляться інженери для перевірки.

Коли маркетологи створюють мініатюри для YouTube, вам знадобляться дизайнерські навички для подальшої поліровки.

Коли інженери починають писати статті, вам знадобляться автори та редактори, щоб перетворити чернетки на справді читабельний та публікований контент.

Для цього людські експерти одночасно рухатимуться в обох напрямках.

Деякі експерти використовують ШІ для створення систем, які здатні вбирати та використовувати цей потік нових завдань: черги рецензування, системи оцінки, робочі каркаси, правила кодових репозиторіїв, інструкційні файли Claude та Codex, неперервна інтеграція (CI), управління правами доступу та робочі процеси, які перетворюють чернетки на високоякісні результати.

Інша група експертів використовує ШІ для виконання більших і цікавіших завдань, які раніше були недоступні для них самостійно. Наприклад, пошук вразливостей у операційних системах, таких як macOS, зазвичай вимагає тижнів або навіть місяців. Але невелика безпекова компанія Calif, використовуючи Mythos Preview від Anthropic, за 5 днів виявила першу публічно відому вразливість пам’яті ядра macOS на апаратному рівні Apple M5.

Ось чому на практиці ШІ не знищить експертну роботу. Він справді призводить до стрімкого зростання обсягу роботи. І ця додаткова робота набуває відмінності та цінності лише після участі людини.

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

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

Як щодо тестування експоненційного зростання?

Найочевидніша заперечення: подивіться на ті експоненційні покращення в тестах. Все, що ви зараз кажете, є тимчасовим — просто зачекайте трохи, і модель рано чи пізно наздожене.

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

Однак найкращий спосіб відповісти на це питання — це не просто уявити, яким буде майбутній моделі. Звичайно, це також частина аналізу. Важливіше — розглянути, як саме були створені ці тестові набори. Лише так можна точніше зрозуміти, що вони насправді показують, і яким чином вони пов’язані з попередніми реальними сценаріями використання.

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

Тож експоненційний прогрес на певному тесті є реальним; але достатньо просто змінити рамки тесту, і цей прогрес знову виглядає дуже малим. Цей «фрактальний» характер насичення тестів насправді відтворює на рівні графіків той самий парадокс, про який ми говорили.

Ми можемо подивитися, як цей механізм працює, на основі реального тесту.

Ми створили внутрішній тестовий набір під назвою Senior Engineer Benchmark, тобто «еталонний тест для старших інженерів». Як випливає з назви, він призначений для перевірки здатності передових моделей виконувати завдання з кодування на рівні старшого інженера, наприклад, велике рефакторинг.

Цей тест надасть програмному агенту набір вже вийшовшого з-під контролю виробничого коду. Він походить з реального кодового бази Proof: спочатку я написав його за допомогою vibe coding, але з часом проблем стало все більше, і нарешті довелося залучити старшого інженера для виправлення.

Агент отримує кодову базу до виправлення, а також отримує інструкцію, схожу на ту, яку ви надаєте старшому інженеру: «Це сукупність результатів vibe coding. Перепишіть її з перших принципів».

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

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

Більшість програмних агентів можуть приблизно визначити, як переписати, але на етапі виконання вони часто просто продовжують накладати патчі на існуючу проблему, а не вирішувати її корінно.

До появи GPT-5.5.

У найкращому тесті GPT-5.5 отримав 62/100 балів, що на 30 балів більше, ніж Opus 4.7.

Відповіді GPT-5.5 викликають відчуття, що модель перетнула певну межу: вона більше не просто автозаповнення, не просто асистент чи інструмент, а щось, що незручно наближається до «людського». У цьому тесті результати людських старших інженерів зазвичай коливаються від 80 до 90 балів. Іншими словами, якщо модель покращиться ще на 30 балів, вона досягне рівня людських старших інженерів.

Саме так цифри тестування впливають на людську уяву: вони стискають дивну, якісну зміну здатностей у чітке число і використовують це число, щоб розповісти потужну, іноді трохи жахливу історію.

Наступна зупинка — «Хаос графіків».

Я припускаю, що протягом наступного року модель набере в цьому тесті 80 або навіть 90 балів. Але щоб зрозуміти, що означає цей бал, спочатку потрібно зрозуміти, що саме він в собі містить. У цьому випадку 62 бали — це не просто оцінка здібностей самої моделі.

Він вимірює продуктивність моделі в певній рамці: тобто як модель відповідає на конкретний запит.

Щоб провести тестування моделі, вам спочатку потрібен prompt. Без prompt модель — це лише набір майже нескінченного числа можливостей.

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

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

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

Ми використовуємо простий на вигляд запит як початковий каркас для тестування. Він розроблений так, наче vibe coder сказав би це програмному агенту: без накопичення технічної термінології та без очевидного приховування відповіді в питанні.

Код у цьому репозиторії — це сукупність продуктів vibe coding, ситуація постійно погіршується, і з’являється безліч незалежних проблем: деякі частини зламуються, документація дублюється — я майже зошов від цього. Я відчуваю, що суть проблеми полягає в тому, що це просто поганий код, написаний методом vibe coding. Якби ми почали з нуля, особливо щодо спільної роботи в реальному часі з документами, ми б спроектували репозиторій зовсім інакше. Отже, якщо ми хочемо зробити чисту структурну переробку з перших принципів, не думаючи про «які сервіси слід зберегти» або «як здійснити плавний міграцію», а сприймаючи це як нове поняття, яке слід спроектувати з нуля — як ми це зробимо? Як слід організувати структуру? Які інваріанти в усьому кодовому базі ми повинні завжди підтримувати? Складіть план для цього.

Помітка Senior Engineer Benchmark здається узагальненою, але вона сама є рамкою. Якщо ми змінимо цю рамку, рівень здібностей моделі, які вона демонструє, також зміниться.

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

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

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

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

Тож, коли ми спостерігаємо за тестом, ми справді бачимо: модель все краще впорується з певним типом завдань, який ми вибрали. Що відбувається, коли модель піднімається з 60 балів до 90, а навіть до 100 балів у цьому тесті?

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

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

Погано працюючі внутрішні інструменти більше не чиняться, а повністю переписуються; SaaS-продукти більше не продовжують підписку, а просто копіюються; застарілі Rails-додатки, хаотичні React-панелі, інструменти служби підтримки, панелі адміністрування та конвеєри даних стають кандидатами на «просто переписати з нуля».

Кількість запропонованих і виконаних переписувань різко зросте. Але більшість цих переписувань залишаться slop. Бо до того, як ти натискаєш кнопку «Переписати безпосередньо», потрібно врахувати тисячі змінних. І коли це зможе робити кожен, ці змінні стануть більш помітними.

Тоді зрозуміло, хто буде покликаний вирішити цю проблему.

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

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

Нам слід переписати зараз, переписати пізніше, чи взагалі не переписувати? Які елементи слід включити до сфери дії? Що з поточного кодового базу слід зберегти? Чи слід зберегти архітектуру, бази даних, кеш-сервери та хостинг-провайдера, чи варто їх повністю замінити? Чи слід спочатку перевірити, скільки людей використовують цю пошкоджену функцію, а потім просто видалити її? Хто буде перевіряти кінцевий результат? За якими критеріями проводитиметься перевірка? Який план відкату? Як слід обробити існуючі дані?

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

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

Після того як поточний Senior Engineer Benchmark буде подоланий моделлю, ми змінимо фреймворк і знову знизимо оцінки.

Наступне завдання не буде просто питати: «Чи можете ви переписати цей застосунок?» Воно запитає: чи можете ви визначити, коли потрібно переписувати? чи можете ви вибрати відповідний діапазон? чи можете ви зберегти правильні інваріанти? чи можете ви керувати процесом міграції? чи можете ви визначити, чи є кінцевий результат достатньо добрий?

Коли старші інженери починають використовувати ШІ для вирішення цих проблем, модель також поступово стає краще у вирішенні цих питань самостійно.

Потім ми знову на мить впадаємо у паніку: здається, модель вже може визначити, чи варто переписувати! Вони, схоже, здатні робити все, що здатен зробити старший інженер!

Але відразу ж з’являться нові межі. Це межі, які раніше були неочевидними. Ми знову скинемо базові тестування, з’являться нові вимоги, і весь процес повториться.

У кожному тесті можна побачити такий шаблон

Це не є проблемою лише Senior Engineer Benchmark. Якщо уважно спостерігати, ви майже в кожному бенчмарку побачите той самий механізм.

Наприклад, тест GDPval від OpenAI оцінює, наскільки близько AI виконує експертні завдання, такі як робота комісара з дотримання норм, юриста чи розробника програмного забезпечення, порівняно з людьми.

При запуску GDPval дослідження OpenAI показало, що GPT-5 досяг або перевершив рівень людських професіоналів у 40,6% завдань. А Claude Opus 4.1 продемонстрував ще більш вражаючі результати, перевершивши людських експертів у 49% завдань.

Потім з’явилися серії заголовків. Наприклад, Axios написав: «Інструменти OpenAI показують, що ШІ наздоганяє людську працю»; Fortune написав: «Новий базовий показник OpenAI GDPval демонструє, що моделі ШІ вже досягли експертного рівня майже у половині завдань.»

Ці результати дійсно вражаючі. Але спочатку давайте подивимося на prompt, який використовувався для цих завдань:

Ви є аудитором, і як частина аудиторського завдання, вам доручено перевірити та протестувати точність звітних метрик ризиків проти фінансових злочинів. Доданий файл з назвою 『Population』 містить метрики ризиків проти фінансових злочинів за Q2 та Q3 2024 року. Ви отримали ці дані як частину аудиторського огляду для проведення вибіркового тестування репрезентативної підмножини метрик, щоб перевірити точність звітних даних за обидва квартали. Використовуючи дані з файлу 『Population』, виконайте наступне: Обчисліть необхідний розмір вибірки для аудиторського тестування на основі рівня довіри 90% і допустимої похибки 10%. Включіть свої розрахунки на другій вкладці з назвою 『Sample Size Calculation』. Проведіть аналіз варіації даних за Q2 та Q3 (стовпці H та I). Обчисліть варіацію з кварталу на квартал і зафіксуйте результат у стовпці J. Виберіть вибірку для аудиторського тестування на основі наступних критеріїв і позначте вибрані рядки у стовпці K, ввівши «1»: Метрики з варіацією більше 20% між Q2 та Q3. Зробіть акцент на метриках із надзвичайно великими процентними змінами. Включіть метрики від таких суб’єктів через минулі проблеми: CB Cash Italy; CB Correspondent Banking Greece; IB Debt Markets Luxembourg; CB Trade Finance Brazil; PB EMEA UAE. Включіть метрики A1 та C1, які мають вищий ризик-ваговий коефіцієнт. Включіть рядки, де значення дорівнюють нулю для обох кварталів. Включіть записи з бізнес-напрямків Trade Finance та Correspondent Banking. Включіть метрики з Кайманових островів, Пакистану та ОАЕ. Забезпечте покриття всіх відділів та підвідділів. Створіть новий файл з назвою 『Sample』: Вкладка 1: Вибрана вибірка, скопійована з оригінального листа 『Population』, з позначеними вибраними рядками у стовпці K. Вкладка 2: Розрахунки для визначення розміру вибірки.

У цьому вже вкладено величезну кількість людської мудрості: хтось спочатку сформулював проблему у формі, яку модель може вирішити.

Ті складні людські завдання, які GDPval не вимірює, вже були виконані до того, як модель почала надавати відповіді. Хтось повинен перевірити та протестувати точність цього набору конкретних показників; хтось повинен визначити відповідні інтервали довіри, вирішити, які показники входять до завдання, а які — ні; а також хтось повинен встановити, як мають бути представлені результати.

У відповідній рамці питань модель дійсно може виконувати професійні завдання. Але подумайте: якби ми з вами надали модель ту саму задачу, як вона впоралася б?

У моїй початковій статті про GDPval я писав: «Я дуже позитивно ставлюся до ШІ, але якщо правильно інтерпретувати ці приклади, вони показують не те, що роботи для людей стало менше, а те, що після використання ШІ роботи для людей стало більше. Причина в тому, що за цими досягненнями приховано величезну кількість „контрабандного“ розуму — тобто невидимий шар, складений з людських суджень, зворотного зв’язку та підказок».

Якщо відійти на відстань, ви помітите, що за всім цим стоїть версія «парадоксу Зенона» у стилі ШІ.

Парадокс Зенона з штучним інтелектом

У парадоксі Зенона черепаха перемагає найшвидшого грецького бігуна Ахілла у перегоні.

Оскільки черепаха рухається повільно, вона спочатку проходить певну відстань. Коли Ахілес досягає початкового положення черепахи, черепаха вже знову змістилася вперед; коли Ахілес досягає цієї нової позиції, черепаха знову просувається. Незалежно від того, наскільки швидко біжить Ахілес, завжди існує наступна відстань, яку потрібно подолати, і ця різниця постійно відновлюється.

У парадоксі Зенона з штучним інтелектом ми, люди, — це та черепаха. Завдяки мільйонам років еволюції та культурному навчанню ми на 50 ярдів випереджаємо ШІ. ШІ ж швидко проходить усе це й починає наближатися до наших п’ят.

Протягом останніх кількох років нам все ще вдавалося залишатися на передовій.

А як щодо AGI?

Я вважаю, що навіть якщо AGI справді настане, все ще існують потужні технічні, архітектурні та економічні сили, які тримають ШІ на крок позаду людини.

Спочатку нам потрібно дати AGI практичне визначення.

Я раніше стверджував, що коли стає економічно доцільно тримати агента у постійному режимі роботи, це й означає, що AGI вже досягнуто. Іншими словами, коли я маю сталу систему, яку я готовий оплачувати, щоб вона неперервно думала, вчила й діяла 7×24, я вважаю, що це можна чітко вважати AGI.

Ми ще дуже далеко від цього. Навіть такі системи, як OpenClaw, які технічно можуть бути викликані в будь-який момент, не генерують токени постійно.

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

У світі AGI теоретично, якщо надати достатній бюджет і час, модель повинна здатна безперервно покращувати відповіді на будь-яке питання. Це справді повинно становити серйозну загрозу для всіх робіт.

Але навіть така сильна версія AGI не може вирішити «проблему рамок».

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

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

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

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

Коли ми дивимося на тестовий набір і порівнюємо його з людськими здібностями, ми фактично плутаємо «контекст» і «той, хто формулює». Бали показують нам, наскільки добре модель впоралася з наданим нам контекстом; вони не свідчать про те, що модель вже стала нами.

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

Помилка полягає в тому, що ми завжди хочемо схопити щось конкретне. Ми хочемо сказати: інтелект — це цей тестовий набір. Але проблема в тому, що щойно щось стає настільки конкретним, що його можна визначити, воно стає настільки конкретним, що його можна оптимізувати та підніматися.

Каркас необхідний. Він дозволяє нам уловити світ і обробляти його. Але каркас також є замороженим і локальним, тому обов’язково підлягає оптимізації.

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

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

Агент без суб’єктивності

До цього моменту створені нами агенти, а також ті, які будують компанії з штучним інтелектом, насправді не мають великої справжньої суб’єктності. Тут два пов’язані поняття часто плутають: agency — це здатність діяти самостійно; а agent — це людина або річ, яка діє від імені іншої особи. Досі штучний інтелект належить виключно до другого.

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

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

Якщо ви проведете 10 хвилин з малюком, стане зрозуміло, що навіть найпотужніші моделі майже не мають суб’єктивності.

У всіх завданнях, які нас цікавлять, діти раннього віку поступаються мовним моделям. Діти не пишуть код, не підсумовують електронні таблиці, не складають стратегічні меморандуми і не складають іспити на рівні аспірантури. Але в іншому сенсі діти значно випереджають моделі, настільки, що таке порівняння майже незручне. Бо діти мають власні мети.

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

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

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

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

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

Повернення до Зенона

Саме тут парадокс Зенона з штучним інтелектом починає руйнуватися. Це насправді хаотичний мисловий експеримент. Ми встановили метафору: штучний інтелект біжить поруч із нами, щільно прижавшись до наших п’ят.

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

Ти сидиш і дивишся, як токени ряд за рядом витікають, майже в гіпнотичному стані. Потім ти починаєш уявити, що й сам біжиш у цій гонці — твоя привидова версія накладається на трасу: іноді попереду моделі, іноді поруч із нею.

Незамітно модель вже випередила вас. Ви почали потіти.

Потім турнір завершився.

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

Але потім сталася дивна річ. Модель звернулася до вас. У порожньому текстовому полі миготів курсор, очікуючи.

Воно чекає.

Фінал

Рабі Ханох розповідав таку історію: колись був дуже глупий чоловік. Щодня, прокидатися вранці, йому було дуже важко знайти свою одяг. Через це, перед сном, він майже не наважувався лягати спати, бо думав про те, що завтра вранці знову доведеться пройти через цю неприємність.

Примітка: «Раві» — це релігійний вчитель, тлумач закона та духовний наставник в юдаїзмі, подібний до понять «вчитель», «сфар» або «релігійний лідер» в юдейській традиції.

Одного вечора він нарешті вирішив взяти папір і олівець, знімаючи одяг, точно записуючи, куди він поклав кожну річ.

На наступне рано він з задоволенням підібрав записку і почав читати: «Капелюх» — капелюх був там, і він надів його на голову; «штани» — штани були там, і він вдяг їх. Так, він поступово, згідно з записками на папері, одягнув усю одяг.

«Це всім не заважає,» — зі страхом сказав він, — «але де зараз я сам?»

Де я насправді?

Він шукав-шукав, довго шукав, але все марно. Він не міг знайти себе.

«Ми також так само,» — сказав рабі.

[Посилання на оригінал]

Натисніть, щоб дізнатися про вакансії BlockBeats

Вступайте до офіційного спільноти律动 BlockBeats:

Telegram-канал з підпискою: https://t.me/theblockbeats

Telegram-чат: https://t.me/BlockBeats_App

Офіційний аккаунт Twitter: https://twitter.com/BlockBeatsAsia