Четвер, 25 Червня, 2026
Додому Блог

Ексголова Infosys запускає AI‑стартап для ринку IT‑послуг

0

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

Ексголова Infosys запускає AI‑стартап для ринку IT‑послуг

Його новий стартап Hang Ten Systems залучив посівні інвестиції у розмірі 32 млн доларів у раунді під проводом фонду Mayfield, про що компанія повідомила в середу. У раунді також узяв участь стратегічний інвестор Aramco Ventures та низка бізнес‑ангелів. Стартап, до ради директорів якого входить співзасновник Yahoo Джеррі Ян, заявляє, що допомагає підприємствам безперервно створювати, змінювати та експлуатувати програмне забезпечення завдяки ШІ‑керованій розробці та автоматизації.

Hang Ten виходить на ринок, де гравці на кшталт Infosys уже намагаються адаптуватися до епохи ШІ через партнерства з компаніями на кшталт Anthropic та OpenAI.

Запуск стартапу відбувається на тлі дискусій про те, чи розширить ШІ сукупний адресний ринок для індустрії IT‑послуг, чи радикально змінить спосіб створення, підтримки та доставки корпоративного ПЗ.

Очевидно, що частина корпоративних клієнтів готова випробувати модель «ШІ‑послуг», особливо від такого досвідченого гравця, як Сікка, який 12 років займався розробкою корпоративного ПЗ у SAP, а пізніше входив до ради директорів Oracle. Керівний партнер Mayfield Навін Чаддха розповів TechCrunch, що компанія «фактично стартувала лише місяць тому», але вже має клієнтів.

Стартап повідомив, що працює з такими замовниками, як Siemens Gamesa Renewable Energy та Fresenius, над проєктами з «AI‑native» підходом до доставки рішень. У окремому дописі в блозі, де було анонсовано нову компанію, Сікка, якому нині 59 років, написав, що Hang Ten уже допомагає великим підприємствам «осідлати найбільшу хвилю нашого життя».

Штаб‑квартира Hang Ten розташована в Сан‑Франциско-Бей‑аріа. У коментарі для TechCrunch компанія зазначила, що активно наймає фахівців у напрямах доставки рішень, інженерії, продажів та менеджменту й планує розширювати присутність у кількох регіонах світу, аби задовольнити попит з боку великих підприємств.

До ранньої команди стартапу входять топменеджери, які роками працювали із Сіккою в SAP, Infosys та його попередньому AI‑стартапі для підприємств VianAI, про що свідчать їхні профілі в LinkedIn. Серед них — співзасновники Навін Будхіраджа, технічний директор (CTO) Hang Ten, Санджай Раджагопалан, директор з дизайну, та Тао Лю, старший віцепрезидент із forward deployed engineering.

Після відставки з посади гендиректора Infosys у 2017 році Сікка заснував VianAI. Компанія вийшла з режиму stealth у 2019‑му, залучивши 50 млн доларів посівного фінансування, а у 2021 році отримала ще 140 млн доларів у раунді під проводом SoftBank Vision Fund 2.

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

У Mayfield підтримали Hang Ten завдяки досвіду Сікки та переконанню, що «AI‑native» модель стартапу масштабуватиметься інакше, ніж традиційні сервісні компанії.

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

Hang Ten з’являється на ринку в момент, коли інвестори активно обговорюють, як ШІ вплине на економіку індустрії IT‑послуг. Аналітики Jefferies раніше цього року стверджували, що саме IT‑послуги можуть стати одним із перших секторів, які зазнають суттєвого зсуву під впливом ШІ. Водночас голова ради директорів Infosys Нандан Нілкані цього тижня заявив, що штучний інтелект може навпаки розширити ринок для галузі.

Джерело

TechCrunch

Тисячі Mac від Apple стають гарбузами: macOS 27 прощається з Intel

0

Чергова Всесвітня конференція розробників Apple 2026 року, як завжди, принесла “дивовижні новини” для відданих шанувальників. Серед анонсів “Apple Intelligence” та “Siri AI” представили macOS 27 Golden Gate, що обіцяє низку “нових функцій та покращень”. Однак, доступ до цього оновлення отримають не всі пристрої, тому власникам комп’ютерів Apple слід з’ясувати, чи їхній Mac взагалі потрапив до списку “гідних” для подальшої підтримки.

Компанія Apple вже, по суті, припинила активну підтримку більшості Mac із процесорами Intel ще у 2025 році з виходом macOS 26 Tahoe. Тоді останніми “щасливчиками” стали 16-дюймовий MacBook Pro 2019 року, 13-дюймовий MacBook Pro 2020 року, Mac Pro 2019 року та 27-дюймовий iMac 2020 року. Тепер, із запуском macOS 27 Golden Gate, жоден з цих пристроїв оновлення також не отримує, що цілком очікувано.

Отже, з цього випливає, що тільки Mac, випущені з 2020 року та оснащені фірмовими чіпами M-серії, отримають оновлення до macOS 27. До цього списку належать різні моделі MacBook Air, MacBook Pro, iMac, Mac mini, Mac Studio, Mac Pro, а також найновіший MacBook Neo з чіпом A18 Pro. По суті, компанія повністю перейшла на підтримку власної архітектури, зобов’язуючи користувачів міняти “застаріле” обладнання.

Що ж тепер очікує на власників Mac із процесорами Intel? Хоча Apple і відмовилася від основних оновлень операційної системи, це не означає миттєвої “смерті” пристроїв. Компанія дотримується політики, за якою кожна версія ОС отримує оновлення безпеки протягом трьох років після випуску. Отже, власники Intel-базованих комп’ютерів, що працюють на macOS 26, можуть розраховувати на певні оновлення безпеки приблизно до 2029 року.

