Після аварії на Фукусімській АЕС Японія опинилася перед енергетичним вибором: замінити атомну генерацію вугіллям чи зробити ставку на чисті джерела. TED-виступ кліматичної активістки Кіміко Хірати, записаний на TED Countdown Summit 2025, показує, як невеликий громадський рух зміг зупинити частину вугільних проєктів і переформатувати дискусію — від «ні вугіллю» до «так відновлюваній енергетиці».

Вибух вугільних проєктів після Фукусіми

Після зупинки всіх ядерних реакторів у 2011 році японська енергосистема опинилася на роздоріжжі. Суспільна увага змістилася на ризики атомної енергетики, а тема клімату відійшла на другий план. Цим скористалася вугільна галузь: кількість нових проєктів вугільних електростанцій стрімко зросла — спочатку 10, потім 20, а згодом і до 50 запланованих об’єктів.

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

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

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

Акціонерний тиск на фінансистів вугілля

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

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

Сукупність локальних кампаній, публічного тиску та акціонерних дій дала відчутний ефект: із 50 запланованих вугільних проєктів 17 (загальною потужністю 9 ГВт) були скасовані. За оцінками, це дозволило уникнути 50 млн тонн CO₂ щороку та 1,7 млрд тонн за весь строк роботи цих станцій — еквівалент виведення з експлуатації понад 8 млн автомобілів щороку протягом 40 років.

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

Від «ні вугіллю» до «так відновлюваній енергетиці»

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

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

Щоб працювати з цими сумнівами, була створена незалежна аналітична структура Climate Integrate. Її завдання — надавати фактологічну базу, яка може прискорити енергетичний перехід, і вести діалог з урядовими структурами та бізнесом. Підхід змінився: замість фронтального протистояння — робота з різними точками зору, пошук спільних рішень і формування внутрішнього переконання, що перехід до ВДЕ можливий і доцільний.

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

Міста як лабораторії енергетичного переходу

Ще один напрям — співпраця з муніципалітетами. Наразі в фокусі три міста, які демонструють різні моделі переходу до низьковуглецевої економіки.

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

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

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

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

Візія: 90% ВДЕ та експорт змін до Азії

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

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

Джерело

«A Cheat Sheet for Canceling Coal | Kimiko Hirata | TED»

Запуск ChatGPT Images 2.0 став однією з найпомітніших подій на ринку генеративної графіки 2026 року. Новий візуальний модуль від OpenAI, інтегрований у ChatGPT, позиціонують як серйозного конкурента популярним моделям на кшталт Nano Banana, які довго вважалися «золотим стандартом» для зображень. Канал Futurepedia провів розгорнуте практичне тестування новинки — від промпт‑трюків до складних інфографік та освітніх постерів.

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

Одне слово, велика різниця: як «photorealism» змінює якість зображень

Перший практичний висновок, який кидається в очі під час роботи з ChatGPT Images 2.0, стосується промптингу. Звичні формулювання на кшталт «realistic photo», «iPhone photo» чи «cinematic» дають цілком пристойні результати, але не виводять модель на максимум її можливостей.

Ключовим виявилося одне слово — «photorealism». Додавання цього терміна до вже наявного промпту радикально змінює результат:

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

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

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

Це добре ілюструє важливу рису сучасних генеративних моделей: вони мають власні «мовні звички» та приховані стилістичні перемикачі. Те, що працює в одному генераторі («cinematic», «DSLR shot», «8k»), не обов’язково дає найкращий результат в іншому. Для ChatGPT Images 2.0 таким перемикачем, принаймні зараз, виявляється саме «photorealism».

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

Редагування зображень: від зміни статі до повороту сцени

Ще одна сильна сторона ChatGPT Images 2.0 — гнучке редагування вже створених або завантажених зображень. Модель не обмежується простими інпейнт‑операціями, а дозволяє послідовно змінювати сцену, зберігаючи при цьому логіку та цілісність персонажів.

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

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

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

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

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

4K через API: коли роздільна здатність справді має значення

Ще один важливий елемент екосистеми ChatGPT Images 2.0 — підтримка 4K‑генерації через API. OpenAI додала цю опцію для GPT‑Image 2, і в тестах вона виявилася не просто маркетинговою позначкою, а реальним покращенням якості, особливо для облич і дрібного тексту.

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

У базовому режимі всередині ChatGPT результат вийшов набагато кращим, ніж зазвичай дають подібні інструменти, але обличчя все ж залишалося трохи «м’яким», із недостатньою деталізацією. Після запуску того ж промпту через 4K‑опцію API (у тесті використовувався сервіс Higgs Field як інтерфейс до моделі) чіткість помітно зросла: зморшки, текстура шкіри, дрібні риси стали значно виразнішими.

Для порівняння той самий сценарій прогнали через Nano Banana з її власною 4K‑опцією. Там обличчя стабільно виглядали «не так»: пропорції, вираз, дрібні деталі були помітно менш точними. Це не означає, що Nano Banana погано працює в усіх 4K‑сценаріях, але саме в задачі комбінування реальних фото GPT‑Image 2 із 4K‑режимом показав себе переконливіше.

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

Від алфавітних постерів до сіток 10×10: логіка, простір і текст

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

Класичний «головоломковий» промпт — постер «alphabet animals», де кожна літера англійського алфавіту має відповідати тварині: A — alligator, B — bear, C — cat тощо. На перший погляд завдання просте, але на практиці багато моделей спотикаються на останніх рядках: 26 літер не вкладаються в ідеальну прямокутну сітку, і генератор починає «вигадувати» власну структуру.

У Nano Banana це проявлялося у вигляді зсувів: літери й назви тварин переставлялися місцями, деякі букви пропускалися, інші дублювалися. В одному з варіантів Q виявилася під носорогом, R — під лінивцем, а в іншому W і X були об’єднані в одну плитку з «гібридом» кита та риби‑рентгена.

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

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

Результат виявився майже бездоганним. Лише при детальному розгляді виявилися кілька дрібних збоїв: наприклад, «answering machine» і куртка опинилися на одній плитці, а в іншому місці з’явилася неоднозначність із «antique key». Водночас модель коректно обробила менш очевидні слова: «aubergine» було правильно інтерпретовано як баклажан, хоча для багатьох користувачів це слово потребує додаткового пояснення.

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

