Економія токенів у середовищах на кшталт 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

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

Коли більше людей не означає більше результату

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

• компанія залучає інвестиції
• різко збільшує кількість співробітників
• зростає burn rate — щомісячні витрати
• CEO розчарований: часу й грошей витрачається більше, а відчутного приросту результатів немає

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

Якщо збільшувати штат, не збільшуючи кількість таких «бочок», компанія фактично:

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

У результаті зростає складність, а не продуктивність.

Хто такі «бочки» і чому вони критичні

«Бочка» — це людина, яка:

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

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

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

Усе, що «менше за це», не є «бочкою» в запропонованому розумінні.

Чому просто додавати людей — хибна стратегія

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

Але без збільшення кількості людей, які можуть незалежно вести ініціативи, відбувається таке:

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

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

Як зрозуміти, що компанії потрібні саме «бочки»

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

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

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

Джерело

Hire barrels, not ammunition — Lenny’s Podcast

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

Коли швидкість шкодить розумінню

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

Замість того щоб:

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

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

Втрата інтуїції та доменної експертизи

Довгострокова робота з кодовою базою формує те, що можна назвати «інженерною інтуїцією»:

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

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

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

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

Знецінення процесу та відповідальності

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

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

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

Як використовувати AI і не деградувати як розробник

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

Щоб цього уникнути, важливо:

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

Інакше швидкість, яку дає AI, обернеться тим, що розробник втратить головне — глибоке розуміння власного коду.

Джерело

You NEED to stop using AI — Tech With Tim

OpenAI поступово виходить за межі тексту, коду й зображень, заходячи в одну з найскладніших і найрегульованіших сфер — біологію та медицину. У новому епізоді подкасту OpenAI дослідниця Джой Цзяо (Joy Jiao) та продакт-лідерка Юн’юн Ван (Yunyun Wang) розповідають, як компанія будує спеціалізовану лінійку моделей для life sciences, навіщо цим моделям «інтуїція» біохіміка і чому ціль — не просто викликати інструменти, а створити справжніх цифрових експертів, здатних працювати вздовж усього біомедичного конвеєра — від клітинних шляхів до етапів, пов’язаних із FDA.

Новий клас моделей: ШІ, який «мислить» біохімією

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

Фокус першої хвилі цих моделей — раннє відкриття (early discovery). Саме тут, на стику геноміки та розуміння білків, сьогодні виникають найбільші інтелектуальні та обчислювальні вузькі місця. Аналіз варіантів у геномі, інтерпретація їхнього впливу на білкові структури, зв’язок із клітинними шляхами та хворобами — усе це потребує величезних обсягів знань і часу. Команда OpenAI вважає, що «більше мислення» за рахунок масштабування тестового часу обчислень (test-time compute) і спеціалізованих моделей може відчутно зняти ці бар’єри.

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

Від геноміки до FDA: амбіція охопити весь біомедичний ланцюжок

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

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

Далі — прискорення відкриття ліків. Тут постає кілька ключових запитань, на які ШІ має допомагати відповідати:

• Чи може модель допомогти виявити механізм захворювання, зв’язавши розрізнені дані — від оміксових профілів до клінічних спостережень?
• Чи здатна вона, отримавши ціль (наприклад, конкретний білок або шлях), запропонувати молекули чи біологічні агенти, які можуть на неї впливати?
• Чи можна використати ШІ, щоб оптимізувати дизайн кандидатів, зменшуючи кількість ітерацій між in silico й wet lab?

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

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

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

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

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

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

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

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

Моделі як професії: спеціалізовані «персони» для різних наукових workflow

Один із найцікавіших концептів, який проглядається в підході OpenAI, — це ідея моделей як професій. Замість одного універсального ШІ, що вміє «трохи всього», компанія рухається до спеціалізованих персон, налаштованих під конкретні наукові ролі та workflow.

У life sciences це особливо помітно. Уже зараз OpenAI розгортає life sciences research plugins, орієнтовані на конкретних користувачів у трансляційній біології та корпоративних сценаріях. Ці плагіни — не просто набір API-викликів, а структуровані «навички», які відображають реальні професійні задачі.

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

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

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

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

