США можуть виграти технологічну гонку в галузі штучного інтелекту — і водночас програти власному суспільству. На це попереджає виступ на каналі 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

OpenAI представила GPT-5.4-Cyber — спеціальний варіант своєї LLM, орієнтований на кібербезпеку та «кібердозволеність». У бонусному епізоді подкасту Security Intelligence від IBM Technology експерти обговорюють, що означає поява такої моделі для індустрії безпеки та як змінюється підхід до доступу до найпотужніших ШІ-систем.

Що таке «кібердозволена» модель і чим вона відрізняється

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

• аналіз потенційного шкідливого ПЗ;
• пошук вразливостей;
• моделювання атак для тестування захисту.

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

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

Доступ до потужних LLM: від «для всіх» до «для обраних»

Поява GPT‑5.4‑Cyber вписується в ширший зсув: доступ до найпередовіших моделей стає дедалі більш контрольованим.

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

Сьогодні вимальовуються дві стратегії доступу:

• Консорціумний підхід
  Наприклад, у випадку з Project Glasswing та Claude Mythos доступ обмежують вузьким колом компаній. Це максимально закритий сценарій: лише перевірені організації, жорсткий контроль, фактично «клуб за запрошеннями».

• Автоматизований «довірений» доступ
  OpenAI використовує механізм Trusted Access for Cyber (TAC). Це автоматизований процес, через який можуть подати заявку як компанії, так і окремі спеціалісти. Критерій — доведена кваліфікація в кібербезпеці та «благі наміри».

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

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

Дискусія навколо GPT‑5.4‑Cyber повторює суперечки, які кіберспільнота веде десятиліттями. Ще в 1995 році з’явився інструмент SATAN (System Administrators Tool for Analyzing Networks) — один із перших відкритих сканерів вразливостей. Він був створений «для хороших хлопців», але швидко стало очевидно: інструмент не обирає сторону.

Ті самі аргументи звучать і сьогодні:

• У руках захисників потужна модель:
• прискорює пошук вразливостей;
• допомагає швидше латати діри;

• підвищує загальний рівень захищеності систем.

• У руках зловмисників:

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

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

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

Пошук балансу: між «секретним клубом» і повною відкритістю

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

Схожий баланс шукають і зараз щодо доступу до LLM:

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

• не заважає зловмисникам розробляти власні інструменти.

• Повна відкритість дає всім однакові можливості, але:

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

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

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

Джерело

Подкаст Security Intelligence, епізод «GPT-5.4-Cyber: What you need to know»
YouTube: https://www.youtube.com/watch?v=xbvI5G-8q4o

У Лондоні на сцену виходить Райан Лопополо — member of technical staff в OpenAI. Уже дев’ять місяців він будує продакшн‑софткер виключно через агентів, фактично заборонивши своїй команді торкатися редакторів коду. У цьому підході, який він називає «harness engineering», людина керує, а агенти виконують. Із цієї радикальної практики виростає теза, яка звучить майже єретично для індустрії: реалізація більше не є дефіцитним ресурсом, бо код став фактично безкоштовним.

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

Коли код стає безкоштовним: що насправді стало дефіцитним

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

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

У такій парадигмі змінюється сама економіка інженерії. Найдорожчим стає не код, а три інші ресурси:

1. Людський час.
2. Увага — як людська, так і модельна.
3. Контекстне вікно моделі.

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

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

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

Від індивідуального виконавця до «staff engineer» з армією агентів

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

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

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

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

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

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

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

Людина як дизайнер промптів, гардрейлів і систем

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

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

У цій логіці ключовими артефактами стають:

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

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

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

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

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

Внутрішні інструменти, локалізація й «безкоштовні» найкращі практики

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

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

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

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

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

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

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

Масштабування експертизи: як один інженер підсилює всіх агентів

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

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

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

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

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

Новий базовий рівень: кожен інженер як керівник «нескінченної» команди

У підсумку з підходу Лопополо вимальовується новий базовий рівень для професії розробника. Якщо раніше кар’єрний шлях часто виглядав як рух від індивідуального контриб’ютора до техліда й далі до staff/ principal‑рівня, то в світі harness engineering кожен інженер стартує з позиції, близької до staff‑мислення.

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

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

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

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

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

Джерело

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