Окремої уваги заслуговує робота з текстом у складних макетах. У пародійному кіноафіші дрібний «службовий» текст унизу — імена композитора, монтажера, художника‑постановника — був відтворений без помилок: «Music by Binary Bard», «Edited by Cut and Code», «Production design by Pixel and Pine». Для порівняння, Nano Banana в аналогічному завданні створила естетично привабливий постер, але дрібний текст виявився спотвореним і нерозбірливим.

Ще один показовий кейс — газетна перша шпальта з анонсом запуску GPT Images 2. Тут ChatGPT Images 2.0 згенерував повноцінний макет: головний заголовок, підзаголовки, додаткові статті по краях, читабельний текст без очевидних артефактів. У Nano Banana подібні завдання часто «ламаються» саме на другорядному тексті: якщо не підвантажувати готовий контент, модель заповнює поля псевдосимволами або напівчитабельними фрагментами.

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

Thinking mode: коли генератор картинок спершу йде «вчитись»

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

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

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

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

Thinking mode виявився корисним і в іншому складному макеті — газетній першій шпальті про запуск GPT Images 2. Тут модель не просто розмістила заголовок, а й продумала оточення: додаткові статті, бічні колонки, дрібні підписи. Текст навколо основного матеріалу залишився чистим і читабельним, без характерного для багатьох моделей «псевдошрифту».

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

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

Освітні та робочі сценарії: від рецептів до рукописних постерів

Практичні тести показують, що ChatGPT Images 2.0 особливо добре почувається в ролі інструмента для створення навчальних і робочих матеріалів.

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

Ще один яскравий приклад — постер «We are Stardust and Co.» у стилі рукописних заміток. У Nano Banana результат вийшов акуратним, без явних помилок у тексті, але візуально нагадував звичайний друкований плакат: рівні лінії, передбачувана композиція, відсутність «живих» деталей.

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

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

Висновки: генератор зображень, який мислить як редактор

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

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

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

По‑третє, підтримка 4K через API робить її придатною для професійних задач, де критичні деталізація облич і чіткість дрібного тексту.

По‑четверте, ChatGPT Images 2.0 впевнено працює там, де інші моделі часто помиляються: алфавітні постери, великі сітки об’єктів, газетні шпальти, інфографіки з великою кількістю тексту.

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

У підсумку ChatGPT Images 2.0 виглядає як інструмент, який може стати центральним елементом робочих процесів для тих, хто працює на перетині тексту, даних і візуального контенту. І якщо сьогодні він уже впевнено конкурує з Nano Banana в низці ключових завдань, то подальший розвиток thinking mode і текстових можливостей може ще більше змістити баланс сил на ринку генеративної графіки.

Джерело

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

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

Як Claude Code виконує дії в проєкті

Під час роботи з Claude Code розробник може сформулювати запит на кшталт: «Створи тестовий файл README». Замість того, щоб одразу створити файл, інструмент спершу виводить запит на підтвердження: чи дійсно потрібно додати README.md до поточного проєкту.

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

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

Фактично Claude Code поводиться як агент, який завжди «стукає в двері» перед тим, як щось змінити.

Чому агент постійно запитує підтвердження

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

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

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

Режими дозволів: як зменшити кількість запитів

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

Ідея режимів у тому, щоб знайти баланс між:

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

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

Чому модель дозволів стає стандартом для AI-інструментів

Підхід, який демонструє Claude Code, добре вписується в загальну тенденцію розвитку AI-інструментів для розробників:

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

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

Джерело

Повний огляд Claude Code – Частина 6 — KODARIK

Коли дослідник Кембриджського університету та автор «Designing Data‑Intensive Applications» Мартін Клеппман говорить про майбутнє інженерії, він постійно повертається до однієї теми: межі абстракцій. У світі, де більшість бекендів живе в керованих хмарах, а код усе частіше генерують великі мовні моделі, спокуса «не думати про нижні шари» здається природною. Але чи не втрачають команди при цьому здатність розуміти, як насправді працюють їхні системи — і що робити, коли все ламається?

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

Коли абстракції корисні, а коли — небезпечні

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

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

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

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

Зручність проти контролю: не лише про продуктивність і рахунки в хмарі

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

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

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

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

LLM не скасовують системне мислення — вони підвищують ставки

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

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

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

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

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

Формальна верифікація як відповідь на зростаючу складність

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

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

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

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

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

Від MapReduce до векторних індексів: абстракції змінюються, фундаментальні питання — ні

Друга, суттєво оновлена редакція «Designing Data‑Intensive Applications», що вийшла приблизно через дев’ять років після першої, сама по собі є відображенням зміни абстракцій. Клеппман спільно з Крісом Ріккоміні прибрав із книги розділи про MapReduce, який він безапеляційно називає мертвим: «ніхто більше цим не користується». Натомість з’явилися розширені розділи про системи, що підтримують AI‑навантаження, зокрема про векторні індекси.

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

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

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

Хто має «володіти» глибиною: нова роль системних інженерів

Якщо прийняти, що не кожен розробник має бути експертом із розподілених систем, постає питання: хто тоді відповідає за те, щоб у компанії зберігалося це знання?

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

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

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

Висновок: абстракції — це не втеча від складності, а спосіб її організувати

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

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

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

Джерело

Повна розмова: Designing Data-intensive Applications with Martin Kleppmann — The Pragmatic Engineer

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

Нові «економіки виробництва»: робота дешева, планування й рев’ю — ні

За останні 6–12 місяців змінилася сама структура роботи з AI‑системами:

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

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

«Правило верифікатора» і чому не всі задачі піддаються агентам

Корисна рамка для розуміння можливостей агентів — правило верифікатора (verifier’s rule), сформульоване Джейсоном (прізвище в доповіді не уточнюється):

Якщо задачу можна розв’язати і її легко перевірити, її розв’яже AI.

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

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

Приклад: юридична галузь

• Перевірка визначень у контракті
  Легко верифікувати: чи всі терміни визначені, чи всі визначення використовуються. Це добре піддається автоматизації.
