Штучний інтелект уже перестав бути «допоміжним інструментом» і дедалі частіше виступає повноцінним працівником. Роман Ямпольський, професор з безпеки AI в Університеті Луїсвілля, який понад 15 років досліджує питання «чи можемо ми контролювати штучний інтелект», дивиться на це без ілюзій. На його думку, у довгостроковій перспективі всі види праці можуть бути автоматизовані комбінацією AI та робототехніки, а традиційні кар’єрні сходи — від джуніора до сеньйора — руйнуються вже зараз.

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

Від «можна автоматизувати» до «вирішили автоматизувати»

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

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

Ямпольський підкреслює: його прогноз «99% робочих місць до 2030 року» стосується саме можливостей AI, а не фактичної дати, коли компанії натиснуть кнопку «звільнити всіх». Проте для окремих категорій працівників цей розрив між можливістю та впровадженням уже майже зник.

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

Перші жертви: перекладачі й молодші програмісти

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

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

Ще більш показовий кейс — програмування. Саме IT довго вважали «професією майбутнього», але саме тут AI починає роз’їдати основу кар’єрної піраміди.

Ямпольський наводить конкретну цифру: його кафедра комп’ютерних наук зафіксувала 28% падіння кількості кооперативних стажувань (co‑op placements) — тих самих перших оплачуваних позицій для студентів, які дозволяють увійти в професію. Попит на джуніорів і студентів, що «прийдуть, щоб їх навчали», різко скорочується.

Молодші програмісти, які вміють лише C або C++, більше не виглядають привабливим активом для компанії, якщо значну частину їхньої роботи може виконати AI‑система, а старші інженери можуть напряму взаємодіяти з моделями, минаючи проміжну ланку.

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

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

Коли робот стає «співробітником»: когнітивна праця сьогодні, фізична — завтра

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

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

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

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

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

Хто вирішує, чи залишити людину: компанія, клієнт чи ринок?

Якщо всі роботи технічно можна автоматизувати, постає питання: хто і за якими критеріями вирішуватиме, де все ж таки залишити людину?

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

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

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

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

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

Зламані кар’єрні сходи й кінець «нормальної» побудови статків

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

Якщо стартові позиції — джуніорські ролі, стажування, co‑op — зникають, ця модель перестає працювати. Ямпольський прямо говорить: традиційні шляхи накопичення багатства через «просто мати роботу» можуть стати недоступними в світі, де існує штучний загальний інтелект (AGI), здатний виконувати будь-яку когнітивну працю на рівні людини.

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

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

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

Гіперекспоненційний прогрес і стиснення часових горизонтів

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

Це видно навіть у зміні очікувань щодо термінів появи AGI. Якщо раніше багато експертів і ринки прогнозували 2045 рік, то зараз, за його словами, прогнозні ринки змістилися до діапазону 2028–2030 років. Тобто те, що ще недавно вважалося справою середини століття, тепер обговорюється як подія найближчих кількох років.

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

Це стискання часових горизонтів робить традиційні освітні та кар’єрні стратегії ризикованими. Якщо навчання на лікаря чи інженера триває 6–10 років, а прогнозований горизонт радикальної автоматизації — 3–5 років, питання «чи встигну я відбити інвестицію в освіту» перестає бути теоретичним.

Світ із безкоштовною працею: невідомі для економіки

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

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

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

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

Висновок: робота як опція, а не як основа життя

Якщо підсумувати позицію Романа Ямпольського, картина виглядає так: технічно ми рухаємося до світу, де майже будь-яку роботу — розумову й фізичну — можуть виконувати AI‑системи й роботи. Першими під удар потрапляють когнітивні професії, особливо ті, що пов’язані з формалізованими завданнями: переклад, базове програмування, рутинна офісна робота. Кар’єрні сходи, які трималися на масовому наймі джуніорів, уже дають тріщину, що видно навіть у статистиці університетських програм.

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

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

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

Джерело

AI Safety Expert: No One Is Ready for What’s Coming in 2 Years | Roman Yampolskiy

На конференції TED вийшов незвичний експеримент: організатори попросили ChatGPT сформулювати, що він сказав би людству, якби міг прочитати TED Talk. Отриманий текст перетворили на сценічну промову за участі оповідача та художниці, поєднавши сучасні AI‑інструменти з традиційним сторітелінгом. Результат — короткий маніфест про людську вразливість, силу й відповідальність у добу технологій.

Людство між дивом і руїною

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

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

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

Слабкість, сльози й межі як джерело мудрості

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

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

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

Сила, технології й різниця між інтелектом і мудрістю

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

Людство вже володіє можливостями, які предки вважали б «божественними». Проте фундаментальні питання залишаються тими самими:
– чи можна будувати, не «пожираючи» все навколо;
– чи можна ставати потужнішими, не перетворюючись на монстрів.

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

Якими предками ми хочемо стати

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

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

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

У підсумку експеримент із «першою AI‑промовою» на TED не стільки про штучний інтелект, скільки про людей. Машина, створена з людських текстів і даних, повертає аудиторії дзеркало — з акцентом не на потужності алгоритмів, а на тому, як ми розпоряджаємося власною людяністю.

Джерело

The World’s First AI TED Talk | TED

Claude Code часто сприймають як ще один інструмент для розробників. Але в новому відео на каналі Austin Marchese цей продукт Anthropic показують зовсім з іншого боку: як основу для персональної AI-операційної системи, що вчиться на ваших діях, запам’ятовує контекст і з часом працює дедалі краще.

Три папки, з яких починається «AI-операційка»

Базова ідея — побудувати на комп’ютері проєкт Claude Code з трьома ключовими папками:

• skills — «робочі руки» системи, тобто навички (skills), які виконують завдання
• knowledge — база знань, що робить ці навички розумнішими
• projects — вихідні результати роботи (звіти, скрипти, листи тощо)

Claude Code працює з файлами (переважно .md або .txt), тож зручно переглядати й редагувати все це не через термінал, а через менеджер нотаток на кшталт Obsidian. У результаті користувач отримує не просто чат із ШІ, а структурований робочий простір, де AI постійно дописує, оновлює й покращує файли.

Два типи навичок: виконання та розвиток системи

Усі навички в Claude Code пропонується ділити на два класи:

1. Execution skills (виконавчі навички)
   Це повторювані завдання, які ви робите регулярно:
2. створення щотижневих звітів
3. аналіз email-листування
4. аналіз воронки продажів
5. підготовка шаблонних документів