Ще одне важливе питання – сумісність програм для Intel-процесорів (архітектура x86). Apple оголосила, що macOS 27 Golden Gate буде останньою версією з Rosetta 2, інструментом для запуску Intel-коду на власних чіпах. Отже, якщо на macOS 27 старі програми ще працюватимуть, то з виходом macOS 28 ця функція зникне зовсім. Це створить неабиякі проблеми для користувачів, які покладаються на застаріле програмне забезпечення.

Такий стан справ “стимулює” розробників переходити на архітектуру Apple Silicon, що, згідно з обіцянками, має покращити продуктивність програм. Проте, це створює значну проблему для тисяч старих програм та ігор, які вже не оновлюються і, відповідно, не будуть адаптовані під нові вимоги. Хоча Apple нібито пропонує “полегшення”, обіцяючи зберегти функціональність Rosetta для “старих ігор” у майбутніх оновленнях, паралельно заявляється, що ця ж функція не працюватиме з більшістю Intel-програм, які все ще активно оновлюються. Це породжує багато питань.

Rockstar Games продає GTA VI за 79.99 доларів без диска в коробці

0

Компанія Rockstar Games офіційно оголосила вартість майбутньої гри Grand Theft Auto VI, яка надійде у продаж 19 листопада за ціною 79.99 доларів. Дивним маркетинговим рішенням стало вилучення фізичного носія із коробки з грою, замінивши його звичайним кодом для завантаження. Це створює небезпечний для всієї індустрії розваг прецедент, адже відсутність диска фактично позбавляє покупців права на реальну власність копією продукту, перетворюючи придбання гри на оренду ліцензії, яка будь-якої миті може перестати працювати.

Статистика невблаганно свідчить на користь цифрового формату, оскільки видавці постійно звітують про падіння попиту на фізичні носії. Наприклад, компанія Capcom нещодавно оприлюднила звіт, згідно з яким у минулому фінансовому році 93 відсотки всіх продажів ігор припали саме на цифрові версії. Одночасно виробники ігрових консолей, зокрема PlayStation Pro, Xbox Series S та різні модифікації Steam Machine, вже випускають обладнання без дисководів, фактично примушуючи споживачів відмовлятися від дисків на користь завантажень із віддалених серверів.

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

Існують припущення, що Rockstar Games вдалася до такого кроку задля мінімізації витоків інформації, намагаючись синхронізувати час запуску гри для всіх користувачів одночасно. Також цілком імовірною є технічна причина, пов’язана з катастрофічно великим обсягом файлів GTA VI, який просто не вміщується на стандартні оптичні диски сучасних консолей. Подібну модель коду в коробці раніше практикували Bethesda з Fallout 4 та Skyrim, проте тепер цей підхід масштабується на головний проект індустрії.

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

Європа опирається чіповій війні Вашингтона

0

Міністр зовнішньої торгівлі Нідерландів Сьйорд Сьйордсма цього тижня відвідав Вашингтон, щоб зустрітися з міністром торгівлі США Говардом Латніком та членами Конгресу й виступити проти законопроєкту MATCH. Цей документ має заборонити китайським виробникам мікросхем доступ до західного обладнання для виробництва напівпровідників і особливо сильно вдарив би по компанії ASML.

Європа опирається чіповій війні Вашингтона

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

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

На Китай припадає 19% чистих продажів систем ASML. Законопроєкт MATCH пішов би далі за чинні експортні обмеження, поширивши заборони на іммерсійні машини глибокого ультрафіолету (DUV) ASML, на додаток до давньої заборони на постачання до Китаю її найбільш передових інструментів на основі екстремального ультрафіолету (EUV).

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

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

Джерело

TechCrunch

AI й ерозія навичок: чому зусилля стає головною відмінністю

0

У розмові на подкасті The Pragmatic Engineer творець платформи підготовки до техспівбесід NeetCode (Навдіп Сінгх) виходить далеко за межі алгоритмів. Він говорить про те, як масове «промптнути все» змінює інженерію, чому з’являється покоління девелоперів, які буквально «завмирають» без Copilot, і чому був готовий записати ролик із заголовком «деяким людям варто здатися з кар’єрою в техніці» — хоча насправді він не про відбір «геніїв», а про ставлення до зусиль.

Коли «навчання через LLM» перестає бути навчанням

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

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

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

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

Інженери, які розучилися писати код без Copilot

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

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

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

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

Культура «просто промптити» й чому «деяким варто здатися» — це про ставлення

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

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

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

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

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

Ефект AI: навички дешевшають, зусилля дорожчає

Через кілька років після появи Copilot-подібних інструментів і LLM-кодерів Сінгх бачить чітку асиметрію: «Будувати стало нескінченно простіше, але створювати цінність — відчутно важче».

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

Сам NeetCode демонструє гранично прагматичний підхід. Він розповідає про власний сервіс виконання коду, який замінив дорогий SaaS: за допомогою «vibe coding» із LLM він написав аналог за два–три дні, скоротивши щомісячні витрати з кількох тисяч до кількох сотень. У новій системі є продакшн-баг — імовірний memory leak, що час від часу валить окремі інстанси. Він чудово розуміє, що це технічно неправильно, але свідомо не витрачає тижні на пошук кореня проблеми: для користувачів сервіс працює стабільно, аварії автоматично перекриваються резервними інстансами, бізнес-цінність не страждає.

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

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