• Написання контракту загалом
  Згенерувати текст — нескладно. Але перевірити, чи «правильний» цей контракт, часто можна лише в суді, коли суддя фактично виступає остаточним верифікатором. Це робить задачу дуже складною для повної автоматизації.
• Стратегія судового спору (літигації)
  Якщо п’ять юристів дадуть п’ять різних стратегій, немає об’єктивної «єдино правильної» відповіді. Верифікація тут майже неможлива.

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

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

Довіра й контроль: як правильно ділити роботу між людьми та агентами

Для ефективної співпраці людини й агента важливі дві осі:

• Довіра (trust) — скільки роботи можна не перевіряти.
• Контроль (control) — наскільки ефективно людина може «вшити» свій досвід і судження в роботу агента.

Як підвищити довіру до агента

1. Зробити задачу більш верифікованою
2. У розробці:
   • дати агенту доступ до браузера;
   • використовувати TDD (спочатку тести, потім реалізація).

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

3. У фінансах чи праві можна шукати проксі‑метрики верифікації.
   Наприклад, для контрактів:
   • взяти «золоті» (еталонні) контракти, які добре працювали в минулому;
   • порівнювати новий контракт із цими зразками;
   • будувати тести на схожість структури, формулювань, ключових положень.

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

4. Декомпозувати задачу

Замість «написати контракт» — розбити роботу на підзадачі:

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

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

1. Встановити guardrails (обмеження)

Це спосіб підвищити довіру, обмеживши можливості агента:

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

Чим менше свободи для «дивних дій», тим легше довіряти системі.

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

Як підвищити контроль над агентом

Складну роботу агента можна уявити як дерево або DAG завдань:

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

1. Планування: корисно, але недостатньо

На етапі планування агент пропонує кроки: що дослідити, які пункти перевірити, як структурувати роботу. Людина може:

• скоригувати план;
• додати чи прибрати кроки;
• уточнити, на що звернути увагу.

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

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

Тому планування — корисний, але не достатній механізм контролю.

2. Skills: «вшивання» людського досвіду в вузли роботи

Більш потужний підхід — skills (навички), тобто формалізовані способи виконання окремих підзадач. Наприклад:

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

Переваги skills:

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

Мінус очевидний: skills не покривають усе. Неможливо заздалегідь описати кожен можливий випадок.

3. Еліцитація: питати людину, але без «інфінітного чату»

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

• агент приходить із конкретним питанням: «Я натрапив на такий випадок, як мені діяти?»;
• бажано, щоб агент не блокувався: якщо не впевнений, він:
• приймає тимчасове рішення;
• записує його в журнал рішень (decision log);
• продовжує роботу.

Потім людина може:

• переглянути журнал;
• скасувати або скоригувати окремі рішення.

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

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

Чат виявляється одновимірним і низькопродуктивним способом керувати складним деревом роботи.

Чому чат — це тупик для складних агентів

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

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

Для реальної спільної роботи потрібні «високоширокосмугові» (high‑bandwidth) артефакти, які:

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

Приклади таких артефактів

1. Документ як спільний простір роботи

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

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

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

1. Табличний огляд (tabular review)

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

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

Людина отримує:

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

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

Мова — універсальний інтерфейс, але не єдиний для агентів

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

• ставити завдання;
• уточнювати вимоги;
• пояснювати контекст.

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

Агенти таких обмежень не мають:

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

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

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

Висновок

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

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

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

Source

Agents need more than a chat – Jacob Lauritzen, CTO Legora

Запуск ChatGPT Images 2.0 став однією з найпомітніших подій на ринку генеративної графіки 2026 року. У новому випуску каналу Futurepedia автор детально порівнює цю модель з Nano Banana — інструментом, який тривалий час вважався «золотим стандартом» для якісних зображень і тексту в кадрі. Серія практичних тестів показала: GPT‑Image 2 не просто наздогнав конкурента, а в низці важливих сценаріїв вийшов уперед — особливо там, де йдеться про дрібний текст, складні інтерфейси, технічні діаграми та логічно структуровані інфографіки.

Фотореалізм, редагування та 4K: фундамент, на якому будується перевага

Перші враження від ChatGPT Images 2.0 виявилися стриманими: стандартні запити на кшталт «realistic photo», «iPhone photo», «cinematic» не давали очікуваного рівня реалістичності. Прорив стався після простої, але показової знахідки: додавання до промпту слова «photorealism» радикально змінює результат. За незмінних інших умов одне це слово перетворює картинку з «просто непоганої» на значно більш живу й переконливу. Це добре ілюструє, наскільки поведінка сучасних моделей залежить від точних формулювань і як невелика зміна в промпті може розкрити прихований потенціал.

На базовому рівні GPT‑Image 2 демонструє те, що вже стало стандартом для топових генераторів: адекватне дотримання промптів, коректні обличчя навіть у сценах з великою кількістю людей, стабільну якість зображень. Важливий момент — це суттєве оновлення порівняно з попередньою версією ChatGPT‑моделі для зображень, яка помітно відставала від лідерів.

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

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

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

Окремий технічний крок уперед — поява 4K‑опції для GPT‑Image 2 через API OpenAI. У тесті зі змішуванням двох реальних фотографій результат у стандартній роздільній здатності виглядав добре композиційно, але обличчя залишалося дещо «м’яким». Перегенерація того ж запиту через 4K‑режим (через сервіс Higgs Field) дала значно вищу чіткість рис обличчя. Для порівняння, Nano Banana з власною 4K‑опцією на цьому ж завданні стабільно видавала «дивні» обличчя, які виглядали неприродно, попри високу роздільну здатність. Це важливий сигнал: висока роздільна здатність сама по собі не гарантує якості, якщо модель гірше справляється з базовою структурою об’єкта.

Дрібний текст і постери: де Nano Banana починає «ламати літери»

Текст завжди був ахіллесовою п’ятою генеративної графіки. Nano Banana довго вважалася однією з найкращих у цій сфері, але GPT‑Image 2 помітно змістив баланс сил.

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