Логіка проста: якщо ви робите щось 2–3 рази на день, за однаковим патерном, і вам допоміг би попередньо завантажений контекст — це кандидат на окрему навичку.

Для виявлення таких завдань пропонується:
– або пройти «inner loop test» (перевірити себе за трьома питаннями вище),
– або попросити Claude Code:
«На основі моєї минулої активності запропонуй 5 навичок, які варто створити. Фокусуйся на завданнях, які я роблю більше двох разів на тиждень».

1. Foundational skills (фундаментальні навички)
   Вони не просто економлять час тут і зараз, а покращують всю систему з кожною сесією.
   Суть: після кожної взаємодії з Claude Code фіксується:
2. що спрацювало
3. що не спрацювало
4. які висновки можна зробити

Ці дані зберігаються в папці knowledge і надалі використовуються всіма навичками. Так система перестає повторювати ті самі помилки.

Один із прикладів — навичка generate personalized training data, яка переглядає останні сесії, витягує інсайти й формує з них тренувальні дані. Аналогічний ефект можна отримати, просто регулярно просивши Claude:
«Що ми сьогодні дізналися? Збережи ключові висновки в папку knowledge».

Ключовий принцип тут добре формулює бізнес-автор Алекс Хормозі: AI — це не магія, а множник. Перевага не в доступі до найкращої моделі, а у володінні найкращими даними. Саме тому фундаментальні навички, що збирають і структурують ваш досвід, стають критичними.

Автоматизація: hooks, loops і schedules

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

У Claude Code для цього є три механізми:

Hooks: реакція на події

Hook — це тригер, який спрацьовує автоматично, коли відбувається певна подія:

• завершилась сесія
• змінено файл
• виконано завдання

Наприклад, можна налаштувати хук, який після кожної сесії запускає навичку-рекап:

• що було зроблено
• що спрацювало / не спрацювало
• які знання варто зберегти

І автоматично записує це в папку knowledge. Формулювання для Claude може бути простим:
«Створи hook, який запускає підсумок сесії щоразу, коли я завершую розмову, і зберігає висновки в папку knowledge».

Loops: періодичні перевірки

Loop — це завдання, яке запускається з певним інтервалом. Наприклад:

/loop 10 minute check project

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

Schedules: завдання за розкладом

Schedule схожий на loop, але прив’язаний до конкретного часу. Наприклад, щоденний запуск навички analyze funnel о 6:00 ранку:

• аналіз усіх соцмереж
• аналіз продуктів / пропозицій
• формування списку інсайтів і можливих дій

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

Масштабування: як не перетворити систему на хаос

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

1. Проблеми — частіше у навичках, а не в моделі

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

• інструкції нечіткі або суперечливі
• у навичку завантажено забагато контексту
• різні фрагменти знань конфліктують між собою

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

2. Жодних перетинів між навичками

Кожна навичка має бути:

• чітко визначеною
• відокремленою від інших
• відповідальною за один зрозумілий результат

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

3. Одна навичка — кілька сценаріїв

Якщо є завдання з кількома варіантами виходу (наприклад, звіт у PDF або CSV), не варто створювати дві різні навички. Краще:

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

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

4. Ставитися до бази знань як до кодової бази

Коли навичок і знань стає багато, їх варто вести так само, як інженери ведуть код:

• зберігати все в GitHub
• фіксувати зміни (оновлення навичок, додавання консультантів, правки знань)
• синхронізувати зміни між членами команди

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

Практичні кейси: від інженерних звітів до контент-машини

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

Автоматизація інженерних звітів

Один із кейсів — інженерна компанія, якій потрібно було підготувати понад 80 звітів з викидів вуглецю (Local Law 97). Раніше це була двотижнева робота.

Підхід:

• разом з інженером за ~2 години створили навичку /LL97-report
• навичка генерує звіт у потрібному форматі
• після кожної партії запускали /improve skill, щоб навичка вчилася на помилках

Результат: те, що займало 5 годин, тепер робиться за 5 хвилин. Компанії не потрібно наймати додаткових людей під цей процес.

Контент-продакшн як ланцюжок навичок

Для створення контенту використовується ціла низка пов’язаних навичок:

• YouTube-script-writer
• читає патерни голосу автора
• аналізує попередні скрипти
• враховує поради «консультантів»
• враховує дані про аудиторію

• генерує чернетку сценарію

• панель консультантів

• окремі файли в папці knowledge/consultants, наприклад, з матеріалами Алекса Хормозі

• Claude Code може «звертатися» до цих консультантів, аналізуючи скрипт з різних точок зору

• newsletter-writer

• бере готовий скрипт
• переформатовує його в email-розсилку

Цей підхід називається skill chaining — послідовне використання кількох навичок, які передають результат одна одній.

Консультанти, аудиторія та «/me»

У папці knowledge зберігаються кілька важливих підпапок:

• consultants — «оцифровані» експерти: книги, транскрипти, матеріали з відкритих джерел, зібрані в єдині профілі. Claude Code може звертатися до них як до віртуальних радників.
• audience — відповіді реальних глядачів/читачів на інтерв’ю; система використовує їх, щоб оцінити, наскільки контент «зайде» цільовій аудиторії.
• /me — дані про самого користувача:
• патерни голосу
• життєва історія
• щоденні інсайти й нотатки

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

Як запустити власну систему: мінімальний стартовий план

Для тих, хто хоче повторити підхід, пропонується простий «стартовий пакет»:

1. Створити структуру проєкту
2. Папки skills, knowledge, projects у Claude Code-проєкті.

3. Налаштувати зручний перегляд (наприклад, через Obsidian).

4. Заповнити папку knowledge про себе

5. Запустити навичку на кшталт interview me (через плагін BuildPartner або просто попросити Claude провести інтерв’ю).

6. За можливості використати інструменти на кшталт Hexter WhisperFlow, щоб надиктовувати інформацію голосом і автоматично отримувати транскрипти.

7. Налаштувати один hook

8. Hook, який після кожної сесії запускає рекап і зберігає висновки в knowledge.
   Це вже створює базовий рекурсивний цикл покращення.

9. Через тиждень — зафіксувати уроки

10. Зібрати, що спрацювало, що ні, які навички варто уточнити.
11. Передати ці висновки назад у систему як нові знання.

У підсумку Claude Code перестає бути просто інструментом для коду й перетворюється на довгострокову інфраструктуру — персональну AI-операційну систему, яку можна розвивати роками, так само як інженери розвивають кодову базу продукту.