«Я не за те, щоб люди здавалися» — що означає «рефокус на навчанні»

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

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

людина визнає, що AI розмиває ручні навички — і свідомо тренує їх там, де це має сенс (наприклад, у підготовці до інтерв’ю чи в критичних частинах системи);

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

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

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

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

Висновок: те, чого не можна промптнути

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

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

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


Джерело

Подкаст The Pragmatic Engineer — епізод «Tech interviews with NeetCode»
YouTube: https://www.youtube.com/watch?v=xafwfGVBxos

Чому алгоритмічні співбесіди живуть, навіть коли всі вже «промптять»

0

Навдіп Сінгх, відомий як NeetCode, побудував один із найпопулярніших сервісів для підготовки до технічних співбесід — NeetCode.io. До цього він працював інженером в Amazon і Google, проводив і проходив класичні DSA‑співбесіди, а зараз спостерігає, як на ринок одночасно обрушились AI‑інструменти, віддалений формат і масові «чітинг‑ тулзи». Попри це, каже він, саме формат алгоритмічних інтерв’ю дивним чином залишається стабільним — і це багато що говорить про те, як індустрія реально вміє (і не вміє) оцінювати інженерів.

Формат, який «не вмирає»: чому DSA‑інтерв’ю такі липкі

Парадокс починається з очевидного контрасту. На буденній роботі, за його спостереженнями, «більшість інженерів уже не пишуть код, вони промптять». З’явився клас інструментів, з якими «ми дійшли до точки, де ти можеш спитати AI‑бота будь‑що про кодову базу, і він дасть доволі хорошу відповідь… можна попросити реалізувати фічу, зробити майже що завгодно — це може дістатися хоча б на 90% шляху, навіть якщо не на 100%».

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

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

DSA ніколи не були тестом «чи вмієш ти робити цю роботу»

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

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

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

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

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

Компанії не вміють оцінювати інженерів — і, можливо, ніколи не вміли

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

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

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

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

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

AI в інтерв’ю: Meta експериментує, Google закручує гайки

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

Тепер маятник починає хитатися назад. NeetCode відзначає: «Google pretty much gone to on‑sites at this point… it’s going to be in person and somebody’s going to be watching you code». Тобто повернення до класики: дошка або ноутбук, інтерв’юер у кімнаті, мінімум шансів підглянути в інший екран.

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

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

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

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

Гейміфікація неминуча — але є один формат, який важко зламати

Ще одна теза NeetCode звучить майже як закон природи: «Будь-який процес, що стандартизований і скейлиться, завжди можна «загеймити»». Неважливо, чи це LeetCode‑френдлі алгоритмічний гриль, чи модна нова система з AI‑підказками й поведінковими питаннями — як тільки формат стає масово застосовним, з’являються курси, гайди, тулзи й тактики, які навчають «як пройти, не розуміючи по суті».

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

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

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

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

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

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

У підсумку ландшафт виглядає суперечливо:

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

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

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

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

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

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


Джерело

YouTube: Tech interviews with NeetCode

Security Harness: як IBM та OpenAI випробовують код проти frontier‑загроз

0

IBM продовжує обережно, але цілеспрямовано заводити найпотужніші мовні моделі у консервативний світ корпоративної безпеки. У подкасті Security Intelligence на каналі IBM Technology лідер напряму application security сервісів IBM Джайєш Камат розповів про нове партнерство з OpenAI в межах програми Daybreak Cyber Partner Program і про сервіс Security Harness. Йдеться не про ще один «сканер вразливостей», а про обв’язку для frontier‑LLM, яка дає змогу моделі поводитися як висококваліфікований ресерчер, але в контрольованих, аудитованих межах великого підприємства.

Спільний вихід до клієнтів: що пообіцяли IBM та OpenAI

Партнерство в межах OpenAI Daybreak, за словами Камата, будується навколо дуже конкретної цілі: спільної роботи з клієнтами над безпекою застосунків у добу frontier‑AI.

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

Таким чином, OpenAI приносить моделі, які швидко еволюціонують і належать до класу frontier, а IBM — методики, сервіси та консалтинг у сфері корпоративної безпеки. Формат — це не просто інтеграція API, а спільний вихід до замовників: ко‑креація, ранні «альфа»‑проєкти, спільний go‑to‑market.

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

Security Harness: керований «контейнер» для потужності LLM

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

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

Security Harness, за його словами, виконує одразу кілька функцій.

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

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

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

Довести експлуатацію — але зробити це безпечно

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

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

У практичному вимірі це означає кілька речей.

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

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

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

Frontier‑моделі як «супердослідники» у кодовій базі

Одна з найсильніших оцінок, яку дає Камат, стосується ролі frontier‑LLM у роботі, яку раніше виконували люди-експерти. Він говорить про «здатність AI‑моделі робити роботу, яку традиційно виконував би спеціаліст із безпеки», і називає це «величезним стрибком».

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

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

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

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

«Краще з двох світів»: де сходяться моделі та консалтинг

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

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

Тут закладена важлива теза: frontier‑LLM самі по собі не розв’язують проблему безпеки коду. Потрібна обв’язка, яка зробить їх придатними для суворих корпоративних реалій — із аудитом, трасованістю, врахуванням політик доступу та особливостей кожного середовища. Security Harness у моделі IBM — це пряма відповідь саме на цей розрив між «сировою» потужністю моделі й реальними вимогами ринку.

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

Що це означає для ринку application security

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