Справжній розрив стався на тесті з пародійним постером до фільму. Обидві моделі змогли відтворити загальну композицію та основні елементи, але вирішальним виявився дрібний шрифт у нижній частині — саме той «юридичний» або технічний текст, який роками перетворювався на кашу в більшості генераторів. GPT‑Image 2 коректно відтворив усі фрази: «Music by Binary Bard», «edited by Cut and Code», «production design by Pixel and Pine» — без спотворень, з правильною орфографією та розбірливими літерами. У Nano Banana, попри привабливішу загальну естетику постера, дрібний текст внизу виявився типовим «глітчем»: деформовані літери, нерозбірливі слова, фактично непридатний для читання блок.

Цей приклад добре демонструє, що саме в зоні дрібного тексту, де раніше Nano Banana мала перевагу, GPT‑Image 2 тепер виглядає переконливіше. Для дизайнерів, які створюють постери, обкладинки, рекламні макети або прев’ю до відео, це не дрібниця, а критичний фактор. Показово, що перша ж спроба згенерувати прев’ю (thumbnail) для відео про GPT‑Image 2 дала результат, який автор оцінив як «значно кращий за стандартні прев’ю з Nano Banana та інших генераторів» — настільки, що він планує використати саме зображення з ChatGPT і навіть A/B‑тестувати кілька варіантів.

Ще один текстовий сценарій — рукописний постер у стилі «We are Stardust and Co.». Nano Banana впоралася з завданням формально: текст без помилок, але загальний вигляд вийшов «чистим» і надто акуратним, без відчуття справжнього рукопису. GPT‑Image 2, навпаки, створив сторінку, яка виглядає як живий, хаотичний конспект: нерівні літери, дрібні каракулі, розкидані по полю елементи, безліч маленьких іконок і «кліпарту». Візуально це набагато ближче до реальної рукописної нотатки, і саме така увага до дрібних деталей робить сцену переконливою.

Складні інтерфейси та технічні діаграми: де GPT‑Image 2 показує «інженерний» рівень

Однією з найяскравіших демонстрацій можливостей GPT‑Image 2 стали тести на відтворення складних інтерфейсів і технічних схем. Тут мова вже не лише про красу, а про структурну точність, логіку розташування елементів і коректність підписів.

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

Ще один тест — відтворення сторінки Explore на сайті Midjourney. GPT‑Image 2 не лише зберіг загальне компонування, а й наповнив плитки зображеннями, які стилістично дуже нагадують роботи, створені в Midjourney. Це свідчить про здатність моделі не просто копіювати структуру інтерфейсу, а й стилістично наслідувати контент, який зазвичай у ньому з’являється.

Найвражаючішим став експеримент із ComfyUI — популярним інструментом для побудови складних пайплайнів генерації зображень і відео. Завдання полягало у створенні скриншота робочого процесу, де зображення генерується, а потім подається в конвеєр image‑to‑video. GPT‑Image 2 відтворив:

читабельний текст промпту у верхній частині;
окремий блок із negative prompt conditioning;
коректні назви нод, включно з використанням AnimateDiff та завантаженням motion LoRA;
типові значення параметрів, наприклад, кількість кадрів за секунду.

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

Цю ж тенденцію підтверджує тест із робочим місцем інженера з двома моніторами. На зображенні, згенерованому GPT‑Image 2, при збільшенні видно:

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

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

Логіка, інфографіки та «алфавітні» виклики: де нова модель демонструє глибше розуміння

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

Показовий приклад — плакат «alphabet animals», де потрібно розмістити 26 літер англійського алфавіту з відповідними тваринами. Nano Banana у різних версіях стабільно «спотикалася» на нижніх рядах: або пропускала літеру, або об’єднувала дві в одну плитку, або плутала відповідність між літерами й назвами тварин. У одному з випадків Q виявилася підписом до носорога, R — до лінивця, а в іншому модель об’єднала W і X в один блок, замість окремих зображень кита й риби‑рентгена. GPT‑Image 2 вперше впорався із завданням бездоганно: усі 26 літер, усі відповідні тварини, без пропусків і зміщень. Для людини це тривіальна задача, але для генеративної моделі зображень — складний тест на поєднання просторової організації, рахунку й асоціацій.

Ще складнішим став експеримент із сіткою 10×10, де потрібно розмістити 100 об’єктів, що починаються на літеру A. GPT‑Image 2 майже впорався: при поверхневому перегляді помилок не видно, але при детальному аналізі виявляється кілька збоїв — наприклад, плитка, де на одному місці опинилися і куртка, і автовідповідач, або подвійне трактування окремих слів. Водночас модель коректно розпізнала, що aubergine — це баклажан, тобто показала не лише візуальну, а й лінгвістичну обізнаність. Попри кілька неточностей, сам факт, що модель змогла заповнити 100‑елементну сітку логічно пов’язаними об’єктами, свідчить про суттєвий прогрес у «рахункових» і класифікаційних завданнях.

У сфері інфографіки GPT‑Image 2 також виглядає сильнішим за Nano Banana. На прикладі кулінарного постера з рецептом обидві моделі змогли створити привабливі візуально зображення без помилок у тексті. Однак версія від ChatGPT виявилася значно кориснішою практично: вона містила конкретні кількості інгредієнтів, детальні покрокові інструкції, чітку структуру, яка дозволяє реально приготувати страву, спираючись лише на цей плакат. У Nano Banana інфографіка виглядала добре, але була менш інформативною, з меншою кількістю практичних деталей. Це важливий маркер: GPT‑Image 2 не просто «малює текст», а наповнює його змістом, який має сенс у контексті задачі.

Ще один показовий кейс — газетна перша шпальта з новиною про запуск GPT Images 2. Модель створила макет, який виглядає як реальна газета: головний заголовок, кілька додаткових статей, колонки тексту, без помітних помилок у написанні. У Nano Banana подібні завдання зазвичай вимагають попереднього надання всього тексту, інакше «фонові» статті заповнюються спотвореними словами. GPT‑Image 2, навпаки, здатен самостійно згенерувати правдоподібний газетний контент, зберігаючи читабельність навіть у другорядних блоках.

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

Що це означає для ринку генеративної графіки