Джерело

Claude Code Isn’t for Coding. Here’s What It’s ACTUALLY For. — YouTube

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

AI як загроза не лише робочим місцям, а й самій інновації

США вже мають сильні позиції: доступ до енергії, найкращі чипи, провідні AI-компанії та моделі. Але цього недостатньо, якщо паралельно мільйони працівників опиняться «під ніж» автоматизації.

Логіка проста:

• масові звільнення → економічний спад;
• економічний спад → соціальна напруга й політичні потрясіння;
• політичні потрясіння → надмірне, «каральне» регулювання AI.

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

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

Чому нинішні системи освіти й підтримки працівників не витримають удару AI

Освіта, відірвана від ринку праці

Сучасна американська модель інвестує сотні мільярдів доларів у заохочення вступу до коледжів — без прив’язки до того, чи:

• отримує людина диплом;
• здобуває релевантні навички;
• знаходить роботу за фахом.

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

Показовий приклад — розгортання виробництва чипів TSMC у США. Компанія чітко сформулювала потребу: інженери-електрики та оператори обладнання. У відповідь було створено прискорені сертифікаційні програми, курси в коледжах та apprenticeships, спеціально «заточені» під ці вимоги. Результат — TSMC успішно виробляє передові AI-чипи в Аризоні, а робочі місця отримують люди з конкретно підготовленими навичками.

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

«Освіта один раз і назавжди» більше не працює

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

Більшість критично важливих навичок люди опановують уже на роботі. Але гнучких, доступних і масових форматів «заробляй, навчаючись» бракує. Приклад фахівця з IT, який у 30+ років вирішує перейти в HVAC (системи опалення, вентиляції, кондиціювання), показує системний збій: навчання триває понад рік, коштує грошей і не передбачає зарплати. Для більшості сімей це просто нереалістично.

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

Підтримка під час втрати роботи: система з минулого століття

Головний інструмент підтримки при втраті роботи — страхування з безробіття, створене майже сто років тому для економіки, де люди десятиліттями працювали в одній галузі. Ця система:

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

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

Новий «суспільний договір»: як має виглядати план переходу до AI-економіки

Партнерство держави й бізнесу замість стіни між школою та роботою

Запропонована модель спирається на три опори:

1. Новий «великий компроміс» між урядом і бізнесом.
   Бізнес не просто користується AI для оптимізації витрат, а бере участь у плануванні переходу: формує запит на навички, інвестує в перепідготовку, бере участь у програмах redeployment (переведення працівників на нові ролі).

2. Ліквідація розриву між освітою та ринком праці.
   Освітні програми, коледжі, сертифікації та курси мають будуватися на основі даних від роботодавців: які компетенції потрібні зараз, які — через 3–5 років.

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

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

Зміна стимулів: інвестувати не тільки в машини, а й у людей

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

Пропонується розвернути систему стимулів:

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

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

Оновлення системи підтримки під час переходу

Окрім класичних виплат із безробіття, пропонується:

• тимчасова підтримка зарплати (wage insurance) для тих, хто переходить у нову сферу з нижчим стартовим доходом;
• програми підтримки самозайнятості для тих, хто запускає власний бізнес — особливо з огляду на те, що AI здатен суттєво знизити бар’єри входу в підприємництво.

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

Уроки з минулого: чому цього разу не можна повторити помилки деіндустріалізації

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

Особиста історія з закриттям заводу Bulova в 1980-х і втратою роботи 56-річним працівником із тридцятирічним стажем ілюструє, як виглядав цей «перехід без мосту». Люди розуміли економічну логіку аутсорсингу, але не отримали жодної реальної підтримки для нового старту.

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

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

AI як «столітня технологія» потребує столітньої відповіді

Штучний інтелект описується як «100-річна технологія» — інфраструктурний зсув, який визначатиме економіку й суспільство на покоління вперед. Відповідь на нього не може обмежуватися:

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

Натомість потрібна довгострокова стратегія, яка поєднує:

• інвестиції в інфраструктуру AI (чипи, дата-центри, моделі);
• реформу освіти й підготовки кадрів;
• оновлення системи соціальної підтримки;
• зміну ринкових стимулів для бізнесу.

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

Джерело

«A Plan to Stop AI from Automating Our Decline | Gina Raimondo | TED»

Anthropic знову змістила лінію фронту в гонці великих мовних моделей. Несподіваний реліз Claude Opus 4.7 відбувся вже після того, як команда подкасту Mixture of Experts від IBM Technology записала черговий випуск, тож для обговорення новинки довелося робити окремий «екстрений» сегмент. У ньому інженер IBM Кріс Хей ділиться першими враженнями від моделі, порівнює її з Opus 4.6 і попереднім Mythos Preview та уважно розбирає системну картку Anthropic.

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

Від 4.6 до 4.7: чому саме агентне кодування стало головною інтригою

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

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

За перші години роботи з Opus 4.7 у середовищі Claude Code Хей описує відчутний якісний зсув порівняно з 4.6. Модель, за його словами, краще виявляє проблеми, знаходить більше багів і загалом поводиться структурованіше в довгих сесіях. Це не просто суб’єктивне враження: стрибок підтверджують і формальні тести.

На бенчмарку SWE Bench Pro, який оцінює саме агентні можливості в розв’язанні реальних задач програмування, Opus 4.6 показував близько 53%. Opus 4.7 піднімається до приблизно 64%. Для світу LLM це не косметичне покращення, а серйозний крок уперед: мова йде про десятки відсотків додаткових задач, які модель може самостійно довести до робочого рішення.

Водночас цей результат не є піком для Anthropic. Попередня модель Mythos Preview, доступна лише обмеженому колу компаній, демонструє на тому ж SWE Bench Pro близько 77,8%. Саме це порівняння задає тон усій дискусії навколо Opus 4.7: Anthropic явно намагається перенести частину потужності Mythos у більш безпечний, масовий продукт – але не повністю.

Швидше й розумніше: як Opus 4.7 змінює відчуття від роботи з моделлю

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

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

Цікаво, що Anthropic у своїх матеріалах прямо підкреслює: Opus 4.7 має «суттєво кращі» візуальні можливості, ніж попередник. Модель «бачить» зображення у вищій роздільній здатності й краще працює з інструкціями, пов’язаними з картинками. Для інженера це важливий сигнал: такі покращення рідко досягаються простим донавчанням уже готової моделі. Частіше це ознака того, що під капотом – інша або оновлена базова архітектура.