По‑перше, frontier‑LLM усе більше позиціюються як інструменти не лише для розробки, а й для автономного пошуку та підтвердження вразливостей. Ідея: модель проводить ту ж ментальну роботу, що й дослідник-людина, але з іншим масштабом і швидкістю.

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

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

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

Висновок

Security Harness у партнерстві IBM та OpenAI — показовий приклад того, як frontier‑LLM поступово інтегруються у практики корпоративної безпеки не як «чарівна паличка», а як керований, контрольований інструмент. Обв’язка дає змогу моделі мислити як дослідник, виявляти та ланцюжити вразливості, доводити експлуатаційність — але в рамках, які відповідають вимогам журналювання, аудиту й трасованості.

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


Джерело

Security Intelligence — Have we finally solved social engineering? Plus: World Cup fraud, AI IDs and an IBM/OpenAI collab

Ідентичності для AI‑агентів: естонський експеримент і межі сучасного IAM

0

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

У подкасті IBM Security Intelligence цю ідею розбирають технічний директор з безпеки IBM Research JR Rao, консультант з кібербезпеки Dave Bales та інженерка з детекції загроз Kimmie Farrington. За їхніми оцінками, естонська ініціатива виглядає логічним, навіть неминучим кроком — але таким, що впирається у фундаментальні обмеження сучасних систем керування ідентичностями.


Навіщо AI‑агентам власні ID

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

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

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

Звідси і дві основні переваги окремого ID для агента:

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

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


5 мільйонів агентів: чому масштаб ламає IAM

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

Rao нагадує, що сьогодні у великих підприємствах зазвичай йдеться про десятки тисяч співробітників — він називає цифри 50 000 або 100 000 людей. Сучасні системи керування ідентичностями та доступом (IAM) проєктувалися саме під такий порядок величин.

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

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

Виникає низка практичних питань:

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

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


Що таке «агентна» ідентичність

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

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

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

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

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


Ефемерні агенти та «директрія» майбутнього

Ситуацію додатково ускладнює те, що не всі агенти однакові за життєвим циклом і значенням.

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

Це породжує питання:

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

Farrington схиляється до технічної моделі, що нагадує поєднання каталогу на кшталт Active Directory із короткоживучими токенами, близькими до Kerberos. За такої схеми агент при створенні отримує обмежений у часі токен, який діє лише стільки, скільки потрібно для конкретного завдання, а потім перестає існувати.

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

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


Коли сам агент стає вразливістю

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

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

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

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

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

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

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


Чи справді Естонія «на правильному шляху»

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

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

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

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


Висновок: ідентичність — необхідна, але недостатня умова

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

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

Проблему посилює триєдина реальність:

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

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


Джерело

Обговорення базується на подкасті IBM Security Intelligence:
https://www.youtube.com/watch?v=10XtOi4Lbes

Світовий футбол як глобальний attack surface: розбір Operation FanTrap

0

Чемпіонат світу з футболу — це не лише мільярди глядачів і національні драми, а й ідеальний ґрунт для масових кібершахрайств. У подкасті IBM Security Intelligence ведучий Метт Кузінскі разом із експертами з безпеки Дейвом Бейлзом, Кіммі Фаррінгтон та JR Рао розбирають дослідження Cyble Research and Intelligence Labs під кодовою назвою Operation FanTrap. Воно демонструє, як навколо World Cup виростає повноцінна індустрія фроду, що працює за тими ж принципами, що й сучасний маркетинг, але з кримінальною метою.

4 000 шкідливих доменів: індустрія, а не одиничні махінації

Cyble в рамках Operation FanTrap зафіксувала майже 4 000 шкідливих доменів, які використовують бренд Чемпіонату світу, щоб розповсюджувати шкідливе ПЗ, красти гроші, перехоплювати облікові дані та здійснювати інші атаки.

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

Користувач уявляє, що отримає:

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

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

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

World Cup як глобальний attack surface

Рао пропонує формулу, яка добре описує природу проблеми: Чемпіонат світу — це не лише глобальна спортивна подія, а й глобальний attack surface.

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

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

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

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

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

Технічна відповідь: заглядати всередину браузера

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

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

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

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

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

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

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

Серед базових поведінкових орієнтирів, які він виділяє:

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

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

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

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

Ослаблення пильності як спільний знаменник

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

Масові події зразка World Cup лише різко підсилюють загальний фон: шквал рекламних повідомлень, інформаційний шум, FOMO, гонитва за «останнім шансом». На цьому тлі шахрайські домени й листи виглядають як частина загального потоку, і відокремити їх стає дедалі складніше.

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

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


Джерело

Подкаст Security Intelligence, IBM Technology — «Have we finally solved social engineering? Plus: World Cup fraud, AI IDs and an IBM/OpenAI collab»
https://www.youtube.com/watch?v=10XtOi4Lbes

TSMC “стратегічно” підвищує ціни на 74% своїх чипів, роблячи гаджети дорожчими

0

За повідомленнями галузевих джерел, компанія TSMC, що виробляє значну частину мікросхем для сучасної електроніки, планує чергове підвищення цін на свою продукцію. Цей крок, нібито, стосуватиметься “всіх передових технологічних вузлів”, що за оцінками становить близько 74% усього бізнесу компанії з виготовлення кремнієвих пластин. Такі відомі замовники, як Nvidia, AMD, Apple, Qualcomm, Broadcom та MediaTek, ймовірно, незабаром знову зіткнуться з вищими витратами на виробництво своїх чипів.