Від лабораторної лави до автономних експериментів: як моделі входять у wet lab

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

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

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

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

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

Масштабування мислення: від людських до обчислювальних вузьких місць

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

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

У цьому контексті слоган команди — «scale test-time compute to cure all disease» — звучить не як гучний маркетинговий лозунг, а як формула підходу: збільшити обсяг «мислення», який модель може виконати над конкретною науковою задачею, і таким чином розширити простір досліджуваних гіпотез і сценаріїв.

Висновок: цифрові біохіміки як новий шар наукової інфраструктури

Life Sciences model series OpenAI — це спроба створити новий шар наукової інфраструктури, де спеціалізовані моделі виступають не просто як універсальні помічники, а як цифрові професіонали. Вони мають розуміти геноми й білки, міркувати про клітинні шляхи, допомагати в дизайні ліків і підтримувати етапи, пов’язані з регуляторними процесами.

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

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

Джерело

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

MiroFish — експериментальний open source‑проєкт, який за лічені тижні перетворився на один із найгучніших феноменів GitHub. Автор Tech With Tim у своєму відео розбирає, як ця система «цифрового світу» з тисячами агентів будує знання та робить прогнози, а головне — як її реально запустити без власного дата‑центру.

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

Вибухова популярність MiroFish: 10 днів розробки, мільйони фінансування і топ GitHub

MiroFish з’явився на GitHub буквально «з нізвідки» і дуже швидко став вірусним. На момент запису відео репозиторій мав близько 51 000 зірок і приблизно 7 600 форків. Проєкт був номером один серед глобально трендових репозиторіїв GitHub, що для інструмента з настільки специфічною функцією — симуляцією майбутнього — виглядає нетипово навіть на фоні хайпу навколо AI.

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

Популярність MiroFish підживлюється не лише ідеєю «передбачення майбутнього», а й тим, що це не закритий SaaS‑продукт, а open source‑система, яку можна клонувати, змінювати й запускати на власних ресурсах. Однак за цією свободою стоїть доволі складний стек, кілька зовнішніх сервісів і реальні витрати на API‑запити до LLM.

Усередині MiroFish: Oasis, Zep Cloud, FastAPI, Vue.js і будь‑який LLM зі стилем OpenAI

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

Серцем симуляції є Oasis — рушій, який відповідає за побудову та виконання самої моделі світу. Саме Oasis керує тим, як агенти взаємодіють, як формується граф знань і як відпрацьовуються сценарії в умовному «аналогові Twitter і Reddit». Це не просто бібліотека для виклику LLM, а повноцінний simulation engine, який задає правила гри для всієї системи.

Другий критичний елемент — Zep Cloud. Він використовується як пам’ять для агентів: зберігає контекст, історію взаємодій, знання, які накопичуються протягом симуляцій. На відміну від інших частин стека, Zep Cloud не є open source і працює як зовнішній сервіс. У типовій конфігурації MiroFish саме Zep відповідає за те, щоб агенти не були «амнезійними» й могли послідовно розвивати свої думки та стратегії.

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

Фронтенд реалізовано на Vue.js. Через нього користувач бачить граф знань, може досліджувати агентів, читати згенеровані звіти та взаємодіяти з симульованим середовищем. Це важлива частина досвіду роботи з MiroFish: система не просто повертає текстовий прогноз, а дає змогу «зазирнути» в логіку агентів.

Нарешті, мовна «начинка» — будь‑яка LLM, сумісна з OpenAI‑SDK. MiroFish не прив’язаний жорстко до одного провайдера: він очікує API у стилі OpenAI, а конкретну модель і базовий URL можна задати в налаштуваннях. Це відкриває шлях до використання різних постачальників — від OpenAI до Anthropic чи Minimax — без переписування коду.

У підсумку стек виглядає так: Oasis як симуляційний рушій, Zep Cloud як пам’ять, FastAPI як бекенд, Vue.js як інтерфейс і будь‑який OpenAI‑сумісний LLM як мовний мозок. Усе, окрім Zep Cloud, — open source і може бути розгорнуто локально.