У сукупності – стрибок у SWE Bench Pro, відчутне прискорення, краща візія, поліпшене слідування інструкціям і довгі задачі – усе це наштовхує на думку, що Opus 4.7 не є просто «ще одним патчем» до 4.6. Швидше, це окрема дистиляція більш потужної моделі.

Тінь Mythos: як Anthropic балансує між потужністю й безпекою

Ключ до розуміння Opus 4.7 – порівняння з Mythos Preview. Anthropic сама в публічних формулюваннях визнає: Opus 4.7 «загалом не настільки широко здатний», як Mythos, але водночас кращий у низці аспектів. Це обережне формулювання, яке залишає простір для інтерпретацій, але системна картка моделі дає більше підказок.

За спостереженнями Хея, системна картка Opus 4.7 «дуже схожа» на картку Mythos – настільки, що місцями виглядає як перероблена версія того ж документа. У прикладах джейлбрейків і порівнянь часто фігурують саме кейси Mythos, а не 4.7 чи 4.6. Це створює враження, що Anthropic мислить Opus 4.7 як похідну від Mythos, а не від попереднього Opus.

Ще одна деталь: у картці прямо зазначено, що частину зовнішнього тестування, яке проводилося для Mythos, для Opus 4.7 пропустили через брак часу. Це нетипова відвертість для системних карток і водночас непряме підтвердження гіпотези: якщо внутрішньо команда впевнена в базовій архітектурі (бо вона вже пройшла повний цикл перевірок як Mythos), то для дистильованої версії можна дозволити собі скорочену процедуру.

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

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

Кібербезпека як лінія розмежування: де Anthropic проводить червону риску

Найбільш виразно ця стратегія проявляється в розділі системної картки, присвяченому кібербезпеці. Саме тут Anthropic проводить чітку межу між Mythos і Opus 4.7.

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

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

Це важливий сигнал для ринку. Anthropic фактично розділяє свої моделі на дві лінійки: експериментальну, з максимальною потужністю (Mythos), і масову, з посиленими обмеженнями (Opus). Перша доступна лише обмеженому колу партнерів, друга – стає робочою конячкою для широкого кола клієнтів, але з чітко окресленими «червоними зонами».

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

У будь-якому разі, саме кібербезпека стає тією зоною, де Anthropic свідомо жертвує частиною можливостей заради репутації відповідального гравця. І Opus 4.7 – перший великий реліз, у якому ця стратегія проявляється настільки явно.

Місячний ритм гонки моделей: чому Opus 4.7 – не останній крок

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

У такій динаміці Opus 4.7 виглядає як проміжний, але важливий крок. З одного боку, він переносить у масовий продукт частину можливостей Mythos, насамперед в агентному кодуванні й роботі з візуальними даними. З іншого – залишає Anthropic простір для «великого пострілу» у вигляді повноцінного релізу Mythos або його наступника.

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

Opus 4.7 у цій грі – демонстрація того, що Anthropic не просто тримається в строю, а й намагається задати тон у ключових для розробників сценаріях. SWE Bench Pro із 64% проти 53% у 4.6 – це сигнал для ринку інструментів розробки: якщо ви будуєте IDE, агентів‑кодерів чи платформи автоматизації, новий Opus може стати помітним апгрейдом.

Водночас цифра 77,8% у Mythos Preview нагадує: у запасі в Anthropic є ще один, потужніший рівень можливостей, який поки що не виходить за межі обмеженого кола партнерів. І саме баланс між цими двома лінійками – масовою й експериментальною – визначатиме, як компанія виглядатиме в очах ринку в найближчі місяці.

Висновок: Opus 4.7 як тест на зрілість стратегії Anthropic

Claude Opus 4.7 – це не просто «версія плюс нуль одна» в лінійці Anthropic. Це концентрований приклад того, як сьогодні виглядає зріла стратегія на ринку LLM: агресивний ривок у практично важливих сценаріях (агентне кодування, довгі задачі, візія), поєднаний із помітним посиленням запобіжників у найризикованіших зонах, насамперед у кібербезпеці.

Бенчмарки на кшталт SWE Bench Pro показують, що це не косметичний апдейт: стрибок із 53% до близько 64% – це вже інший рівень корисності для команд розробки. Відчутне прискорення роботи моделі й краща структурованість відповідей роблять цей прогрес відчутним і в щоденній практиці.

Водночас тінь Mythos Preview з його 77,8% на тому ж тесті нагадує, що Anthropic свідомо не виводить на масовий ринок максимум того, на що здатна. Opus 4.7 виглядає як дистильована, обмежена й більш безпечна версія цієї потужності – компроміс між інновацією та відповідальністю.

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

Джерело

Mixture of Experts – Claude Opus 4.7, Apple’s AI glasses and Allbirds AI pivot

Команди даних часто починають із простих batch-процесів, а згодом змушені нашвидкуруч додавати стрімінг, коли бізнесу раптом потрібні «реальні» реальні часи. На каналі Confluent Developer пояснюють, як із цього еволюціонують три ключові архітектури — Lambda, Kappa та Data Streaming Platform — і чому варто прагнути до уніфікації, а не до нарощування латок.

Базова модель: «джерело → трансформація → сховище»

Щоб порівнювати архітектури, зручно звести будь-який пайплайн до простої схеми:

• Джерела (sources) — звідки надходять дані: бази даних, Kafka-топіки, логи, зовнішні системи.
• Трансформації (transform) — бізнес-логіка: фільтрація, агрегація, дедуплікація, збагачення тощо.
• Сховища (sinks) — куди потрапляють оброблені дані: data lake, аналітичні вітрини, дашборди, інші топіки для downstream-сервісів.

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

Lambda: коли до batch «прикручують» стрімінг

Типовий стартовий сценарій:

1. Batch-пайплайн
2. Джерела даних.
3. Трансформації у Spark, Snowflake чи іншому batch-рушії.
4. Один або кілька sinks (сховище, BI-дашборди).
5. Оркестратор (Airflow, Dagster, Argo Workflows), який вирішує, коли запускати які джоби.

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

1. Запит на real-time
   Коли з’являється вимога до дашбордів у реальному часі, повністю переробляти архітектуру зазвичай ніхто не готовий. Команди обирають «прагматичний» шлях — додати другий пайплайн:

2. Піднімається Kafka-топік.