Точні масштаби такого підвищення залишаються дещо розмитими, адже цифри, як зазначається, відрізнятимуться залежно від замовника, конкретного технологічного процесу та категорії продукту. Однак, за загальними оцінками, вони, ймовірно, коливатимуться в межах від 5% до 10%. Вже є повідомлення, що для деяких клієнтів нові тарифи вже почали діяти, тоді як іншим партнерам TSMC було “люб’язно” запропоновано врахувати вищі витрати у своїх наступних замовленнях.

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

Початкові повідомлення від тайванських ЗМІ натякали переважно на підвищення цін для 3-нанометрового процесу TSMC, що є ключовою технологією для флагманських смартфонів, ПК та чипів для штучного інтелекту. Очікувався тиск і на новітнє 2-нанометрове виробництво. Проте, звіт Culpium “несподівано” розширює інформацію: TSMC нібито повідомила клієнтів про подорожчання “всіх передових вузлів”. Це означає, що підвищення виходить за межі 3-нм та 2-нм, охоплюючи також старіші, але все ще затребувані процеси, такі як 5-нм та 7-нм.

Згідно з фінансовими даними, лише 3-нанометровий процес вже приніс TSMC 25% доходу від кремнієвих пластин у першому кварталі 2026 року. При цьому весь портфель “передових вузлів” компанії – які TSMC сама визначає як технології 7-нанометрів та новіші – забезпечив аж 74% її доходу від пластин. Таким чином, це підвищення цін охопить майже три чверті всього бізнесу компанії з виробництва напівпровідників, що, безумовно, є суттєвим кроком для фінансових показників гіганта.

Включення 7-нанометрового процесу до списку підвищення цін є особливо “цікавим”, адже цей вузол вже не вважається флагманською технологією TSMC. Однак це не є цілковитою несподіванкою, адже 7-нм виробництво досі інтенсивно використовується у процесорах, прискорювачах, мережевому обладнанні та інших високопродуктивних чипах. Багато виробів залишаються на цих “старіших, але передових” вузлах завдяки їхній кращій вартості, стабільному виходу придатних чипів та загальній зрілості, що часто є ефективнішим рішенням, якщо дизайн не потребує надмірної щільності або енергоефективності 3-нм чи 2-нм процесів.

Ці клієнтські повідомлення “дивовижним чином” збіглися з кількома тижнями публічних коментарів керівництва TSMC, які “обережно натякали” на те, що підвищення цін розглядається. На щорічних зборах акціонерів 4 червня генеральний директор К.К. Вей згадав, що клієнти зберігають оптимізм щодо попиту на штучний інтелект, водночас вказуючи на зростання витрат та “очевидний” розрив між попитом на чипи та доступними виробничими потужностями. Фінансовий директор Венделл Хуан раніше також не виключав підвищення цін, посилаючись на інфляцію, розширення та зростання вартості передового виробництва.

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

Цей “своєчасний” крок відбувається саме тоді, коли TSMC отримує значну вигоду від буму попиту, пов’язаного зі штучним інтелектом. У своїх результатах за перший квартал компанія звітувала про 35.9 мільярдів доларів доходу та солідну валову прибутковість у 66.2%. Обидва показники “успішно” підтримувалися високим попитом на високопродуктивні обчислення та виробництво за передовими технологіями. TSMC також підвищила свій прогноз зростання доходу на 2026 рік до понад 30%, а її виробничі потужності в Аризоні, до речі, повністю розпродані до кінця 2027 року ще з початку 2025-го.

Заявлене підвищення цін, звісно, поки що значно менше, ніж нещодавні “стрибки” на ринку пам’яті, де попит на HBM та інші висококласні продукти, спричинений штучним інтелектом, дозволив постачальникам впровадити набагато крутіші збільшення. Проте TSMC, на відміну від виробників пам’яті, не потребує “астрономічних” цін для суттєвого покращення своєї прибутковості. Оскільки передові технологічні вузли складають більшу частину її доходу від кремнієвих пластин, навіть помірне підвищення на кілька відсотків у цьому сегменті може “легко” додати мільярди доларів до річного доходу, за умови збереження високого попиту.

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

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

Чи зможуть AI‑операційні системи зупинити соцінженерію

0

У подкасті Security Intelligence від IBM Technology ведучий Мет Кузінскі разом із експертами Дейвом Бейлсом, Кіммі Фаррінгтон та JR Рао розбирають провокаційну тезу з колонки на Dark Reading: чи здатні «AI‑нативні» операційні системи з вбудованими LLM‑агентами радикально зменшити, а можливо й припинити соціальну інженерію. Розмова швидко виходить за межі оптимістичних прогнозів і перетворюється на тверезий аналіз того, що саме штучний інтелект може змінити в атаках на людей — і які нові вектори нападу створює сам.

Чому проблема не в тому, що «люди занадто довірливі»

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

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

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

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

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

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

AI‑нативна ОС як «суперспам‑фільтр», що бачить усе

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

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

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

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

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

Від паролів до поведінки: як аутентифікацію може змінити AI

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

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

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

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

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

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

LLM як нова жертва соцінженерії

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

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

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

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

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

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

Людина в контурі чи поза ним: конфігурація майбутнього захисту

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

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

Тут важлива відмінність між «людиною в контурі» (human in the loop) і «на контурі» (on the loop). У першому випадку без участі людини рішення не ухвалюється; у другому — агенти діють автономно, але людина може втрутитися, контролювати та коригувати поведінку системи на вищому рівні.

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

Кінець соцінженерії чи її перезавантаження?

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

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