Порівняння ChatGPT Images 2.0 з Nano Banana показує цікаву зміну акцентів у розвитку генеративних моделей. Якщо раніше основна конкуренція точилася навколо стилю, фотореалізму та художньої виразності, то тепер на перший план виходять:

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

GPT‑Image 2 демонструє, що інтеграція потужної мовної моделі з візуальним генератором дає відчутну перевагу саме в цих зонах. Там, де Nano Banana все ще може виглядати привабливіше стилістично, нова модель OpenAI часто виграє за рахунок точності, читабельності й структурованості.

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

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

Висновок

ChatGPT Images 2.0 став для OpenAI не просто черговим оновленням, а якісним стрибком у сегменті генеративної графіки. У тестах, де раніше беззаперечно домінувала Nano Banana, нова модель або зрівнялася, або вийшла вперед — особливо там, де йдеться про дрібний текст, складні інтерфейси, технічні діаграми та логічно структуровані інфографіки. Додавання 4K‑режиму через API ще більше посилює її позиції в задачах, де важлива деталізація облич і дрібних елементів.

На тлі цього Nano Banana вже не виглядає недосяжним лідером. Ринок входить у фазу, де ключовим стає не лише художній стиль, а й здатність моделі «мислити» в межах зображення: рахувати, структурувати, узгоджувати текст і графіку. І саме в цій новій реальності GPT‑Image 2 виглядає одним із головних претендентів на роль нового стандарту.

Джерело

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

Штучний інтелект уже суттєво здешевлює розробку програмного забезпечення, але це лише перший удар по традиційній SaaS-моделі. У розмові на подкасті 20VC with Harry Stebbings пролунала теза: справжній злам для ринку настане тоді, коли ШІ так само радикально знизить вартість і складність перенесення даних між сервісами.

Коли створення софту дешевшає, що тоді має цінність?

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

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

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

Поки що відповідь часто зводиться до одного: дані.

Дані як головний “замок” SaaS

Сьогодні більшість SaaS-компаній тримають клієнтів не лише завдяки продукту, а й завдяки високим “витратам на вихід” — насамперед через дані:

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

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

Як ШІ може зламати “данкові кайдани”

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

• зчитати структуру даних у поточного SaaS-провайдера;
• інтерпретувати її відповідно до моделі даних нового сервісу;
• трансформувати й перенести інформацію автоматично;
• зробити це максимально просто — аж до сценарію “один клік”.

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

У цьому сценарії:

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

Коли починається справжній ризик для SaaS-моделі

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

Ситуація кардинально зміниться, коли:

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

Саме тоді загроза для традиційної SaaS-моделі стане системною. Перевага більше не ґрунтуватиметься на тому, наскільки складно піти, а на тому, наскільки переконливо продукт щодня доводить свою цінність.

Джерело

The REAL Threat to SaaS — 20VC with Harry Stebbings

У подкасті IBM Security Intelligence креативна директорка IBM X‑Force Cyber Range Клер Нуньєс, віцепрезидент з глобального управління кіберзагрозами Дейв Маꥳнніс та інженерка з детекції загроз Кіммі Фаррінгтон обговорюють, як штучний інтелект змінює саму природу програмного забезпечення й оборони. Від експериментів із агентами на кшталт OpenClaw до ідей Брюса Шнайєра про «миттєве» програмне забезпечення — розмова зводиться до одного: або захисники навчаться використовувати потужні AI‑моделі, або цим скористаються нападники.

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

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

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

Автоматизація таких процесів за допомогою AI‑агентів дозволяє:

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

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

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

Команди безпеки як природні лідери AI‑трансформації

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

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

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

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

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

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

Claude Mythos, GPT‑5.4 Cyber і гонка озброєнь: чому захисникам не можна відставати

На ринку вже з’являються спеціалізовані моделі, орієнтовані на безпеку: у подкасті згадуються Claude Mythos від Anthropic та GPT‑5.4 Cyber від OpenAI. Це не просто «чергові LLM», а інструменти, які можна використовувати для аналізу, виявлення загроз, моделювання атак і захисту.

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

Аргументація проста. Потужні моделі дозволяють:

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

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

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

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

«Миттєве» програмне забезпечення й фантомні додатки: виклик епохи AI‑генерації коду

Другий великий пласт дискусії стосується того, як сам характер програмного забезпечення змінюється під впливом AI. Тут важливою точкою відліку стає есе Брюса Шнайєра «Cybersecurity in the Age of Instant Software», де він описує потенційне майбутнє «миттєвого» ПЗ.

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

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

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

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

Такі «епізодичні» застосунки можуть:

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

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

AI‑агенти як «корисні інсайдери» і чому без людини в циклі поки ніяк

Окрема лінія розмови стосується того, як саме працювати з AI‑агентами всередині організації. Приклад OpenClaw тут показовий. Як тільки інструмент став доступним публічно, частина адміністраторів у IBM просто завантажила його й почала запускати на власних системах. Команда детекції, за словами Кіммі Фаррінгтон, раптово виявила, що не готова до такого сценарію й змушена в авральному режимі вигадувати, як блокувати агент, який має привілейований доступ і задуманий як «корисний помічник».

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

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

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

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

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

Висновок: стратегія для епохи миттєвого коду й розумних агентів

Штучний інтелект одночасно змінює й інструменти захисту, і сам об’єкт захисту. З одного боку, з’являються спеціалізовані моделі на кшталт Claude Mythos і GPT‑5.4 Cyber, які можуть суттєво посилити оборону, автоматизувавши аналіз, виявлення й моделювання атак. З іншого — AI робить можливим світ «миттєвого» програмного забезпечення, де застосунки народжуються й зникають за секунди, залишаючи по собі сліди, які легко перетворюються на вразливості.

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

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

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

Джерело

Security Intelligence Podcast – Should you let OpenClaw pen test your system? Plus: Cybersecurity for ephemeral software

Швидкий розвиток AI‑агентів змушує переглянути базові принципи проєктування програмного забезпечення. Розмова на подкасті 20VC with Harry Stebbings пропонує простий, але жорсткий критерій: головне питання вже не «які в нас фічі», а «наскільки добре наші API та чи готові вони до роботи з агентами».

Від «фіч» до API: нова ціннісна пропозиція

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

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

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