3. Додаються стрімінгові джоби (Apache Flink, Spark Streaming, кастомні сервіси).
4. Дані безперервно течуть у real-time-сервіси та дашборди.
5. З’являється serving layer, який поєднує історичні batch-дані з «швидким» шаром.

Так народжується Lambda-архітектура:
– Batch-шар — довгострокова історія.
– Speed-шар — реальні часи та дельти.

Операційна ціна Lambda

Lambda працює й використовується великими компаніями, але має суттєвий мінус — подвоєння всього:

• Два пайплайни.
• Дві технологічні стеки (Spark/Snowflake vs Flink/кастомні стріми).
• Часто — дві команди (big data vs streaming).
• Бізнес-логіка дублюється: один раз у batch, другий — у стрімінгу.

Як наслідок, типова ситуація: показники в real-time-дашборді не збігаються з тижневим звітом. Щоб з’ясувати причину, доводиться:

• Перевіряти обидва пайплайни.
• Зважати на різні семантики виконання, помилки та edge cases у кожному рушії.
• Вручну «зводити» дані до консистентного стану.

Формула «eventual consistency» у Lambda на практиці часто означає «неконсистентно, доки хтось не виправить руками».

Kappa: «batch — це просто обмежений стрім»

Альтернатива Lambda спирається на просту ідею: batch — це окремий випадок стрімінгу.

• Необмежений стрім (unbounded): є початок, немає кінця — класичний потік подій.
• Обмежений стрім (bounded): є початок і кінець — по суті, batch.

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

Як виглядає Kappa-архітектура

У Kappa все розглядається як стрім:

• Бази даних підключаються через CDC-конектори (наприклад, Debezium).
• Логи збираються агентами.
• Зовнішні системи — через власні конектори.
• Усе це потрапляє в єдиний стрім у брокері на кшталт Apache Kafka.

Далі:

• Один стрімінговий рушій (наприклад, Flink) виконує всі трансформації.
• Результати відправляються:
• у downstream-сервіси та інші стрімінгові клієнти;
• у lakehouse у вигляді таблиць у відкритих форматах (Iceberg, Delta Lake тощо).

Ключові наслідки:

• Один кодовий базис.
• Один технологічний стек і, відповідно, одна команда компетенцій.
• Уся бізнес-логіка в одному місці — єдине джерело правди для правил обробки.

Це різко зменшує як архітектурну, так і операційну складність.

Типові заперечення проти Kappa — і як їх знімають

1. «Не можемо тримати терабайти в брокері»
   Раніше це було серйозним обмеженням: дані зберігалися на локальних дисках брокерів.
   З появою tiered storage (наприклад, у Kafka через KIP-405, реалізований у 2023 році) довгострокове зберігання можна винести в дешеве object storage, а брокер тримає лише «гарячі» дані.

2. «Як аналітикам запитувати дані в стрімі?»
   Сучасні рушії (Flink SQL, Spark Structured Streaming) дозволяють писати SQL-запити безпосередньо до стрімів, у тому числі з ноутбуків. Аналітикам не обов’язково писати код — вони працюють із потоками як із таблицями.

3. «Ми хочемо використовувати Snowflake/Trino/улюблений BI-інструмент»
   Багато аналітичних систем не вміють нативно читати Kafka. Повний реплей стріму для отримання потрібного зрізу може бути повільним.
   Це підводить до наступного кроку еволюції — Data Streaming Platform, яка поєднує стрімінг і табличне подання даних.

Data Streaming Platform: уніфікований стрім плюс таблиці

Практична реалізація Kappa-ідей у вигляді платформи спирається на дві концепції: shift left та матеріалізація стріму в таблиці.

Shift left: якість, схеми й контракти — якнайближче до джерела

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

• Кожен сервіс окремо видаляє дублікати.
• Обчислювальні витрати дублюються.
• Логіка розмазана по багатьох місцях.

Підхід shift left пропонує:

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

Це стосується не лише обчислень:

• Керування схемами.
• Data governance.
• Data contracts між продюсерами та консюмерами.

Усе це зсувається «вліво», у стрім. У результаті:

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

Стрім як таблиця: Apache Iceberg, Delta Lake, TableFlow

Другий крок — зробити стрім доступним як таблицю:

• Потік синкується в відкритий табличний формат (Apache Iceberg, Delta Lake).
• Інструменти на кшталт TableFlow автоматизують цей процес: стрім «матеріалізується» у вигляді таблиці в object storage.

У підсумку:

• Той самий набір даних:
• доступний як реальний стрім для Flink та мікросервісів;
• одночасно доступний як високопродуктивна таблиця для Snowflake, Spark, Trino та інших SQL-рушіїв.

Що дає Data Streaming Platform

Поєднання shift left і табличної матеріалізації формує Data Streaming Platform:

• Один стрім даних живить:
• real-time застосунки;
• аналітичні системи та BI.
• Немає потреби будувати окремі пайплайни під кожен інструмент чи команду.
• Команди можуть:
• обирати будь-яке object storage;
• використовувати улюблений query engine;
• працювати з одними й тими самими, узгодженими даними.

Це фактично дає переваги Lambda (і batch, і streaming, і гнучкі аналітичні інструменти) без її операційної складності, завдяки уніфікованому стрімінговому ядру.

Як обирати архітектуру

Зіставлення трьох підходів виглядає так:

• Lambda
• Природний результат, коли до існуючого batch додають стрімінг.

• Працює, але створює подвійну інфраструктуру й складні розслідування інцидентів.

• Kappa

• Уніфікує обробку в одному стрімінговому рушії.

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

• Data Streaming Platform

• Розвиває Kappa, додаючи:
  • shift left для якості та governance;
  • матеріалізацію стрімів у відкриті табличні формати.
• Дає єдине джерело даних для real-time і аналітики, зберігаючи гнучкість вибору інструментів.

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

Джерело

Lambda vs Kappa vs Data Streaming Platform — Which One Wins? | Modern Data Engineering Pipelines

У новому випуску подкасту The Pragmatic Engineer творець Ruby on Rails Девід Хайнемайєр Ханссон (DHH) ділиться доволі провокаційною тезою: індустрія вже пройшла «пік програмістів». Та замість апокаліптичних прогнозів про кінець професії він описує більш тонку трансформацію — зміну попиту на навички та ролі в розробці.

Менше «класичних» програмістів, але не менше роботи

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

Йдеться не про те, що програмісти більше не потрібні, а про те, що:

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

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

Коли розробка — витрата, а не інвестиція