По‑друге, LLM‑агенти не є магічними щитами. «LLM настільки ж вразливі до інʼєкцій промптів… і, відповідно, до соціальної інженерії», — нагадує Кіммі. А JR прямо попереджає, що атакуватимуть не лише людей, а й «AI‑асистента, моделі довіри, системи памʼяті та інструкції агентів».

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

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

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


Джерело

YouTube: Have we finally solved social engineering? Plus: World Cup fraud, AI IDs and an IBM/OpenAI collab

Користувачі смартфонів Pixel з Android 17 втрачають керування екраном у ландшафтному режимі

0

Оновлення до версії Android 17 для смартфонів Google Pixel супроводжується технічними проблемами, які суттєво обмежують функціональність сенсорних дисплеїв під час відтворення відео у горизонтальній орієнтації. Згідно з повідомленнями користувачів на офіційних форумах та платформі Reddit, верхня частина екрана пристрою перестає адекватно реагувати на дотики, коли контент розгорнутий на весь екран. Ця помилка виникає під час використання стрімінгових сервісів, застосунку YouTube та стандартних мобільних браузерів, що фактично унеможливлює керування елементами інтерфейсу, які розміщені у верхній зоні дисплея.

Додаткові тести, проведені виданням 9to5Google на моделі Pixel 10 Pro XL, підтверджують факт існування проблеми, оскільки пристрій демонстрував аналогічну поведінку в різних застосунках, активованих у ландшафтному режимі. Хоча середина екрана зберігає чутливість до натискань, певні критичні опції, як-от перемикання субтитрів чи налаштування автоматичного відтворення, стають недоступними. Цікаво, що при цьому анімація шторки сповіщень все ще викликається звичним свайпом зверху вниз, що вказує на вибірковий характер програмного збою в новій системі Android 17, яка тільки починає поширюватися.

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

Окрім проблем із сенсорним введенням, власники Pixel стикаються з додатковими ускладненнями, пов’язаними з нестабільною роботою мережевих модулів після оновлення. Існують чисельні звіти, що певні системні додатки Google втрачають здатність коректно розпізнавати стабільні Wi-Fi підключення, змушуючи користувачів самостійно проводити маніпуляції з налаштуваннями IPv6 на домашніх маршрутизаторах. Уся ця ситуація виглядає як чергова спроба поспішного випуску програмного забезпечення, де інтеграція розрекламованого штучного інтелекту Gemini стає пріоритетнішою за стабільну базову роботу сенсорного інтерфейсу.

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

Екосистема Claude: як перетворити ШІ з чату на робочу платформу

0

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


Чотири основні продукти: думати, делегувати, будувати, створювати

Anthropic вибудувала Claude як набір окремих, але пов’язаних між собою робочих середовищ.

Chat: партнер для мислення

Базова точка входу — Claude Chat. Це класичний діалоговий інтерфейс, де ви ставите запитання, формулюєте завдання, обговорюєте ідеї, отримуєте відповіді, уточнюєте й ітеруєте.

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

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

Co‑work: делегування реальних завдань

Co‑work працює вже не в хмарі «десь там», а безпосередньо на вашому комп’ютері. Ви вказуєте папку, і це стає робочим простором для Claude.

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

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

Code: побудова інструментів без входу в IDE

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

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

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

Design: прототипи, слайди, лендинги без знання Figma

Четвертий продукт — Claude Design, який наразі виглядає дещо окремішнім, хоча інтегрований в екосистему. Доступний через сайдбар або за адресою claude.ai/design.

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

  • існуючого кодової бази;
  • Figma‑файлів;
  • бренд‑гайдів та візуальних активів.

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

Після завершення дизайну результат можна прямо передати в Claude Code для «доведення до продакшену».

У спрощеному вигляді ролі виглядають так:
Chat — для мислення;
Co‑work — для делегування;
Code — для побудови інструментів;
Design — для творчого оформлення.


Універсальний шар: навички, конектори й плагіни

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

Skills: повторювані «пакети експертизи»

Навички (skills) — це заздалегідь підготовлені інструкції, які Claude читає перед виконанням певного типу завдань, щоб відразу працювати послідовно та передбачувано.

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

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

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

Технічно навичка — це папка з інструкціями та гайдлайнами, які Claude читає першими. Але важливо, що її можна використовувати в усіх ядрових продуктах: і в Chat, і в Co‑work, і в Code.

Connectors: інтеграції з робочими інструментами

Конектори поєднують Claude з сервісами, якими користується команда:

  • Gmail, Slack, Google Drive, Asana;
  • та сотні інших SaaS‑рішень.

Через панель «підключити» користувач авторизується у своєму акаунті; після цього Claude може:

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

Управління правами доступу відбувається через простий список дозволів. Конектори так само універсальні: їх можна використовувати для запитів у Chat, для автоматизації в Co‑work або як частину кастомних інструментів у Code.

Plugins: готові зв’язки для ролей і ніш

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

Anthropic пропонує маркетплейс плагінів, де, зокрема, є:

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

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

Стисла ієрархія:
skills — повторювані завдання;
connectors — зв’язок із зовнішніми сервісами;
plugins — готові набори з обох попередніх для конкретних кейсів.


Пам’ять і контекст: проекти, облікова пам’ять і claude.md

Ще один шар екосистеми відповідає за довготривалу пам’ять і розуміння контексту — як у рамках одного проекту, так і на рівні облікового запису.

Projects: папки з власною поведінкою й контентом

Проекти — це не просто групи чатів за темами. Усередині кожного можна:

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

Таким чином Claude:

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

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

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

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