Вибір мовної моделі: OpenAI, Claude, Minimax і чому не варто брати «ультра‑преміум»

Один із ключових практичних моментів для тих, хто хоче запустити MiroFish, — це вибір LLM. Система розрахована на використання моделей, які підтримують OpenAI‑style API. Це означає, що вона очікує знайомий формат запитів і відповідей, а також стандартні параметри на кшталт model, messages тощо.

У налаштуваннях MiroFish можна вказати:

• базовий URL API,
• назву моделі,
• API‑ключ.

Якщо використовується OpenAI, усе виглядає стандартно: ключ створюється на платформі OpenAI, модель обирається зі списку доступних (у прикладі Тіма — GPT‑4.0). Якщо ж користувач хоче перейти на інший провайдер, доведеться змінити базовий URL на той, що надає відповідний сервіс, і вказати сумісну назву моделі.

Так, для Minimax буде свій URL, для Anthropic Claude — інший. Головна вимога — підтримка OpenAI‑подібного API. Якщо це виконано, MiroFish може працювати з цими моделями без глибоких змін у коді: достатньо підставити правильний endpoint і модель.

Однак вибір моделі — це не лише питання якості, а й грошей. MiroFish запускає велику кількість агентів, які багато разів звертаються до LLM. У демонстраційному запуску з GPT‑4.0 повна симуляція обійшлася приблизно в 3 долари за API‑виклики. Це вже не копійки, але й не захмарна сума для складного експерименту.

Тім прямо застерігає від використання «ультра‑преміум» моделей на кшталт Opus із найвищими тарифами. За його оцінкою, у такому разі вартість одного повного прогону може легко зрости до десятків доларів — 20, 30, 40, 50 і більше, залежно від кількості агентів і тривалості симуляції.

Тому для більшості користувачів, які хочуть «погратися» з MiroFish, компроміс на кшталт GPT‑4.0 виглядає раціональним: модель достатньо потужна, щоб підтримувати складні дискусії агентів, але не настільки дорога, щоб кожен запуск ставав фінансовим ризиком.

Для тих, хто має доступ до дешевших або спеціалізованих моделей через OpenAI‑сумісні API, можливість змінювати базовий URL і модель відкриває шлях до оптимізації витрат. Але в будь‑якому разі варто пам’ятати: MiroFish — це не «один запит до чату», а сотні й тисячі звернень до LLM у межах однієї симуляції.

Zep Cloud: єдиний закритий компонент і фактична вимога за замовчуванням

Попри те, що MiroFish і Oasis є open source і можуть бути вільно клоновані, у стандартній конфігурації є один критичний виняток — Zep Cloud. Це хмарний сервіс, який використовується як система пам’яті для агентів. Він зберігає їхній контекст, історію, знання, що дозволяє симуляції бути послідовною, а не складатися з набору незалежних викликів LLM.

У типовому стеку MiroFish Zep Cloud — єдиний не‑open‑source компонент. Формально його можна замінити, але це потребуватиме суттєвої перенастройки проєкту. Тім прямо зазначає, що без «важкої» реконфігурації відмовитися від Zep практично неможливо: система на нього розрахована.

Водночас вхідний бар’єр для використання Zep Cloud відносно низький. Сервіс надає 1 000 безкоштовних кредитів і не вимагає введення даних банківської картки для старту. Для перших експериментів цього достатньо, особливо якщо не запускати симуляції безперервно.

Щоб підключити Zep до MiroFish, потрібно:

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

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

Для розробників, які принципово хочуть уникнути закритих сервісів, теоретично можливо замінити Zep на власне рішення або інший open source‑аналог. Але це вже окрема інженерна задача, яка виходить за межі «запустити MiroFish за інструкцією з GitHub». У стандартному сценарії Zep Cloud — фактично обов’язковий елемент.

Open source, локальний запуск і роль змінних середовища

Попри залежність від Zep Cloud, MiroFish залишається проєктом, який можна повністю розгорнути на власній машині. Репозиторій на GitHub відкритий, так само як і Oasis — рушій симуляції, що стоїть за ним. Це означає, що користувач може:

• клонувати репозиторій,
• встановити залежності,
• налаштувати змінні середовища,
• запустити бекенд і фронтенд локально.

Ключовим кроком є саме конфігурація змінних середовища. Сюди входять:

• API‑ключ LLM‑провайдера (OpenAI чи іншого OpenAI‑сумісного сервісу),
• базовий URL для API моделі, якщо використовується не OpenAI,
• назва моделі,
• API‑ключ Zep Cloud,
• інші параметри, які потрібні для коректної роботи Oasis і FastAPI.

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

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

Саме тому в гру вступає ще один елемент екосистеми — готове VPS‑розгортання.

Один клік до симуляції: VPS‑деплой MiroFish через Hostinger

Щоб знизити поріг входу для користувачів, які не хочуть витрачати години на налаштування, Тім уклав партнерство з Hostinger. Результат — можливість розгорнути MiroFish на віртуальному приватному сервері в один клік, використовуючи Docker.

За його словами, Hostinger став першою компанією, яка запропонувала таке рішення для MiroFish. Суть підходу проста: користувач обирає VPS‑план, натискає кнопку деплою, і система автоматично розгортає контейнер із MiroFish у захищеному середовищі. Після цього залишається лише ввести власні API‑ключі для LLM і Zep Cloud.

Ціни на такі VPS‑плани стартують приблизно від 6,50 долара на місяць. Тім рекомендує план KVM2, який коштує близько 9 доларів на місяць і, на його думку, краще підходить для стабільної роботи MiroFish. Усі розгортання відбуваються в Docker‑контейнері, що ізолює симуляцію від інших процесів і спрощує управління середовищем.

Після завершення деплою користувач отримує HTTPS‑URL, за яким доступний інтерфейс MiroFish. Далі потрібно:

• ввести API‑ключ LLM‑провайдера (наприклад, OpenAI),
• обрати модель (наприклад, GPT‑4.0),
• за потреби змінити базовий URL і модель для альтернативних провайдерів,
• додати API‑ключ Zep Cloud.

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

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

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

Запуск MiroFish — це завжди поєднання трьох типів витрат: інфраструктура, пам’ять і LLM‑запити.

Інфраструктура може бути безкоштовною, якщо користувач запускає систему локально на власному обладнанні. У такому разі доведеться платити лише за API‑виклики до LLM і, за потреби, за додаткові кредити в Zep Cloud. Якщо ж обрати VPS‑варіант, до цього додається щомісячна абонплата за сервер — від приблизно 6,50 до 9 доларів і вище, залежно від плану.

Пам’ять у вигляді Zep Cloud стартує з 1 000 безкоштовних кредитів без вимоги вказувати картку. Це дозволяє провести низку повноцінних симуляцій, перш ніж виникне потреба в оплаті. Для інтенсивного використання, як у випадку Тіма, знадобиться перехід на платний тариф.

Найбільш змінною статтею витрат залишаються LLM‑запити. У демонстраційному запуску з GPT‑4.0 повна симуляція коштувала близько 3 доларів. Це дає орієнтир для тих, хто планує серію експериментів: десяток прогонів — це вже десятки доларів лише на API‑виклики.

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

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

Висновок: MiroFish як тест на зрілість AI‑інфраструктури

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

З одного боку, користувач отримує повністю open source‑рушій симуляції (Oasis), відкритий репозиторій MiroFish, можливість запускати все локально й гнучко обирати LLM‑провайдера. З іншого — залежність від зовнішнього сервісу пам’яті (Zep Cloud), реальні витрати на API‑запити й потребу в мінімальній інженерній грамотності для налаштування змінних середовища.

Партнерський VPS‑деплой через Hostinger показує ще один тренд: поява «один‑клік» інфраструктури для складних AI‑проєктів. Те, що ще кілька років тому вимагало окремої DevOps‑команди, сьогодні зводиться до вибору тарифу й введення кількох ключів.

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

Джерело

YouTube: I Spawned 10,000 AI Agents to Predict the Future (MiroFish is Insane)

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

Від «повторювати» до «думати»: чим відрізняється філософія

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