Не весь софт однаковий: потрібна «матриця» підходів

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

1. Рівень бізнес‑логіки
2. Продукти з великою кількістю складних правил, процесів, перевірок, інтеграцій.

3. Простіші інструменти з мінімальною логікою.

4. Ступінь взаємодії «людина ↔ агент»

5. Сценарії, де потрібна тісна співпраця: людина задає цілі, коригує, затверджує.
6. Сценарії, де агент може працювати майже автономно.

У різних квадрантах цієї умовної «2×2» матриці вимоги до API та архітектури будуть різними. Наприклад:

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

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

Де агенти не загроза, а прискорювач розвитку

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

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

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

Як зрозуміти, чи ваш продукт «agent‑ready»

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

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

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

Джерело

YouTube: Is your software agent-ready? — 20VC with Harry Stebbings

У новому покроковому туторіалі на каналі Tech With Tim демонструється, як з нуля зібрати AI‑email‑асистента: достатньо надіслати листа на спеціальну адресу — і система відповість, надішле вітальний лист, а згодом дозволить робити розсилки всім контактам. Під капотом — Next.js, Postmark для пошти, Anthropic Claude для генерації відповідей і компактний, але продуманий бекенд на SQLite з Drizzle ORM.

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

SQLite як ядро збереження контактів і листування

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

Доступ до бази реалізовано через бібліотеку better-sqlite3. Це нативний драйвер для Node.js, орієнтований на продуктивність і синхронний API. Він добре підходить для сценарію, де запити до бази відносно короткі, а обсяг даних — помірний, як у випадку логів листування й списку контактів.

Поверх драйвера використовується Drizzle ORM. У цьому проєкті Drizzle виконує одразу кілька ролей. По‑перше, це типобезпечний шар доступу до даних у TypeScript, який дозволяє уникати сирого SQL і помилок у запитах. По‑друге, це єдине джерело правди для схеми: таблиці описуються в коді, а Drizzle Kit синхронізує ці описи з реальною базою.

Схема моделюється в одному спільному файлі lib/db.ts. Саме на нього посилається конфігурація Drizzle (drizzle.config.ts), тож будь‑які зміни в цьому файлі стають основою для оновлення структури бази. Це важливо для підтримки цілісності: бекенд, AI‑логіка й UI‑дашборд працюють з одними й тими самими типами та полями.

Фізично база — це файл emails.db. У drizzle.config.ts він вказаний як ціль для підключення, а Drizzle знає, що працює з SQLite через параметр dialect. У результаті розробник отримує просту, але чітко описану систему збереження: один файл схеми, один файл бази, один ORM‑шар, який усе зв’язує.

Дві ключові таблиці: повідомлення та контакти

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

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

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

По‑друге, role. Це поле фіксує, хто є автором повідомлення — користувач чи асистент. Такий поділ потрібен і для побудови промптів до Claude, і для візуалізації в інтерфейсі. AI‑моделі зазвичай очікують структуру діалогу у форматі «user / assistant», тож збереження ролі в базі напряму впливає на якість інтеграції з API.

По‑третє, content. Тут зберігається текст листа — як вхідного, так і згенерованої відповіді. Це основний масив даних, який потім може використовуватися для аналізу, повторного навчання промптів або просто для перегляду історії.

Нарешті, created_at. Часова мітка дозволяє впорядковувати повідомлення хронологічно. Для email‑системи це не лише зручність, а й функціональна необхідність: AI‑моделі мають отримувати контекст у правильному порядку, а дашборд — показувати розмови так, як вони реально відбувалися.

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

Основою є email — унікальний ідентифікатор контакту. До нього додається необов’язкове поле display_name, яке дозволяє зберігати ім’я, якщо воно доступне з вхідного листа або форми.

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

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

Разом ці дві таблиці формують мінімальний, але достатній каркас: contacts відповідає за «хто», messages — за «що і коли». Усе інше — AI‑відповіді, розсилки, дашборд — будується поверх цієї структури.

Drizzle Kit і автоматичні оновлення схеми

Щоб схема бази даних не розходилася з кодом, у проєкті використовується Drizzle Kit — інструмент для керування схемою та міграціями. Його конфігурація зосереджена в файлі drizzle.config.ts, де задається шлях до схеми (lib/db.ts) і файл бази (emails.db).

Ключова ідея полягає в тому, щоб зробити оновлення схеми частиною стандартного циклу розробки. Для цього в package.json змінено стандартні скрипти. Додано окрему команду db:push, яка запускає drizzle-kit push. Ця команда аналізує визначення таблиць у lib/db.ts і застосовує відповідні зміни до реальної бази.

Далі db:push вбудовано в основні сценарії запуску. Скрипт dev тепер виглядає як npm run db:push && next dev. Це означає, що перед стартом дев‑сервера Next.js схема бази автоматично синхронізується. Аналогічно, скрипт build запускає npm run db:push && next build, тож перед продакшн‑збіркою база також оновлюється.

Такий підхід знімає одразу кілька ризиків. По‑перше, зменшується ймовірність того, що розробник забуде прогнати міграції й отримає помилки на рівні запитів. По‑друге, спрощується онбординг: достатньо запустити npm run dev, і проєкт сам подбає про структуру бази. По‑третє, Drizzle Kit стає єдиним механізмом змін схеми, що дисциплінує роботу з даними.

У поєднанні з типобезпекою Drizzle ORM це створює досить надійний бекенд‑шар навіть для тих, хто не є фахівцем з SQL. Схема описується в TypeScript, синхронізується автоматично, а запити до бази виглядають як звичайні функції з чіткими типами.

Інтеграція з Claude і Postmark: як AI‑відповіді потрапляють у базу

Хоча база даних і ORM — це фундамент, головна «родзинка» проєкту — AI‑логіка. Для генерації відповідей використовується Anthropic Claude через офіційний SDK @anthropic-ai/sdk. Цей пакет встановлюється разом з іншими ключовими залежностями: better-sqlite3, drizzle-orm, drizzle-kit, @types/better-sqlite3 і postmark.

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