Account‑level memory: ШІ, який «знає вас»

Окрема пам’ять діє на рівні всього акаунта — для Claude Chat. Вона:

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

Це не спільний «універсальний» шар для всіх продуктів, а спосіб, щоб саме Chat поступово підлаштовувався під користувача.

claude.md у Code: бриф усередині репозиторію

У Claude Code пам’ять організована інакше. Тут використовується файл claude.md у межах проектної папки. Створюється він командою /init: Claude аналізує вміст папки й поточну розмову, генерує файл і надалі оновлює його в міру роботи.

Змістово це:

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

Деякі користувачі застосовують claude.md і в Co‑work‑проектах — як централізовану інструкцію, що лежить поряд з робочими файлами.

Якщо узагальнити:
projects фіксують контекст у межах завдання чи напрямку;
account memory навчає Chat стилю та вподобань користувача;
claude.md брифує Code/Co‑work по специфіці поточного проекту.


Автономний рівень: від керування ПК до розкладів і рутин

Останній шар екосистеми — можливість Claude діяти без постійної участі користувача.

Computer Use: керування десктопом

Функція Computer use дозволяє Claude брати під контроль робочий стіл:

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

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

Dispatch: контроль Co‑work зі смартфона

Dispatch дозволяє віддалено керувати сесією Co‑work із телефона:

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

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

Scheduled Tasks: регулярні завдання в Co‑work

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

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

Будь‑який регулярно ручний тригер тут може бути перенесений у розклад.

Code Routines: автоматизація без увімкненого ПК

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

  • промптів;
  • репозиторіїв;
  • конекторів.

Їх можна запускати автоматично:
– за розкладом;
– по подіях із GitHub;
– через API‑виклики.

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

Узагальнюючи автономний шар:
Computer use дає Claude змогу працювати з вашим десктопом;
Dispatch робить Co‑work дистанційно керованим;
Scheduled tasks автоматизують Co‑work за розкладом;
Code routines дозволяють Code запускатися подієво або за часом.


Підсумок: від чату до багатошарової робочої платформи

Екосистема Claude складається з чотирьох основних продуктів — Chat, Co‑work, Code і Design — та трьох ключових шарів поверх них:

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

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


Джерело

YouTube: Understand the FULL Claude Ecosystem in One Video

AI‑шортинґ під ключ: як поєднати Whisper, Claude та ImageKit у продакшн‑сервісі

0

Канадський розробник і ютубер Tech With Tim у новому великому розборі показує не теоретичну «демку», а реальний робочий кейс: побудову веб‑сервісу, який із довгого горизонтального відео автоматично генерує вертикальні шорти з рефреймінгом обличчя, субтитрами й стрімінговим відтворенням. На прикладі цього застосунку він поєднує три ключові компоненти — Whisper, Claude та ImageKit — і на практиці проходить через типові технічні вузькі місця сучасних AI‑відеостеків.

Що має вміти сучасний AI‑сервіс шортів

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

Йдеться не лише про вирізання фрагментів за таймкодами. Сервіс має:

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

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

Складна частина — не LLM, а відеостек

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

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

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

Три кити: Whisper, Claude та ImageKit

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

Перший компонент — Whisper (через API Groq) для транскрипції. Завдання цього модуля суто утилітарне: «передати аудіофайл і отримати назад увесь текст». Точність і швидкість тут критичні, бо саме текст стане основою для подальшої роботи LLM і для генерації субтитрів.

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

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

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

Що саме робить ImageKit у цьому ланцюжку

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

По‑перше, це автоматична оптимізація зображень і відео разом із можливістю «resize, crop & transform». На практиці це означає, що сервіс «уміє робити вирівнювання по обличчю: брати відео, фокусуватись на обличчі й рухати кадр за ним». Це критично для переходу з 16:9 у вертикальний формат — фрейм має не просто обрізатися по центру, а тримати людину в кадрі, навіть якщо вона рухається.

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

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

Оптимізація транскрипції: тільки аудіо, без відео

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

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

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

Трансформації через URL: без важкої логіки на бекенді

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

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

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

Від завантаження до шортів: як виглядає живий пайплайн

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

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

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

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

Останній штрих: субтитри, вшиті у відео

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

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

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

Висновки: реальний потенціал і реальні граблі AI‑відеостеків

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

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

У цьому сенсі зв’язка Whisper + Claude + ImageKit виглядає логічною: Whisper перетворює звук на текст, Claude надає цьому тексту структуру й сенс, а ImageKit закриває весь «фізичний» відеостек — від рефреймінгу до вшитих субтитрів та адаптивного стрімінгу. Кейс Tech With Tim демонструє, що за наявності правильно підібраних сервісів і чіткого розуміння їхніх можливостей та обмежень, повноцінний AI‑сервіс шортів уже можна зібрати «під ключ» у реальному робочому режимі — з багами, відкатами й обов’язковими уточненнями до моделей.


Джерело

YouTube: My Real AI Coding Workflow (build anything)

Як змусити LLM працювати як інженера: контекст, правила й відладка

0

Канадський розробник і автор каналу Tech With Tim показує не черговий «демо‑чудо» ШІ, а свій реальний робочий процес: як змусити велику мовну модель у Cursor поводитися не як чат‑бот, а як керований інженер‑агент. У центрі — не стільки сам застосунок для AI‑шортів, скільки спосіб роботи: довгі голосові промпти, початковий архітектурний контекст, правила для git‑комітів і відладка через знімки екрана.

Диктувати, а не друкувати: чому голосовий промпт важливий

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