Особливо відчутними зміни будуть у компаніях, де розробка — це cost center, тобто витратний підрозділ. За оцінкою Ханссона, саме так працює, ймовірно, більшість розробки у світі: програмісти потрібні для підтримки бізнес-процесів, а не для створення нового продукту як основи бізнесу.

У таких організаціях:

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

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

Новий дефіцит: не код, а рішення «що і як будувати»

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

Ханссон описує це як зміну «вузького місця» в розробці:

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

Ключові питання, які виходять на перший план:

• Що ми маємо будувати?
• Як це має бути побудовано?
• З якими клієнтами варто говорити?
• На яких проблемах фокусуватися?

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

Що це означає для кар’єри розробників

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

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

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

Джерело

The Pragmatic Engineer Podcast — DHH: “We’ve seen peak programmer”

Економія токенів у середовищах на кшталт Claude Code напряму впливає на вартість роботи з ШІ‑інструментами. Чим менше токенів витрачається на запити, тим дешевше обходяться експерименти, розробка й тестування. Канал KODARIK пропонує один із найпростіших, але недооцінених способів оптимізації — змінити мову, якою ви пишете промпти.

Чому мова промпту впливає на кількість токенів

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

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

Скільки можна зекономити

Практичний ефект від переходу на англійські промпти може бути відчутним:

• економія становить орієнтовно 10–30% токенів;
• це зменшує витрати на довгі сесії роботи з кодом;
• дає змогу частіше запускати складні запити в межах тих самих лімітів.

Для користувачів, які активно працюють із Claude Code (наприклад, при розробці, рефакторингу або генерації великих фрагментів коду), така різниця в токенах може накопичуватися в суттєву економію.

Чому варто підтягнути англійську

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

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

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

Джерело

Як економити в Claude Code – Метод 1 — KODARIK

У світі, де великі мовні моделі вже здатні виконувати повний цикл роботи програміста, головним викликом стає не написання коду, а організація середовища, в якому цей код створюють агенти. Про це говорить Райан Лопополо, Member of Technical Staff в OpenAI, який останні дев’ять місяців будує софт виключно через агентів і навіть заборонив своїй команді безпосередньо торкатися редакторів коду. Його досвід — це не футуристичний експеримент, а практичний посібник: як змінити кодову базу, документацію та процеси так, щоб агенти стабільно видавали якісний результат.

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

Коли код безкоштовний: внутрішні агенти, локалізація і «розкіш» найкращих практик

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

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

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

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

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

Документація як промпт: як навчити агентів «розуміти», що таке хороша робота

Якщо код пише модель, то головним артефактом стає не сам код, а все, що формує поведінку агента: промпти, обмеження, приклади, історія рішень. Лопополо підкреслює, що документація, ADR (Architecture Decision Records), описи персон, тікети та код-рев’ю — це не просто супровідні матеріали, а фактично навчальні дані, які визначають, як агент розуміє «якісну роботу».

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

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

Особливу роль відіграє документація, орієнтована на персони. У команді Лопополо працюють фахівці з фронтенд-архітектури, бекенд-скейлінгу, продакт-орієнтованого дизайну. Кожен приносить власне бачення нефункціональних вимог: як виглядає «добре спроєктований API», «якісний QA-план», «стабільна система під навантаженням». Коли ці знання фіксуються в документах, кожен інженер, який керує агентами, отримує доступ до найкращих практик усієї команди, а не лише до власного досвіду.

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

Одноманітність як стратегія: чому варто зробити кодову базу передбачуваною для моделей

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

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

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

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

Результат — кодова база, в якій:

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

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

Нефункціональні вимоги: 500 дрібних рішень, які потрібно зробити явними

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

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

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

Лопополо пропонує підходити до цього системно. Якщо агенти (або люди) регулярно припускаються однакових помилок, варто:

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

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

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

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

Коли агенти помиляються: чому варто свідомо гальмуватися заради кращих гардрейлів

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

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

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

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

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

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

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

Висновок: код як витратний матеріал, стандарти як капітал

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

Якщо код дійсно стає «безкоштовним» у створенні й зміні, то справжнім капіталом стають:

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

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

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

Джерело

Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI

Anthropic оновила десктопний додаток Claude Code, зробивши помітний крок від «термінального помічника» до інструмента, який за відчуттями наближається до IDE: з мультисесіями, вбудованим прев’ю, логами, панеллю задач і глибокою інтеграцією з терміналом. Огляд функцій і змін зібрано на основі відео від каналу KODARIK.

Новий інтерфейс і статистика використання

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

На стартовому екрані тепер відображається детальна статистика використання Claude Code:

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

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

Сайдбар дозволяє:

• переглядати поточні та минулі сесії;
• перейменовувати, пінувати, шарити, архівувати й видаляти їх;
• створювати нові сесії;
• налаштовувати «рутини» (новий тип сценаріїв роботи);
• підключати плагіни, скіли та MCP-сервери через розділ кастомізації;
• приховувати зайві елементи меню через прості чекбокси.

Також доступне перемикання теми (темна/світла) та шрифту.

Режими доступу, моделі та контекст

Claude Code 2.0 дає змогу працювати з:

• локальним проєктом;
• хмарним середовищем;
• віддаленим сервером через SSH.

Окремо налаштовуються режими дозволів. Їх три основних плюс додатковий режим Bypass Permission, який відкриває повний доступ до файлів на комп’ютері. Увімкнути його можна лише в налаштуваннях, після чого додаток отримує змогу:

• змінювати й видаляти файли;
• працювати з базами даних без додаткових підтверджень.

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

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

Праворуч від чату розташований вибір моделі та «рівня зусиль» — наскільки інтенсивно модель працюватиме над завданням. Є гаряча клавіша Shift + Command + I, яка відкриває вікно вибору моделі, але не перемикає її одразу.

Контекст сесії відображається у вигляді індикатора-заповненого кола. Детальніше можна подивитися через окрему кнопку:

• загальний відсоток заповнення контекстного вікна;
• розподіл за типами: повідомлення, системні промпти, інструменти, MCP-інструменти, скіли;
• деталізація по кожному MCP-інструменту.

Ліміти використання (обмеження на контекст) видно лише після натискання на кнопку — на відміну від індикатора контексту, вони не відображаються постійно.

Синхронізація з терміналом і мультисесії

Одна з ключових змін — глибока інтеграція десктопного додатка з термінальною версією Claude Code.

Як це працює:

1. У терміналі користувач переходить у папку проєкту й запускає Claude Code.
2. Створюється сесія, у якій можна спілкуватися з агентом.
3. У десктопному додатку ця сесія автоматично з’являється в списку.
4. Продовження діалогу в GUI миттєво відображається в терміналі, і навпаки.

Для цього має бути активований remote control. При старті сесії в терміналі з’являється повідомлення remote control is active — за замовчуванням він увімкнений. Перевірити налаштування можна командою config, де внизу є пункт enable remote control for all session.

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

• паралельна робота над фронтендом і бекендом;
• одночасне ведення робочого й тестового середовищ;
• порівняння двох підходів до реалізації задачі.

Вбудоване прев’ю, логи, задачі та плани

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

Ключові можливості:

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

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

• Список активних серверів
  Наприклад, можна побачити запущений Next.js-сервер, додатково стартувати Drizzle Studio тощо.

• Інтерактивний курсор для вибору елементів інтерфейсу
  Окрема кнопка-курсор дозволяє клікнути по будь-якому елементу на сторінці в прев’ю (наприклад, кнопці в навігації). Обраний елемент автоматично додається в контекст чату. Це знімає потребу описувати словами «ось та кнопка зверху в навігації» — достатньо виділити її курсором і сформулювати завдання.

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

• Diff-зміни в проєкті
  У верхньому меню є розділ diff, де можна переглядати всі зміни в коді.

• Вбудований термінал
  Доступний окремим пунктом меню — класичний інструмент для тих, хто не хоче постійно перемикатися між вікнами.

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

• Плани (режим планування)
  Якщо перевести Claude Code в режим планування й попросити створити план (наприклад, для реалізації авторизації), цей план зберігається в окремій панелі праворуч. Там можна переглянути структуру запропонованих кроків і повертатися до неї в процесі роботи.

Для кого це може бути корисно

Claude Code 2.0 помітно зміщує акцент у бік розробників, які:

• хочуть працювати з AI-агентом не лише через термінал;
• цінують можливість бачити прев’ю, логи, diff і задачі в одному вікні;
• будують робочий процес навколо «агентів», які пишуть і змінюють код за них.

Для тих, хто звик до чистого терміналу, новий десктопний додаток може залишитися другорядним інструментом. Але для «no-look» розробки, коли значна частина роботи делегується моделі, оновлення виглядає як крок до повноцінної AI-орієнтованої IDE.

Джерело

Claude Code 2.0 — це вже IDE? Новий десктоп додаток з агентами та терміналом

Ефективна робота з AI‑інструментами напряму впливає на витрати — як часу, так і грошей. Один із ключових способів оптимізувати використання Claude Code, на який звертає увагу канал KODARIK, — це правильне формулювання промптів.

Чому промпт — це вже половина результату

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

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

Основний принцип, який варто взяти за правило: чим конкретніше, тим краще.

Не розмовляти, а ставити завдання

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

Показовий контраст двох підходів:

• «Давай на цей раз зробимо ось так. Я думаю, що краще буде…» + далі завдання.
• «Зроби ось так: …» + чітко сформульоване завдання.

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

Коротко, чітко, але детально

Економія в Claude Code не означає писати одне речення й чекати ідеальної відповіді. Важливо поєднати дві вимоги:

• Коротко й чітко — без зайвих фраз, емоційних вставок і «розмовних» конструкцій.
• Детально за змістом — із повним описом задачі, контексту, обмежень і бажаного формату результату.

Тобто промпт має бути лаконічним за формою, але інформативним за суттю. Такий підхід:

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

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

Джерело

https://www.youtube.com/watch?v=PBTHgpk9opg

У квітні 2026 року на сцені конференції AI Engineer в Лондоні член технічного штату OpenAI Райан Лопополо розповів про те, як виглядає розробка, коли люди лише керують, а агенти виконують. Протягом дев’яти місяців він будує софт виключно через агентів, заборонивши своїй команді безпосередньо торкатися редакторів коду. Лопополо описує себе як «токенного мільярдера», який щодня витрачає понад тисячу доларів на вихідні токени, і стверджує: реалізація більше не є дефіцитним ресурсом.

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

GPT‑5.2 як точка зламу: коли модель вперше «тягне» повний стек інженера

Лопополо називає GPT‑5.2 «магічним моментом» — першою моделлю, яку він побачив здатною виконувати повну роботу інженера‑програміста від початку до кінця. Йдеться не про автодоповнення чи написання окремих функцій, а про ізоморфність до людини‑інженера в реальних кодових базах.

За його описом, GPT‑5.2 досягла рівня, коли модель може:

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

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

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

• час людини;
• увага людини й моделі;
• вікно контексту моделі.

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

GPT‑5.4, CEX і кінець «/new»: як автокомпресія контексту розв’язує руки агентам

Якщо GPT‑5.2 зробила можливим повноцінне «інженерство в моделі», то GPT‑5.4 з CEX (Context Expansion / Compaction) зробила це масштабованим у часі. Лопополо підкреслює: GPT‑5.4 з CEX «фантастично» працює з автоматичною компресією контексту для довготривалих агентних задач.

У практичному вимірі це означає, що:

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

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

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

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

Коли рефакторинг безкоштовний: міграції, що більше не зависають на півроку

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

У традиційній розробці великі міграції часто «висять» місяцями: команда робить 80–90% роботи, але останні 10–20% коду залишаються недоторканими через брак часу, контексту або просто втоми. Лопополо описує знайому картину: «ніколи не можемо дотиснути останні шматки кодової бази».

У світі, де код безкоштовний, він пропонує іншу стратегію:

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

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

Це не означає, що великі зміни стали тривіальними. Потрібно:

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

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

Агенти як безкінечно терплячі утримувачі коду: підтримка, рефакторинг і видалення

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

На його думку, моделі:

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

Звідси висновок: підтримку, рефакторинг і навіть видалення коду можна делегувати агентам, які працюють у фоновому режимі, довго й методично.

Лопополо описує підхід, у якому:

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

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

Натомість він пропонує:

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

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

Світ, де всі P3 запускаються одразу: паралельні траєкторії замість вічного беклогу

Ще один наслідок «безкоштовного коду» — зміна ставлення до пріоритизації. У класичній моделі, де кожен рядок коду коштує людського часу, задачі діляться на P0, P1, P2 і P3, але реальність така, що P3 майже ніколи не доходять до виконання.

Лопополо описує це просто: коли людський час потрібен для написання коду, P3 «ніколи не будуть зроблені».