POSTMARK_SERVER_TOKEN — це ключ доступу до Postmark, який береться з дашборда сервісу в розділі Servers → API tokens. У туторіалі використовується сервер у live‑режимі, а не sandbox, що дозволяє працювати з реальними листами. SENDER_EMAIL визначає адресу, з якої асистент надсилає відповіді та вітальні листи.

POSTMARK_WELCOME_TEMPLATE_ALIAS вказує на alias шаблону вітального листа в Postmark. У прикладі використовується значення welcome. Це дозволяє бекенду, отримавши нового контакта, просто викликати відправку шаблонного листа за alias, не збираючи HTML вручну.

ANTHROPIC_API_KEY забезпечує доступ до Claude. Через @anthropic-ai/sdk бекенд формує запит до моделі, передаючи історію діалогу з таблиці messages. Тут особливо важливі поля thread_id, role і content. Вони дозволяють відновити контекст розмови у форматі, який очікує API: послідовність повідомлень користувача й асистента.

Типовий цикл виглядає так. На бекенд надходить вхідний лист через вебхук Postmark. Система визначає контакт за email, створює або оновлює запис у таблиці contacts, за потреби перевіряє welcome_sent_at і надсилає вітальний лист, якщо це перша взаємодія. Потім створюється запис у messages з роллю «user», текстом листа й відповідним thread_id.

Далі бекенд звертається до Claude через SDK, передаючи історію повідомлень цього треду з бази, відсортовану за created_at. Модель генерує відповідь, яку система зберігає як новий запис у messages з роллю «assistant». Після цього через Postmark формується вихідний лист від SENDER_EMAIL до контакту, а контент відповіді береться з щойно збереженого запису.

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

Чому така архітектура добре масштабується для невеликих AI‑сервісів

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

По‑перше, використання SQLite з better-sqlite3 і Drizzle ORM дає простий шлях до продакшн‑готового зберігання без окремого керування сервером бази. Файл emails.db можна тримати на тому ж VPS, де працює Next.js‑додаток, а Drizzle Kit бере на себе синхронізацію схеми.

По‑друге, чітке розділення на messages і contacts дозволяє легко розширювати функціональність. Наприклад, можна додати нові поля до контактів для сегментації розсилок або нові атрибути до повідомлень для маркування типів запитів. Завдяки Drizzle такі зміни проходять через єдину точку — файл схеми — і автоматично застосовуються до бази через db:push.

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

Нарешті, автоматичне виконання db:push перед next dev і next build зменшує кількість ручних кроків і потенційних помилок. Для невеликих команд або соло‑розробників це особливо важливо: менше рутинних дій — менше шансів зламати продакшн через забуту міграцію.

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

Висновок

AI‑email‑асистент із туторіалу Tech With Tim — це не лише демонстрація можливостей Claude і Postmark, а й приклад того, як побудувати акуратний бекенд навколо простих, але продуманих рішень. SQLite з better-sqlite3, Drizzle ORM і Drizzle Kit забезпечують надійне збереження контактів і історії листування, а інтеграція з Anthropic Claude через офіційний SDK перетворює ці дані на живий діалог.

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

Джерело

https://www.youtube.com/watch?v=8FBGb0NS_zc

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

Підключення до джерела даних: без ручного копіювання

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

Ключові моменти:

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

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

«Навчання» агента: навички та стандарти команди

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

Один із запропонованих елементів — skill для розрахунку метрик (metrics calculation skill). Він виконує кілька функцій:

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

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

Автоматичний запуск: щотижневий ритм без нагадувань

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

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

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

Прозорість роботи: історія активності та контроль кроків

Ще один важливий елемент — видимість того, що робить агент. Для цього використовується історія активності:

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

Типовий сценарій роботи виглядає так:

1. Агент відкриває таблицю з даними на Google Drive.
2. Запускає код для розрахунку метрик.
3. Створює графіки на основі цих метрик.
4. Формує узагальнений текстовий звіт (readout), який можна одразу ділити з командою.

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

Джерело

Weekly metrics reporting agent — OpenAI на YouTube

Коли інфраструктурний дослідник і автор «Designing Data‑Intensive Applications» Мартін Клеппманн опинився в LinkedIn після продажу свого стартапу Rapportive, його продуктова команда з часом була розформована. Замість того, щоб шукати новий продукт усередині корпорації, він перейшов у стримінгову команду — до ядра інфраструктури, яка тоді тільки формувалася навколо Apache Kafka та фреймворку Samza. Саме цей перехід — від продуктового інженірингу до фундаментальних систем — став одним із ключових досвідів, що згодом лягли в основу першого видання його книжки про дата‑інтенсивні застосунки.

Kafka щойно була відкритою: LinkedIn тільки що вивів її в open source, і команда займалася тим, щоб перетворити внутрішній інструмент на універсальну платформу для потокової обробки даних. Паралельно Клеппманн, уже працюючи віддалено з Великої Британії, отримав від LinkedIn можливість витрачати приблизно половину свого часу на написання «Designing Data‑Intensive Applications» — рідкісний випадок, коли промислова інфраструктурна робота та глибока теоретична книга розвивалися практично синхронно.

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

Rapportive, другий стартап Клеппманна, інтегрував соціальні профілі в Gmail через браузерне розширення. Після придбання LinkedIn невелика команда з п’яти людей деякий час працювала як напівнезалежний продукт усередині корпорації, а згодом запустила новий сервіс LinkedIn Intro. Попри те, що компанія дала команді велику свободу, продукт швидко закрили, а саму команду розпустили.

Для багатьох інженерів це означало б пошук іншої продуктової ролі. Клеппманн пішов іншим шляхом: він приєднався до стримінгової групи LinkedIn, яка займалася Kafka та побудовою системи потокової обробки даних. Це був різкий зсув фокусу — від Ruby on Rails, PostgreSQL і Redis, на яких працював Rapportive, до низькорівневої інфраструктури, що мала забезпечити роботу всієї соціальної мережі.

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

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

Kafka як append‑only log: інтеграція даних замість зоопарку ETL

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

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

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

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

Ключовим було саме append‑only представлення. Події не перезаписувалися, а лише додавалися в кінець журналу. Це дозволяло:

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

по‑друге, підключати нові споживачі заднім числом, не втрачаючи історичних даних;

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