Розробник відкриває Cursor, створює нову папку й одразу запускає довгий початковий промпт. Але набирати кілька абзаців технічного опису незручно, тому він використовує інструмент Whisper Flow, який працює на комп’ютері й інтегрується з Cursor. Він просто говорить у мікрофон, а все сказане миттєво перетворюється на текст.

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

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

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

Початковий контекст як архітектурний документ

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

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

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

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

Змушуємо агента запитувати й створювати структуру

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

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

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

Git як правило, а не рекомендація

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

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

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

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

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

Правила Cursor як постійний «системний контракт»

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

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

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

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

Людина в циклі: читати, втручатися, направляти

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

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

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

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

Відладка через скріншоти: коли моделі потрібно «побачити»

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

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

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

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

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

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

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

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

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

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

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


Джерело

YouTube: My Real AI Coding Workflow (build anything)

Cursor, MCP і агентні скіли: як перетворити IDE на AI‑співрозробника

0

У новому тривалому гайді розробник і автор каналу Tech With Tim показує не «демку з презентації», а свій реальний щоденний стек для AI‑кодингу. Він будує веб‑додаток із нуля, опираючись на Cursor, моделі Claude та MCP‑сервери, і по ходу детально демонструє, як правильно готувати середовище, щоб модель не просто дописувала функції, а працювала як повноцінний агент, що читає документацію, керує сторонніми сервісами й GitHub‑репозиторієм.

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

Чому саме Cursor: моделі ті самі, а досвід інший

Базовий вибір автора — писати код у Cursor із моделлю Claude як основним «мотором» для проєкту. Для цього конкретного кейса він відкриває «агентне» вікно Cursor, обирає одну з актуальних фронтирних моделей Claude і вмикає розширений контекст, «щоб вона могла вмістити все, що нам потрібно для проєкту». Параметри на кшталт «fast mode», великого контекстного вікна та середнього рівня «thinking mode» він називає своїм робочим «sweet spot» для складних задач.

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

Розробник пояснює, що випробував різні інтерфейси на основі Claude, включно з окремими середовищами на зразок Claude Code, а також інші кодувальні інструменти, але повернувся саме до Cursor. Причина — в «coding harness», який зробила команда Cursor. За його словами, хоч усі ці інструменти звертаються до однакових LLM, внутрішня обв’язка й те, як IDE керує запитами й контекстом, дає Cursor відчутну перевагу в стабільності та якості результатів.

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

Інтерфейс, а не чатик: чому важливо «бачити код»

Хоч Cursor останнім часом активно просуває «агентні» вікна й окремі UI для спілкування з моделлю, автор свідомо обходить їх стороною. Він відкриває стандартну панель із файлами й розміщує чат агента праворуч, фактично перетворюючи його на ще одну IDE‑панель.

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

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

Старт із плану: голосовий контекст як базовий артефакт

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

У цьому початковому промпті він:

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

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

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

MCP як місток до зовнішніх сервісів

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

Йдеться не лише про ImageKit, із яким він працює в цьому кейсі, а загалом про сучасні фреймворки й сервіси, які пропонують агентні інтеграції. Він згадує, що «багато нових тулів — від фреймворків до різних сервісів — уже мають agent skills або MCP‑сервери», покликані пояснити моделі, як правильно ними користуватися. Це фактично стандартизовані «гучні інструкції» та інструменти, які дають агента API‑доступ до сервісу.

На прикладі ImageKit ця стратегія видно особливо чітко. На сторінці «Build with AI» сервіс надає одразу три типи ресурсів:

  • agent skills;
  • MCP‑сервери;
  • звичайну текстову документацію.

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

Наступний крок — власне MCP‑сервер. У документації наведений фрагмент конфігурації для cursor.mcp.json, який можна додати вручну. Замість копіювати файли, розробник просто дає інструкцію самій моделі в Cursor: «додай ці MCP‑сервери». Агенти в IDE редагують конфіг, після чого середовище просить перезапуску.

Далі задіяна стандартна команда командного палетера (Command/Control + Shift + P) із пошуком «MCP settings». Відкривши вікно налаштувань MCP, він бачить:

  • доданий MCP‑сервер для ImageKit;
  • уже раніше підключений GitHub MCP.

Для ImageKit він натискає «Connect», вставляє приватний API‑ключ і отримує підключений MCP‑сервер із переліком доступних tools. Тепер агенти Cursor можуть:

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

У результаті IDE перетворюється на диспетчер, де LLM‑агент може не тільки писати код, а й взаємодіяти з віддаленим сервісом як із власним «бекендом», не вимагаючи від розробника ручного копіювання URL‑прикладів чи фрагментів API‑доків.

GitHub як агентна звичка: правила, що завжди в контексті

Ще один важливий елемент середовища — GitHub MCP‑сервер і система правил у Cursor. Після підключення ImageKit‑агентів автор просить модель:

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

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

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

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

Коли IDE стає хабом: ефект правильно підготовленого середовища

Після підключення MCP‑серверів, agent skills і правил Cursor уже знає:

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

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

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

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

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

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

Висновок: AI‑агент — це не чарівна кнопка, а правильно налаштоване середовище

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

  • планувальним центром, де голосові промпти перетворюються на архітектурні документи;
  • агентним хабом, через який LLM керує MCP‑сервісами на зразок ImageKit і GitHub;
  • органайзером правил, що задають сталі «звички» моделі — від комітів до стилю роботи з інструментами.

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


Джерело

YouTube: My Real AI Coding Workflow (build anything)