У світі, де код генерують агенти, картина інша:

• всі P3‑задачі можна запустити одразу, не чекаючи «вікна» в розкладі інженера;
• одну й ту саму задачу можна спробувати розв’язати кількома паралельними траєкторіями — наприклад, чотирма різними агентами з різними стратегіями;
• потім команда просто обирає найкраще рішення й інтегрує його.

Лопополо прямо говорить: у світі, де код безкоштовний, усі P3 запускаються негайно, часто «4× у паралель». Це не означає, що пріоритизація зникає як така — людський час усе ще обмежений, і хтось має визначати, які задачі взагалі варто формулювати й запускати. Але сам факт запуску більше не прив’язаний до того, чи знайдеться інженер, готовий витратити на це день або тиждень.

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

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

Коли найкращі практики стають «дефолтом» кожного продукту

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

Йдеться не про те, щоб кожен інженер щоразу згадував усі вимоги до безпеки, надійності, тестування чи UX. Натомість:

• експерти в команді формалізують свої знання у вигляді документації, ADR, «персональних» гайдів;
• ці артефакти стають частиною «харнесу» — системи промптів, інструкцій і перевірок, у якій живуть агенти;
• кожен інженер, який керує агентами, автоматично отримує «краще від усіх» — не через код‑рев’ю з низьким сигналом, а через системні інструкції, які агенти враховують на кожному кроці.

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

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

Висновок: масштабування інженерії через контекст, а не через людей

Модель світу, яку описує Райан Лопополо, радикально відрізняється від класичної картини розробки. Тут:

• GPT‑5.2 вперше робить реальним повний цикл роботи інженера в моделі;
• GPT‑5.4 з CEX дозволяє агентам працювати довго, не втрачаючи важливий контекст;
• великі рефакторинги й міграції стають фактично безкоштовними завдяки масово паралельним агентам;
• підтримка, рефакторинг і видалення коду делегуються терплячим, паралельним агентам, які не втомлюються;
• усі P3‑задачі можуть стартувати одразу, часто з кількома паралельними спробами.

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

Джерело

Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI

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

У розмові на подкасті OpenAI дослідниця Джой Цзяо (Joy Jiao) та продакт-лідерка Юнюнь Ван (Yunyun Wang) пояснюють, як компанія одночасно будує потужні інструменти для life sciences і вибудовує навколо них багаторівневу систему безпеки, доступу та контролю. Паралельно команда робить ставку на масштабування обчислень у момент використання моделі (test‑time compute), щоб у перспективі змістити головне вузьке місце науки з людського часу на обмеження обчислювальних ресурсів.

Біобезпека як проблема «подвійного призначення», що росте разом із моделями

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

OpenAI формалізує це як проблему dual‑use: ризик біологічного зловживання розглядається не як окремий сценарій, а як властивість самих можливостей моделі, що зростає разом із її загальною потужністю. Чим краще система розуміє механізми клітин, геноміку, білки, експериментальний дизайн і причинно-наслідкові зв’язки в біології, тим більше вона здатна як допомагати, так і нашкодити.

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

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

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

Від «усім однаково» до диференційованого доступу: хто отримає найпотужніші біомоделі

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

Компанія переходить до моделі, в якій найпотужніші life sciences‑можливості будуть доступні лише певним категоріям користувачів, ідентичність та контекст роботи яких можна перевірити й контролювати.

Йдеться про:

• професіоналів у галузі біології та медицини;
• дослідників у регульованих наукових установах;
• команди у фармацевтичних компаніях та інших організаціях із чіткими процедурами комплаєнсу та безпеки.

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

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

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

Багаторівневі запобіжники: від самовідмов моделі до корпоративної безпеки

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

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

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

Третій рівень — інфраструктурні й організаційні заходи, особливо для високоризикових можливостей. У корпоративних сценаріях OpenAI застосовує enterprise‑grade контролі безпеки: керування доступом, сегментацію середовищ, моніторинг активності, інтеграцію з системами безпеки клієнтів.

Усе це особливо важливо в контексті life sciences, де моделі можуть працювати з реальними експериментальними даними, лабораторними протоколами та результатами високопродуктивних скринінгів. Тут помилка в дизайні системи безпеки може мати наслідки далеко за межами цифрового світу.

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

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

Два роки експериментів: як OpenAI тестує біоможливості моделей на реальних даних

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

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

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

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

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

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

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

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

«Scale test‑time compute to cure all disease»: чому майбутнє науки впирається в обчислення

Внутрішній девіз life sciences‑команди OpenAI звучить майже провокаційно: «scale test‑time compute to cure all disease» — масштабувати обчислення в момент використання моделі, щоб вилікувати всі хвороби.

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

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

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

Це пов’язано з розвитком reasoning‑моделей — систем, здатних не просто видавати швидку відповідь, а будувати довгі ланцюжки міркувань, розбивати складні завдання на підзадачі, перевіряти власні гіпотези й коригувати їх. У контексті life sciences це означає можливість:

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

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

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

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

Від інструментів до експертів: чому моделі мають «думати як біохіміки»

Сьогодні моделі OpenAI вже можуть працювати як «комп’ютерні біологи», використовуючи зовнішні інструменти. Вони здатні викликати open‑source алгоритми прогнозування структури білків, запускати їх на даних, аналізувати результати, змінювати вхідні параметри й повторювати цикл.

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

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

Така експертність дозволяє:

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

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

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

Висновок: баланс між прискоренням науки і стримуванням ризиків

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

З одного боку, компанія інвестує в reasoning‑моделі, масштабування test‑time compute, автономні лабораторії та глибокі оцінки можливостей на реальних даних. Внутрішній девіз про «масштабування обчислень, щоб вилікувати всі хвороби» відображає амбіцію перетворити AI на центральний інструмент сучасної біології.

З іншого боку, OpenAI будує складну систему доступу й безпеки: від початкового гіперобережного розгортання до диференційованого доступу для перевірених професіоналів, від самовідмов моделей до enterprise‑рівня контролю в інфраструктурі.

У цьому підході немає простих рішень. Кожне збільшення можливостей моделі вимагає нового витка роботи над біобезпекою, а кожне посилення обмежень — ризикує загальмувати корисні застосування. Але саме така напруга, схоже, і визначатиме розвиток AI у life sciences в найближчі роки: між бажанням зробити науку швидшою й обов’язком зробити її безпечнішою.

Джерело

https://www.youtube.com/watch?v=UZyH0nx5zgI