• Що я думаю?
• У що я вірю?
• Як я можу захистити свої переконання?

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

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

Філософія поза університетом: як мислити критично в будь-якій сфері

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

У менеджменті та командній роботі

Менеджери й лідери команд можуть свідомо використовувати філософські інструменти:

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

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

У будь-якій професії

Філософське мислення корисне там, де потрібно:

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

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

Як розвивати «філософський ген», якщо ви не вчилися на філософа

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

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

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

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

Джерело

Professor Meghan Sullivan explains how she made asking questions into a career #TEDTalks

Квантові комп’ютери загрожують основам сучасної криптографії, зокрема алгоритмам на кшталт RSA, які сьогодні захищають більшість інтернет‑трафіку. Канал IBM Technology пояснює, чому класичні підходи більше не можна вважати достатньо надійними, і як ґраткова (lattice‑based) криптографія стає ключовою технологією пост‑квантової безпеки.

Чому «важкі» математичні задачі — це наша кіберброня

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

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

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

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

Ґраткова криптографія: складність у тисячі вимірів

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

Від шахового коня до багатовимірних ґраток

Для інтуїтивного розуміння використовується аналогія з шаховим конем:

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

Далі складність нарощується:

• замість фіксованих «2+1» кроків вводяться змінні «x+y» — безліч можливих комбінацій;
• замість двох вимірів — тисяча вимірів;
• додається шум: цільові точки не лежать точно в «дозволених» позиціях, а лише поблизу них.

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

• є початкова точка (origin) і базисні вектори;
• будь‑яка цілочисельна комбінація цих векторів утворює нову точку ґратки;
• вся множина таких точок — це ґратка в багатовимірному просторі.

Задача полягає в тому, щоб:

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

Це відоме як «learning with errors» (навчання з помилками) — клас задач, які вважаються надзвичайно складними як для класичних, так і для квантових комп’ютерів, якщо ґратка достатньо складна, а шум — достатньо великий.

Чому квантові комп’ютери тут безсилі

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

Ґраткові задачі, що лежать в основі пост‑квантових алгоритмів, сконструйовані саме так:

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

Результат: криптографія, яка «переживе» появу потужних квантових машин.

Стандарти пост‑квантової криптографії вже готові

Питання пост‑квантової безпеки не залишилося теоретичним. Близько десяти років тому Національний інститут стандартів і технологій США (NIST) оголосив конкурс на нові криптоалгоритми, стійкі до квантових атак.

Наслідки цього процесу:

• провідні криптографи світу запропонували й проаналізували десятки схем;
• значна частина найперспективніших рішень базується саме на ґратковій криптографії;
• сформовано набір «quantum‑safe» / «post‑quantum» алгоритмів, які:
• реалізують ґраткову арифметику та задачі типу learning with errors;
• доступні в відкритих репозиторіях;
• оформлені як галузеві стандарти.

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

Як організаціям готуватися до «Q‑Day»

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

1. Виявлення та інвентаризація криптографії

Перший крок — повне розуміння, де і як у вашій інфраструктурі використовується криптографія:

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

Результат — «crypto bill of materials» (C‑BOM), криптографічний «реєстр компонентів», який описує всі випадки використання шифрування, підписів, протоколів обміну ключами тощо.

2. Оцінка ризиків і пріоритезація

Далі потрібно:

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

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

3. Планування та ремедіація

Етап впровадження включає:

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

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

4. Криптоагільність як стратегічна мета

Кінцева ціль — досягти «crypto agility», тобто здатності:

• швидко і керовано замінювати криптоалгоритми;
• оперативно реагувати, якщо в одному зі стандартів виявлять слабкість;
• не перебудовувати інфраструктуру з нуля, а просто оновлювати вибрані елементи, спираючись на C‑BOM.

За наявності якісної інвентаризації достатньо буде:

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

«Harvest now, decrypt later»: чому діяти потрібно сьогодні

Один із головних аргументів на користь негайних дій — стратегія «harvest now, decrypt later»:

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

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

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

Джерело

Post‑Quantum Security: How Lattice Cryptography Keeps Data Safe — IBM Technology