Саме така інтерпретація Kafka як журналу подій, а не просто черги, стала одним із центральних концептів, які згодом потрапили в «Designing Data‑Intensive Applications».

Від Kafka до Samza: як будувалися stateful стримінгові пайплайни

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

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

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

У LinkedIn така стримінгова інфраструктура живила не лише онлайн‑функціональність, а й аналітичні та ML‑навантаження. Kafka слугувала джерелом даних для дацаверхаузу та Hadoop‑кластерів, на яких будувалися моделі машинного навчання й аналітичні звіти. Події, що проходили через Kafka, потрапляли в Hadoop для глибокої офлайн‑обробки, а результати могли повертатися в онлайн‑сервіси, знову ж таки через стримінгові канали.

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

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

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

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

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

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

Клеппманн пропонує дивитися на це як на баланс між:

ризиком недоступності, який ви готові прийняти;

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

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

У випадку Kafka та Samza на масштабі LinkedIn це означало, що питання «чи робити multi‑region?» не могло мати універсальної відповіді. Для одних потоків подій, критичних до доступності, складніша, географічно розподілена архітектура могла бути виправданою. Для інших — простіший, але менш захищений варіант виявлявся раціональнішим, якщо враховувати повну вартість володіння, включно з людським фактором.

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

Хмара, стримінг і зміна парадигми масштабування

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

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

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

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

Ця модель сьогодні здається майже очевидною для великих технологічних компаній, але на момент, коли Клеппманн працював у стримінговій команді LinkedIn, вона ще тільки кристалізувалася. Саме тому його участь у розвитку Kafka та Samza на ранньому етапі виявилася настільки впливовою для формування загальної картини сучасних дата‑інтенсивних систем.

Книга, що писалася разом із інфраструктурою

Особливість історії Клеппманна полягає в тому, що «Designing Data‑Intensive Applications» не була написана «після» практичного досвіду — вона створювалася паралельно з роботою над реальною інфраструктурою LinkedIn. Компанія дозволила йому офіційно витрачати близько 50% робочого часу на книгу, поки решту він присвячував Kafka, Samza та стримінговим пайплайнам.

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

Пізніше, у другому, суттєво оновленому виданні, яке вийшло приблизно через дев’ять років після першого, частина старих технологій, на кшталт MapReduce, зникла з фокусу, натомість з’явилося більше матеріалу про системи, що підтримують AI‑навантаження, включно з векторними індексами. Але фундаментальна ідея — розглядати дані як потоки подій, а інфраструктуру як набір компромісів між надійністю, продуктивністю та складністю — залишилася незмінною. І саме досвід роботи з Kafka та Samza в LinkedIn багато в чому сформував цю оптику.

Висновок: стримінг як норма і ціна складності

Історія переходу Мартіна Клеппманна з продуктового інженірингу в Rapportive до інфраструктурної ролі в стримінговій команді LinkedIn показує, як швидко змінилася парадигма роботи з даними за останнє десятиліття. Kafka, що починалася як внутрішній журнал подій, перетворилася на центральну нервову систему даних, яка живить як онлайн‑сервіси, так і аналітику та машинне навчання. Samza дав модель stateful обробки в реальному часі, побудовану поверх цього журналу.

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

Те, що LinkedIn дозволив Клеппманну поєднати роботу над цією інфраструктурою з написанням «Designing Data‑Intensive Applications», зробило книгу унікальною: вона стала не лише описом того, як «має бути», а й рефлексією над тим, як великі системи насправді будуються, ламаються й еволюціонують у світі хмари та стримінгу. І саме тому сьогодні, коли Kafka‑подібні журнали подій і стримінгові пайплайни стали нормою для компаній, що працюють на хмарному масштабі, ці ідеї залишаються актуальними — як нагадування про те, що за кожною додатковою дев’яткою доступності стоїть не лише новий кластер, а й додатковий шар людської та технічної складності.

Джерело

Designing Data-intensive Applications with Martin Kleppmann — The Pragmatic Engineer

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

Навіщо бізнесу агент для third‑party risk management

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

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

Як налаштовується агент Trove

Створення агента починається з промпту, який описує:

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

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

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

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

Інтерфейс побудови поділено на дві частини:

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

Прев’ю, трасування та контроль поведінки

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

Ключовий елемент — моніторинг виконання:

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

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

Від збору доказів до готового звіту

У робочому режимі агент виконує повний цикл third‑party risk management:

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

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

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

Джерело

Відео: Third-party risk management agent — OpenAI

У подкасті Security Intelligence від IBM Technology креативна директорка IBM X‑Force Cyber Range Клер Нуньєс, віцепрезидент з глобального управління кіберзагрозами Дейв Маꥳнніс та інженерка з виявлення загроз Кіммі Фаррінгтон обговорюють, як агентні системи на кшталт OpenClaw змінюють саму природу кібербезпеки. На тлі експерименту Sophos з OpenClaw як пен‑тестером розмова швидко переходить до більш тривожної теми: що відбувається, коли такі агенти починають жити всередині корпоративної інфраструктури як майже повноцінні «інсайдери» — і як безпека має навчитися ними керувати.

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

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

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

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

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

Привілейований агент на кінцевій точці: чому OpenClaw важко зупинити

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

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

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

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

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

AI‑агенти як новий периметр: розширена площа атаки всередині організації

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

Ці агенти:

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

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

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

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

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

Людина в контурі: чому повністю автономні агенти поки що небезпечні

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

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

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

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

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

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

Чому саме безпека має очолити впровадження AI‑агентів

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

Є кілька причин.

По‑перше, безпекові команди вже давно живуть у режимі перевантаження даними. Системи моніторингу, журналювання, SIEM‑платформи генерують більше подій, ніж люди здатні опрацювати вручну. Автоматизація аналізу патернів, кореляція сигналів, пріоритизація інцидентів — це саме ті задачі, де AI може принести реальну, відчутну користь.

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

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

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

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

Висновок: від «нічного жаху» до керованого інструмента

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

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

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

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

Джерело

Security Intelligence Podcast – Should you let OpenClaw pen test your system? Plus: Cybersecurity for ephemeral software