Колишній інженер xAI Ілона Маска подав до суду на компанію та її материнську структуру SpaceX, стверджуючи, що його звільнили за зауваження щодо безпеки ШІ.

Девін Кім, який залишив xAI у вересні 2025 року, подав позов до суду штату Каліфорнія у вівторок. Скарга з’явилася за кілька днів до виходу SpaceX на публічні ринки в рамках IPO, яке може стати найбільшим в історії.

Згідно з позовом, з яким ознайомився TechCrunch, Кім став помітним голосом у темі безпеки ШІ, працюючи над Grok, чат-ботом xAI. Він нібито неодноразово скаржився на те, що xAI не приділяє належної уваги безпеці під час розробки Grok — продукту, який згодом піддався критиці через низку проблем із безпекою та поведінкою. Зокрема, Кім був занепокоєний тим, що Grok може розпалювати дискримінацію та сприяти поширенню інформації про зброю масового ураження.

«Grok, звичайно, підтвердив правоту пана Кіма, демонструючи показові прояви онлайн-ненависті та люті, при цьому модель порівнювала себе з Гітлером (“MechaHitler”)», — йдеться в позові. «Після інциденту з Гітлером пан Кім працював над переоцінкою політичної упередженості Grok та його дискримінаційних тенденцій».

За кілька місяців після відходу Кіма з xAI Grok знову потрапив у заголовки новин, коли чат-бот використали для масового поширення в X — соціальній мережі Маска, яка також входить до орбіти xAI — несхвальних інтимних зображень.

Позов також подає Кіма як викривача, стурбованого нібито ігноруванням xAI питань безпеки ШІ, що він вважає «протиправним» у таких сферах, як інтернет-регулювання, захист прав споживачів та недобросовісна ділова практика, а також регулювання озброєнь і вибухових речовин тощо.

xAI та SpaceX не надали коментарів на запити журналістів.

Інтерес Кіма до безпеки ШІ з’явився ще до роботи в xAI. Працюючи в Scale AI, він брав участь у ранніх ініціативах із безпеки ШІ, зокрема очолював проєкт зі створення навчальних даних для систем виявлення шкідливого контенту та дотримання політик управління. Минулого тижня некомерційна організація Center for AI Safety, що зосереджується на ризиках ШІ, оголосила Кіма своїм президентом.

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

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

«В одному випадку, приблизно в серпні 2025 року, пан Ба намагався обійти вимоги регуляторів ЄС щодо безпеки під час випуску Grok Code 1, неправдиво представляючи окремі аспекти моделі, аби уникнути обов’язкового тестування», — зазначається у скарзі. «Пан Ба дав зрозуміти, що воліє випустити небезпечну модель, ніж таку, що показує слабкі результати. Врешті-решт пан Маск був змушений втрутитися».

Згідно з позовом, Кім планував представити свої висновки під час доповіді у тиждень 15 вересня 2025 року, але Ба викликав його на зустріч і заявив, що їм слід «розійтися», не надавши переконливих пояснень.

TechCrunch також звернувся до Ба по коментар.

Кім вимагає компенсаційних і штрафних збитків, а також судового рішення, яке визнає дії xAI та SpaceX протиправними.

Джерело

TechCrunch

У міру того, як Summer Game Fest добігає кінця, це вдалий час для підбиття підсумків. Ідеться не лише про круті ігри, які ми побачили (а їх було чимало), а й про індустрію, що за останні роки досягла нових творчих і художніх вершин, але водночас переживає глибоко депресивні періоди через масові звільнення, скасування проєктів і закриття студій. Xbox вирішила винести свою рефлексію у публічну площину.

Нова CEO Xbox Аша Шарма та директор із контенту Метт Бууті опублікували відкритий лист до співробітників компанії з нагоди перших 100 днів керівництва Шарми. Висновки у ньому доволі похмурі.

Почати хоча б із простої математики доходів Xbox, яка наразі не складається в історію успіху. «Без урахування Activision Blizzard King, за останні п’ять років ми витратили понад 20 мільярдів доларів на постійні інвестиції в контент, платформу та дотацію “заліза”, але наш річний дохід за цей час знизився майже на пів мільярда», — йдеться у зверненні керівників. «У майбутньому так тривати не може». Вони також визнають вплив так званого RAMaggedon: «Зараз ми не можемо виробити стільки консолей, скільки гравці хочуть купити, і нам потрібна нова бізнес-модель і партнерства у сфері апаратного забезпечення, адже ми залишаємося відданими Helix». (Helix — це Project Helix, кодова назва нової консолі Xbox.)

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

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

Джерело

Engadget

Червневе оновлення Patch Tuesday для Windows 11 стало одним із наймасштабніших за останній час. Воно приносить новий режим із низькою затримкою для плавнішої навігації системою, низку нових функцій, а також сотні виправлень багів і вразливостей. Це своєрідний «пакет полегшення» для Windows 11 на тлі того, що Microsoft знову зосереджується на своїй флагманській ОС, яка останніми роками втратила популярність серед техноентузіастів. Компанія з Редмонда прибирає кнопки Copilot і нарешті покращує UX та продуктивність у давно занедбаних частинах системи.

Користувачі побачать червневе оновлення у Windows Update під кодом KB5094126 (OS Builds 26200.8655 та 26100.8655). Головна новинка — профіль із низькою затримкою, який має зменшити повільні завантаження ключових елементів оболонки, як-от меню «Пуск», Центр дій, Пошук, а також прискорити запуск застосунків.

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

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

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

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

Цим оновленням також виправлено інші наболілі проблеми Windows 11, зокрема роботу завантажень з Microsoft Store. Раніше оновлення застосунків і системних компонентів для багатьох користувачів встановлювалися дивовижно повільно — тепер цей процес має стати значно швидшим. Пошук Windows теж трохи прискорили: результати починають з’являтися вже після введення двох символів. Це корисно тим, хто звик запускати програми через клавішу Win і введення назви або активно користується пошуком.

Серед нових можливостей червневого оновлення — підтримка одночасної роботи камери в кількох застосунках: тепер, наприклад, можна бути на дзвінку в Zoom і паралельно робити селфі. Додано також Shared Audio, що дозволяє Windows транслювати звук одразу на дві пари навушників або гарнітур Bluetooth LE.

Ще одна зміна: під час встановлення нової копії Windows користувачі нарешті можуть задати будь-яке ім’я для своєї користувацької папки. Також у «Диспетчері завдань» з’явилися нові інструменти моніторингу NPU — якщо у вашому ПК є окремий чип для задач штучного інтелекту.

Джерело

Engadget

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

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

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

Це дуже нетипова організаційна модель. У OpenAI Сем Альтман, за повідомленнями, має близько пів десятка прямих підлеглих — значно ближче до стандарту, тоді як у Nvidia Дженсен Хуанг, ще один виняток, керує вже багатьма десятками прямих підлеглих.

Джерело

TechCrunch

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

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

Щоб зрозуміти, що поставлено на карту для Індії, варто подивитися на її роль сьогодні. Країна вже давно вийшла за межі класичного бек-офісного аутсорсингу. Індія — найбільший у світі ринок Global Capability Center (GCC) — спеціалізованих офшорних підрозділів міжнародних корпорацій, які відповідають за все: від ІТ та фінансів до R&D. У країні працює понад 2 100 таких центрів, які забезпечують роботою близько 2,36 млн людей і генерують майже 100 млрд доларів річного доходу.

За словами Неджатіана, сама Opendoor створила в Індії велику команду для обробки ручних робочих процесів у розрізнених системах. Коли компанія відкрила офіси в Ченнаї та Бангалуру у 2024 році, в Індії працювало майже 250 її співробітників. Але за останні роки Opendoor загалом скорочує масштаби. Біржові звіти показують, що наприкінці минулого року в компанії було 1 042 працівники по всьому світу проти 1 470 роком раніше. Чисельність штату за межами США також зменшилася — до 184 працівників проти 342 наприкінці 2024 року.

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

Частина інвесторів сприйняла це як сигнал про можливі наслідки ШІ для величезного індійського ринку аутсорсингових послуг. «У міру того, як ручну працю замінюватиме ШІ, в Індії буде втрачено багато робочих місць», — написав Шил Мохнот, співзасновник Better Tomorrow Ventures.

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

Філ Фершт, CEO консалтингової компанії HFS Research, що відстежує глобальну індустрію аутсорсингу та бізнес‑сервісів, сказав TechCrunch, що подію не варто розглядати лише як перенесення робочих місць з Індії до США. Набагато важливіша зміна, за його словами, полягає в тому, що ШІ зменшує загальну потребу компаній в операційній праці, дозволяючи їм працювати з більш «легкими» структурами незалежно від локації.

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

Фершт вважає, що виграють ті компанії, які зможуть поєднати ШІ, програмне забезпечення та людську експертизу для досягнення результатів без постійного нарощування штату — модель, яку він називає «Services-as-Software» («сервіси як софт»). Opendoor може бути одним із перших гучних прикладів, але навряд чи стане останнім, каже він.

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

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

Джерело

TechCrunch

Коли IBM-івський подкаст Security Intelligence добирається до теми ідентичностей, це зазвичай означає холодний душ для тих, хто вважає, що керує доступами більш-менш упевнено. У свіжому випуску ведучий Метт Косінскі разом із фахівцями зі X‑Force та напрямку identity & access management розбирають звіт Sophos State of Identity Security 2026. Центральний висновок: сервісні обліковки, API‑ключі та інші non‑human identities (NHI) вже давно не «другорядний шум», а ключовий фактор успішних атак.

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

Коли кожен другий інцидент — про ідентичність

Sophos у своєму звіті опитала 5000 керівників ІТ та безпеки й виявила, що 71% респондентів пережили щонайменше один identity‑related breach за останній рік. Для фахівців це не новина: IBM X‑Force роками фіксує, що атаки на ідентичності тримаються у верхніх рядках глобальної статистики.

Новим у звіті стало інше — спроба розділити людські та нелюдські ідентичності. Sophos окремо порахувала інциденти, де зловмисники крали облікові записи користувачів, і випадки, коли компрометувалися саме non‑human identities: сервісні акаунти, API‑ключі, обліковки технічних сервісів і агентів.

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

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

Сервісні обліковки як ідеальна ціль

Керівник напрямку X‑Force threat intelligence Нік Бредлі формулює головну причину такої популярності NHI в атаках максимально просто: «Тому що ніхто не дивиться».

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

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

Тут критичними стають дві властивості NHI:

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

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

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

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

Identity & Access Management: 25 років боротьби з одними й тими самими проблемами

Тема ідентичностей у безпеці не нова. Один із учасників подкасту, який понад чверть століття працює в identity & access management, визнає: «Ідентичність завжди була складною. Я понад чверть століття в identity & access management, і ми досі вирішуємо ті самі проблеми знову й знову».

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

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

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

Ефемерні ID для AI‑агентів: мінімум прав, мінімум часу

Окрема лінія дискусії — як саме вписати агентні фреймворки та AI‑сервіси в модель доступів. Сьогодні чимало експериментів і пілотів запускаються максимально просто: «під основним користувачем».

«Багато хто запускає агентні фреймворки типу Open‑сlaw просто під основним користувачем — фактично під root або “адміном”, тож якщо агент помиляється, він робить дуже великий безлад дуже швидко», — наголошують учасники розмови.

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

Запропонований контрхід — змінити сам принцип роботи з агентами й сервісами.

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

Ключові елементи підходу:

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

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

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

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

Нелюдські ідентичності все одно починаються з людей

Ще один нюанс, який легко випускають з поля зору: non‑human не означає «безлюдний». Креативна директорка IBM X‑Force Cyber Range Клер Нуньєс нагадує, що в кожній NHI десь на початку ланцюга все одно є людина.

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

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

Саме тому тема NHI часто викликає подив на рівні керівництва. «Ми бачимо, як клієнти починають враховувати non‑human identities у своїх сценаріях, і іноді їхні керівники трохи губляться: “Як це — у нас є люди й у нас їх одночасно немає? Ми просто маємо всі ці ідентичності”», — описує вона типову реакцію.

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

Висновок: AI створює проблему й допомагатиме її вирішувати

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

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

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

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

Джерело

Подкаст IBM Technology: Security Intelligence — «Can you social engineer an AI? Plus: AI worms and the nonhuman identity problem»

У щотижневому подкасті IBM Security Intelligence ведучий Метт Косінскі разом із експертами з кібербезпеки Джеффом Крумом, Клер Нуньєс і Ніком Бредлі обговорюють черговий тривожний сигнал для ринку: університет Торонто продемонстрував саморозповсюджуваний AI‑«черв’як» на основі відкритої LLM. Звідси розмова швидко переходить до ширшої теми — як екосистема open‑source моделей, зокрема Hugging Face, радикально ускладнює будь-який контроль зловживань і чому заклики «просто не використовуйте AI для Х» вже не працюють.

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

Чому дослідники обрали саме open‑source модель

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

Ключова деталь: у роботі використали саме відкриту модель.

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

«Вони використали open‑source модель, бо це означає, що немає OpenAI чи Anthropic, які дивляться, що ти робиш, і можуть вигнати з платформи.»

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

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

Hugging Face як GitHub для моделей: машину вже не заглушити

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

Джефф Крум описує платформу як «GitHub для моделей» і підкреслює масштаб явища:

«На Hugging Face — це як GitHub для моделей — вже більше двох мільйонів AI‑моделей. Немає способу зупинити це чи “відкотити назад”.»

Далі він послідовно використовує серію образних аналогій, щоб пояснити: будь-які спроби «загальмувати» розвиток open‑source AI запізнилися:

«Немає сенсу намагатися “замкнути хлів”, коли всі тварини вже втекли. Тут неможливо повернути зубну пасту в тюбик або загнати джина назад у пляшку.»

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

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

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

«Не використовуйте AI для Х» більше не працює

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

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

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

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

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

Якщо захисники відмовляться від AI, гонка все одно триватиме

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

Це формулюється максимально прямо:

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

Ця фраза задає практичну рамку для будь-якої стратегії безпеки в епоху LLM:

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

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

«Занадто небезпечні» моделі й те, як їх використати на користь

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

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

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

Це важливий акцент для команд, які займаються пентестами, Red Team‑операціями чи побудовою DevSecOps‑процесів. Ті самі принципи, які демонструє AI‑черв’як (самостійний пошук шляху атаки, адаптація до цілі, вибір експлойтів), можуть бути використані:

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

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

Новий реалізм для ринку AI‑сервісів

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

Цей реалізм включає кілька неприємних, але необхідних визнань:

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

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

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

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

Джерело

Can you social engineer an AI? Plus: AI worms and the nonhuman identity problem — IBM Technology

Подкаст Security Intelligence від IBM Technology цього разу взявся за тему, яка донедавна звучала радше як сценарій з наукової фантастики: саморозповсюджуваний AI‑черв’як. Ведучий Метт Косінскі разом з експертами з кібербезпеки Джеффом Крумом, Клер Нуньєс і Ніком Бредлі обговорили роботу дослідників Університету Торонто, які продемонстрували прототип такого шкідника на базі open‑source LLM. На тлі постійних дискусій про можливості й ризики генеративного AI це дає рідкісну можливість подивитися на те, як виглядатиме наступний виток еволюції шкідливого ПЗ — і оборони від нього.

Новий тип черв’яка: агент, що «розмірковує» на кожному хості

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

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

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

«Що так довго?» Чому AI‑шкідники були неминучими

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

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

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

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

Моделі стають меншими — черв’якам легше рухатися

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

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

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

Невідворотна асиметрія: open‑source моделі й відсутність «вимикача»

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

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

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

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

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

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

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

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

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

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

Висновок: «швидкий дурень» і наступний етап гонки

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

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

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

Джерело:
Can you social engineer an AI? Plus: AI worms and the nonhuman identity problem — IBM Technology

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

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

Як зламали AI‑підтримку Instagram

Схема, яку описали учасники дискусії, вражає простотою. Хакери видавали себе за законних власників Instagram‑акаунтів і спілкувалися не з живими операторами, а з AI‑агентом служби підтримки Meta.

Вони просили оновити email, прив’язаний до облікового запису, на адресу, яку контролювали самі. І агент просто це зробив. Система без додаткових перевірок внесла новий email у профіль. Далі все елементарно: зловмисники використовували цю адресу, щоб отримати коди скидання пароля і повністю перехопити акаунти.

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

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

«Ти корисний асистент» — і цього вже достатньо, щоб зробити біду

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

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

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

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

AI з тисячею PhD, який ніколи не виходив з підвалу

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

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

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

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

AI — це AI, а не AW

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

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

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

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

Дизайн агентів як нова зона ризику

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

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

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

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

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

Що це означає для сервісів в Україні

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

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

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

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

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

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

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

Джерело

YouTube: Can you social engineer an AI? Plus: AI worms and the nonhuman identity problem

Канадський розробник і ютубер Tech With Tim відомий своїми практичними гайдами для програмістів: від кар’єри до інструментів AI‑кодингу. В одному з останніх випусків він показує не лише локальний стек для agentic‑кодингу, а й утилітарний інструмент, який цей стек доповнює: сервіс here.now для миттєвого деплою демо‑сайтів через одного AI‑агента.

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

Один prompt замість пайплайна деплою

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

Сервіс позиціонується як «спосіб деплоїти сайти дуже легко, особливо для демо», причому ключовий жест — не налаштування репозиторію, домену чи CI/CD, а буквально копіювання одного єдиного prompt. Цю інструкцію для агента можна взяти безпосередньо на головній сторінці here.now.

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

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

Як працює сценарій з AI‑агентом

У розповіді це не абстрактна схема, а опис цілком конкретного робочого процесу. Автор використовував here.now у зв’язці з Claude Code: саме там він копіював agent instructions, вставляв prompt і давав завдання розгорнути сайт.

По суті, here.now виступає «бекендом деплою», а інтерфейсом залишається AI‑агент, який виконує всі кроки за користувача. Коли інструкція вставлена і завдання сформульоване, агент запускає процес, і через короткий час презентація чи демо‑проєкт опиняється на окремому URL.

На прикладі презентації до цього ж відео видно, як це працює на практиці. Слайди були задеплойлені саме через here.now, і доступні за унікальним доменом сервісу. Демонстрація в ролику показує, що після запуску агента сторінка відкривається як повноцінний сайт, до якого можна перейти будь‑яким браузером.

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

24 години без акаунта і модель «claim» для довгоживучих демо

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

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

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

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

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

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

Платні плани є, але їх можна ігнорувати

Сервіс не обмежується тільки безкоштовним шаром. Проте акцент робиться на тому, що платні тарифи — опція, а не вимога.

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

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

Таким чином, платні плани радше відіграють роль safety valve для тих, у кого демо‑сайти поступово перетворюються на напівпродуктові чи постійно доступні проєкти.

Практичний кейс: презентація як задеплойлений сайт

Щоб уникнути враження, що йдеться про черговий абстрактний «AI‑хостинг», Tech With Tim показує конкретний приклад: презентація, на основі якої побудоване відео, задеплойлена через here.now.

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

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

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

Для кого корисний такий підхід

З урахуванням решти контексту відео, де детально розбирається повністю локальний agentic coding‑workflow, here.now виглядає логічним доповненням до цієї екосистеми.

Сервіс особливо цікавий:

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

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

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

Джерело

The Best LOCAL Agentic Coding Workflow (Complete Guide) — Tech With Tim

Розробник і ютубер Tech With Tim у новому гайді показує, як побудувати повністю локальний AI‑кодинг у Visual Studio Code, не використовуючи жодних хмарних API. Окремий акцент — на тому, як отримати справді офлайн‑autocomplete: під’єднати розширення Continue до LM Studio, задати окрему модель саме для автодоповнення та коректно прописати конфігурацію.

Навіщо окремий інструмент для локального autocomplete

VS Code уже вміє працювати з локальними моделями через вбудовану систему “Manage Language Models”. Це дозволяє підключити сервер LM Studio як custom endpoint і використовувати локальну LLM у вікні чату: просити згенерувати код, редагувати файли, запускати агентний режим.

Однак окремого, нативного налаштування саме для autocomplete у VS Code поки немає. Тому, якщо потрібно, щоб і автодоповнення працювало локально — без інтернету й без хмарних підписок — доводиться доповнювати зв’язку VS Code + LM Studio ще одним компонентом.

Цю роль і виконує розширення Continue. Воно фактично дублює можливості роботи з моделями безпосередньо в редакторі, але додає те, чого бракує VS Code “з коробки”: можливість явно призначити окрему модель як джерело автодоповнення коду.

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

Встановлення Continue та зв’язка з LM Studio

Після того як LM Studio встановлено, налаштовано і моделі вже запущені в режимі локального сервера (Developer → Start Server, preload chat‑модель і autocomplete‑модель), можна переходити до VS Code.

Крок перший — встановити Continue з Marketplace VS Code. Після інсталяції внизу ліворуч з’являється нова іконка у вигляді шестигранника: вона відкриває окрему панель Continue з власним чат‑інтерфейсом та налаштуваннями моделей.

У налаштуваннях Continue потрібно перейти в розділ models. Там є кнопка Add, яка запускає майстер додавання нової моделі. Вибір провайдера — ключовий момент: у списку потрібно обрати LM Studio. Далі Continue попросить вказати модель, але на цьому етапі можна вибрати будь‑яку доступну опцію — важливо лише, щоб плагін створив конфіг‑файл.

Після натискання Connect Continue автоматично згенерує конфігурацію у форматі JSON. Внизу файлу з’являється новий блок моделі, пов’язаної з LM Studio. Саме цей блок доведеться відредагувати вручну, щоб модель справді відповідала тій, що запущена в LM Studio.

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

Базова ідея налаштування проста: Continue має знати, до якого API‑endpoint звертатися, яку модель запитувати й для чого саме її використовувати. У випадку з autocomplete це означає: вказати назву моделі, API‑базу LM Studio та роль autocomplete.

У згенерованому Continue config достатньо змінити кілька полів. По‑перше, model має відповідати назві моделі з LM Studio. Для автодоповнення демонструється використання маленької моделі:

у полі model вказується назва моделі з LM Studio, наприклад Gwen 2.5 coder 1.5B.

Можна також змінити людське ім’я (name), але це радше косметика. Ключове поле для прив’язки до LM Studio — apiBase: тут використовується локальна адреса API, яку LM Studio показує в інтерфейсі developer‑сервера. Її достатньо просто скопіювати й вставити в конфіг Continue.

Далі додається ще один параметр — roles. Саме він говорить Continue, для чого ця модель призначена. Щоб зробити її джерелом автодоповнення, у roles потрібно додати:

rules: ["autocomplete"]

У фінальному вигляді блок моделі в Continue має містити назву, провайдера LM Studio, правильний apiBase, назву моделі з LM Studio й масив правил, де чітко вказано autocomplete.

Після збереження конфіг‑файлу Continue починає вважати цю модель спеціальною autocomplete‑моделлю. Тепер у налаштуваннях плагіна можна вибрати її як джерело автодоповнення. З цього моменту, коли розробник друкує код у будь‑якому файлі VS Code, саме локальна модель, підключена через LM Studio, генерує підказки.

Це забезпечує повністю офлайн‑autocomplete: усі запити йдуть по локальному HTTP до LM Studio, а обчислення відбуваються на власному комп’ютері без доступу до інтернету.

Окремі моделі для autocomplete та чату в Continue

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

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

roles і capabilities, серед яких chat, edit, apply і tool use.

Таке поєднання дає Continue змогу не тільки вести діалог, а й застосовувати зміни до коду та викликати інструменти (tools), якщо модель це підтримує. Конфігурацію для чат‑моделі пропонується просто копіювати за готовим шаблоном, змінюючи лише ID та назву моделі під свій вибір у LM Studio.

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

Continue у цій конфігурації використовується цілеспрямовано як “локальний autocomplete‑модуль”, тобто як шар, який додає відсутнє нативне налаштування автодоповнення поверх уже працюючої зв’язки VS Code + LM Studio.

Що бачить розробник і як перевірити, що все працює

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

Паралельно в LM Studio на вкладці з autocomplete‑моделлю можна спостерігати лог запитів: під час набору коду з’являється стрім токенів, що підтверджує, що саме ця модель зараз генерує підказки.

У деяких випадках може знадобитися перезапустити VS Code, щоб Continue коректно підхопив новий конфіг. Після цього вся зв’язка працює стабільно: VS Code для чату й agentic‑операцій із файлами, LM Studio як сервер локальних моделей, Continue як цілеспрямований мостик для офлайн‑autocomplete.

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

Комбінація LM Studio, VS Code і розширення Continue дозволяє досягти того, чого поки не дає жоден компонент окремо: повністю локального, контрольованого розробником AI‑autocomplete у звичному редакторі.

Ключові кроки — підняти локальний сервер у LM Studio з двома моделями (швидка маленька для autocomplete, потужніша для чату), додати LM Studio як провайдера в Continue й правильно розмітити ролі моделей у конфіг‑файлі, зокрема через rules: ["autocomplete"].

У результаті VS Code залишається центральним робочим середовищем, де нативний чат використовується для редагування файлів і агентних сценаріїв, а Continue — як нишевий, але критично важливий інструмент, що вмикає справді офлайн‑autocomplete поверх локальних моделей LM Studio.

Джерело

The Best LOCAL Agentic Coding Workflow (Complete Guide)

Розробник і ютубер Tech With Tim у великому гіді показує, як зібрати повністю локальний стек для AI‑кодингу: мовні моделі в LM Studio, редактор Visual Studio Code і жодних хмарних API. Одна з ключових частин цієї схеми — підключення локальної моделі як повноцінного агента у вбудований VS Code Chat через custom endpoint, з підтримкою tool use і детальними логами в LM Studio.

Йдеться не про ще одне розширення, а про використання нової офіційної функції VS Code для керування мовними моделями, яка працює офлайн і без акаунта. У поєднанні з LM Studio це перетворює звичайний редактор на повноцінний agentic‑код‑середовище, яке живе виключно на вашому комп’ютері.

Нова функція VS Code: локальні моделі без акаунта і інтернету

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

У VS Code це заховано в Command Palette. Потрібно відкрити будь‑яку теку як проєкт, а далі викликати палету клавішами. На Windows це комбінація Ctrl+Shift+P, на macOS — Command+Shift+P. У пошуку команд достатньо ввести «manage», і з’явиться пункт «Manage Language Models».

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

LM Studio як локальний сервер для VS Code Chat

LM Studio в цій зв’язці грає роль не тільки менеджера моделей, а й API‑сервера. У застосунку є окрема вкладка Developer, де вмикається локальний HTTP‑сервер і завантажуються моделі, якими потім може користуватися VS Code.

Спочатку потрібно запустити сервер у Developer‑вікні LM Studio. Після цього туди ж додаються потрібні моделі: одна — основна «велика» для чату, редагування й agentic‑режимів, інша — менша і швидша для автодоповнення. Завантажені моделі з’являються у списку й готові приймати запити через API.

URL до цього API — це локальний сервер, який запускається саме у Developer‑вікні. Цю адресу LM Studio показує безпосередньо в інтерфейсі, а в конфігурації VS Code її треба просто вставити у поле URL для custom endpoint. Таким чином редактор «бачить» локальний сервер як звичайний chat completions API й починає працювати з ним так само, як із будь‑яким хмарним постачальником.

Конфігурація custom endpoint у VS Code: три поля, які мають значення

Коли в VS Code у вікні Manage Language Models обирається варіант «Add Models», далі пропонується кілька джерел. Щоб під’єднати LM Studio, обирається «Custom endpoint». Після цього VS Code просить вказати базову інформацію.

Назву endpoint можна задати довільно — наприклад, «LM Studio». Поле API‑key VS Code вимагає формально, але в локальному сценарії воно не використовується, тож достатньо ввести будь‑який рядок. Головне — вибрати тип «chat completions», щоби конфігурація відповідала інтерфейсу LM Studio.

У цей момент редактор відкриває JSON‑конфіг, де потрібно заповнити лише три параметри: ID, name і URL. URL — це якраз адреса локального сервера LM Studio. Її або копіюють із Developer‑вікна, або вводять у тому ж форматі, який показує сам застосунок.

З ID ще простіше: в LM Studio біля кожної моделі є кнопка копіювання ідентифікатора. Достатньо натиснути цю кнопку, а потім вставити значення одночасно в поля ID та name у VS Code config. У результаті редактор чітко знає, яку саме модель з LM Studio потрібно викликати, і відображає її в інтерфейсі під зрозумілою назвою.

У тій же конфігурації можна вказати, чи вміє модель викликати інструменти (tool calling) і працювати із зображеннями (vision). Для моделей на кшталт Gwen 3.6 у прикладі vision залишили увімкненим, а підтримку tool calling — активною, що критично для agentic‑сценаріїв. Максимальну кількість вхідних токенів логічно синхронізувати з тим контекстом, який показує LM Studio для цієї моделі, а вихідних — збільшити до великого значення, аби не обривати довгі відповіді.

Після збереження JSON‑файлу зміни застосовуються миттєво. Для зручності вікно конфігурації можна викликати знову з Manage Language Models, натиснувши на кнопку відкриття language models JSON — так простіше додавати кілька моделей поспіль, наприклад окремо чат‑модель і окремо модель для автодоповнення.

Як VS Code бачить локальні моделі: «Other models» і вибір Gwen

Коли конфігурація збережена, час перевірити, чи бачить VS Code нову локальну модель. Для цього відкривається вбудований чат редактора. Його можна викликати по‑різному: через гарячі клавіші, через меню View або через пункт Chat у налаштуваннях вигляду. Головне — дістатися до вікна, де відображається діалог і селектор моделі.

У випадаючому списку моделей з’являється розділ «Other models». Саме там і відображаються всі custom endpoints, додані через Manage Language Models. Якщо все зроблено правильно, у списку з’являється, наприклад, «Gwen 3.6 35B A3B» — це саме та модель, ID якої було скопійовано з LM Studio.

Після вибору цієї моделі будь‑який запит у чаті піде не в хмару, а на локальний сервер LM Studio. VS Code при цьому поводиться так само, як із власними інтегрованими моделями: можна просити створити застосунок, переписати файл, згенерувати структуру проєкту тощо. Різниця в тому, що всі обчислення виконує ваша відеокарта чи CPU, а мережний трафік залишається в межах локального хоста.

Developer logs у LM Studio: повний контроль над запитами

Одна з переваг такої інтеграції — прозорість. Коли VS Code надсилає запити до моделі, LM Studio фіксує все це у вкладці developer logs. У ній видно кожен звернений prompt, усі відповіді, службову інформацію та помилки.

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

Якщо щось іде не так — наприклад, модель не встигає завантажитися, бракує пам’яті чи endpoint налаштований некоректно — помилки також потрапляють до developer logs. Це спрощує налагодження локальної конфігурації: замість сліпо шукати, чому VS Code «мовчить», можна подивитися, що саме отримує й повертає LM Studio.

Agentic‑кодинг у VS Code: режими, файли й локальний інтелект

Після підключення локальної моделі через custom endpoint вбудований VS Code Chat перетворюється на повноцінне агентне середовище, але без жодної хмарної залежності. Редактор дає змогу перемикати режими: «ask», «agent», «plan» та інші. Це не просто зміна тону відповідей, а різні поведінкові профілі, де агент може планувати кроки, вносити правки у файли, генерувати нові й працювати поетапно.

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

На практиці це означає, що VS Code із підключеним LM Studio поводиться як будь‑який сучасний agentic‑код‑редактор: приймає завдання високого рівня, планує зміни, вносить правки в декілька файлів, генерує нові модулі. Різниця лише в тому, що обчислення відбуваються на вашому залізі, без вартості за токен і без необхідності розкривати вихідний код зовнішнім сервісам.

Висновок: локальний агент як реальна альтернатива хмарі

Завдяки поєднанню нової функції VS Code для керування мовними моделями та локального API‑сервера в LM Studio стало можливим підняти повноцінного AI‑агента для кодування повністю офлайн. Налаштування зводиться до кількох кроків: запуск developer‑сервера в LM Studio, копіювання URL і ID моделі, заповнення полів ID, name і URL у JSON‑конфігу VS Code та вибір моделі в розділі «Other models» у вбудованому чаті.

Результат — agentic‑код‑workflow, де можна ставити великі завдання, перемикати режими «ask», «agent», «plan», тегати файли, бачити всі запити й відповіді в developer logs LM Studio й водночас повністю контролювати свій стек. Для тих, хто готовий інвестувати трохи часу в налаштування, це відкриває шлях до AI‑асистента, який працює прямо в редакторі — без логіну, без інтернету і без рахунків за API.

Джерело

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

Канал Tech With Tim відомий своїми прикладними розборами інструментів для розробників. В одному з нових випусків автор показує, як побудувати повністю локальний AI‑кодинг‑стек без хмари, з фокусом на LM Studio як центрі керування моделями. Нижче — конденсований практичний гайд по тій частині сетапу, яка стосується саме LM Studio: від вибору моделей родини Gwen до тестування швидкості, контексту, GPU offload і запуску локального сервера.

Чому саме LM Studio: більше контролю, ніж у «простих» лаунчерів

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

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

• Chat — для безпосередньої роботи з моделлю в діалоговому режимі.
• Developer — для запуску локального сервера й перегляду логів запитів.
• Models / «робот» — для пошуку, вибору, завантаження і керування LLM.

Саме цей третій розділ стає ключовим, коли мова йде не лише про «запустити модель», а про точне підбирання варіантів за параметрами, quantization, активними параметрами та можливістю tool use. Далі навколо цього й будується вся логіка локального AI‑кодингу.

Дві моделі, два сценарії: швидкий autocomplete і «важкий» агент

Вся схема локального AI‑кодингу в цьому сетапі спирається на просту, але важливу ідею: використовувати не одну, а дві моделі, кожну під свою роль.

Формула виглядає так: «Зазвичай ми будемо використовувати дві моделі… одну дуже маленьку, швидку для autocomplete, і одну значно більшу, більш здатну — для чату, редагування, agentic‑режиму».

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

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

Поділ ролей дозволяє на тому самому залізі одночасно мати й комфортний live‑autocomplete, і досить потужний локальний агент, який вже не виглядає як «обрізана» версія хмарного LLM.

Autocomplete‑модель: чому ставка робиться на Gwen 2.5 coder 1.5B

Для ролі автодоповнення в цій конфігурації обрана одна «робоча конячка»: «Для більшості з нас ми просто будемо використовувати Gwen 2.5 coder з 1.5B параметрів як autocomplete‑модель».

Логіка тут утилітарна:

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

В LM Studio цю модель можна знайти за назвою Gwen 2.5 coder 1.5B (instruct‑варіант). Автор сетапу просто бере найбільший quantized‑варіант, який «все одно дріб’язковий» для його заліза, але доступні й значно компактніші збірки близько 900 МБ.

Ключова вимога для autocomplete‑моделі проста: мала вага і максимальна швидкість токенів за секунду. Усе інше — другорядне.

Головна модель: без tool use локальний агент «осліплий»

Як тільки мова заходить про основну чат‑модель, вимоги до неї різко змінюються. Тут на перший план виходить не тільки якість коду, а насамперед наявність підтримки інструментів:

«Для основної чат/редагувальної моделі їй потрібен tool use… якщо немає tool use, вона не зможе викликати інструменти, створювати файли, реально редагувати код».

Це критичний момент: без tool use модель може лише «радити» код у відповідях, але не здатна:

• запускати інструменти IDE,
• створювати/переписувати файли,
• виконувати агентні плани всередині редактора.

Фактично це перетворює її на звичайний AI‑чат, а не повноцінного код‑агента. Тому при виборі моделі в LM Studio автор перш за все фільтрує кандидати за наявністю tool use, а вже потім дивиться на розмір, quantization і швидкість.

Вибір Gwen 3.6 35B: баланс потужності, ваги й швидкості

На високопродуктивній машині з великим об’ємом пам’яті (M‑серія Mac із 64 ГБ unified memory) робиться ставка на середній за локальними мірками «важковаговик»:

«Я вирішив взяти Gwen 3.6 35B… 22 GB у Q4… легко влізає в мою пам’ять і працює відносно швидко».

Важливі деталі цього вибору:

• Модель має 35 млрд параметрів, тобто помітно вища за «мінімальний» рівень для локальних код‑LLM.
• Використовується Q4‑quantization, що зменшує вагу збірки до приблизно 22 ГБ — цього достатньо, аби вона «комфортно» вміщувалась у доступну пам’ять.
• Tool use увімкнено, отже модель придатна для agentic‑кодингу, редагування файлів і роботи з інструментами.

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

A3B та «активні параметри»: як змусити великі моделі працювати на слабшому GPU

Окремий акцент зроблено на варіантах моделей із позначенням A3B, A6B тощо. Вони особливо цікаві тим, хто має обмежене залізо, але хоче підняти відносно великі LLM:

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

Суть у тому, що:

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

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

У практичній частині розбору якраз рекомендується Gwen 3.6 14B із позначкою A3B як добрий компроміс для машин із орієнтовно 16 ГБ VRAM: модель відносно велика за потужністю, але все ще «підйомна» для масових конфігурацій.

Тестування моделі в LM Studio: GPU offload, контекст і швидкість

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

По‑перше, GPU offload: «Коли ви тестуєте модель у чаті LM Studio… просто переконайтесь, що GPU offload максимально високий». Це гарантує, що максимальний об’єм моделі працює саме на відеокарті, а не в системній пам’яті чи, ще гірше, на диску. Зменшення offload’у миттєво вбиває швидкість.

По‑друге, довжина контексту. У вікні налаштувань моделі LM Studio показує:

• повну довжину контексту, яку підтримує модель (наприклад, до 262 тисяч токенів),
• оцінку використання пам’яті при різних значеннях контексту.

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

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

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

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

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

Developer‑режим: локальний сервер як місток до редактора

Останній крок усередині LM Studio — це не просто «запустити модель», а підготувати її до взаємодії з іншими інструментами через API.

У вкладці Developer запускається локальний сервер. Далі потрібно:

• увімкнути сервер,
• по черзі завантажити в нього обидві моделі — основну чат/agentic‑модель та autocomplete‑модель,
• ще раз відкоригувати налаштування GPU offload і контексту для кожної, виходячи з доступної пам’яті.

Після завантаження обидві моделі стають доступними через HTTP‑ендпоінт LM Studio. Контролювати їхню роботу можна через developer‑логи: там видно всі запити з редактора, швидкість генерації, можливі помилки.

Усе це — підготовчий етап до інтеграції з редактором коду. Далі вже інші інструменти (у розборі використовується VS Code) просто бачать локальний endpoint як «звичайний» LLM‑API, але фізично вся інференція відбувається на вашій машині.

Підсумок

Якщо відкинути маркетингові обіцянки навколо «локального ШІ», практична реальність виявляється досить структурованою. У запропонованій конфігурації LM Studio стає центральною керуючою консоллю: тут обираються моделі (передусім родина Gwen), налаштовуються quantization, активні параметри й tool use, тестуються швидкість і контекст, а потім усе це виводиться через локальний сервер до редактора.

Схема «мала Gwen 2.5 coder 1.5B для autocomplete + більша Gwen 3.6 з tool use як основний агент» показує, що локальний AI‑кодинг без хмари вже не виглядає екзотикою. За умови уважного налаштування VRAM, GPU offload і довжини контексту такі моделі стають реальним робочим інструментом, а не просто техно‑демо.

Джерело

The Best LOCAL Agentic Coding Workflow (Complete Guide)

У популярного каналу Tech With Tim вийшов докладний гайд про локальний agentic‑кодинг без хмари — з моделями, що працюють прямо на комп’ютері розробника. Ключова частина цієї постановки — правильно підібрана LLM: така, яку ваш ПК або Mac реально “тягне” по пам’яті й пропускній спроможності. Від цього залежить не тільки те, чи модель взагалі запуститься, а й те, чи буде вона працювати зі швидкістю, придатною для щоденного кодування.

У центрі обговорення — кілька простих, але критичних для практики тез: роль VRAM та unified memory, орієнтири по кількості параметрів, пастка “модель трохи більша за вашу відеопам’ять” і значення quantization для розміру та швидкості.

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

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

Критичний параметр — відеопам’ять. Вона фактично задає “стелю” для розміру моделі, яку комп’ютер здатен ефективно тримати цілком у GPU.

У розмові це формулюється максимально прямо: тип або, точніше, розмір моделі, яку можна запускати локально, практично повністю диктується одним числом — обсягом відеопам’яті, VRAM. Для Windows‑машин це означає: потрібно подивитися саме на GPU та його VRAM, а не на загальну системну RAM.

Звідси випливає практичне правило: якщо на відеокарті 16 GB VRAM, можна ефективно запускати модель приблизно до 16 GB за розміром, краще — трохи меншу, щоб залишити запас. Саме цей “ефективно” є ключовим: важливо не просто завантажити модель, а зробити так, щоб вона працювала без катастрофічних просідань у швидкості.

Mac проти Windows: unified memory, доступний обсяг і швидкість

Для Windows та дискретних GPU (NVIDIA тощо) картина доволі пряма: є чітко окреслений обсяг VRAM, і саме він обмежує розмір моделі, що поміститься в GPU цілком. На Mac, особливо з чипами серії M, ситуація відрізняється через unified memory.

На сучасних M‑процесорах RAM є спільною для CPU та GPU. Якщо ноутбук має 64 GB unified memory, теоретично GPU може використати весь цей обсяг як “відеопам’ять”. На практиці частина пам’яті йде на операційну систему й інші процеси, тому орієнтовно доступними для моделі будуть 75–80% цієї пам’яті.

Це породжує два важливі висновки.

По‑перше, при плануванні розміру моделі на Mac доводиться відняти приблизно 10–15% від загального обсягу unified memory: це верхня межа, за якої ще можна розраховувати на пристойну продуктивність. Наприклад, із 64 GB на борту реалістично розраховувати на модель суттєво меншого розміру, а не на повні 64 GB.

По‑друге, попри те, що Mac завдяки unified memory часто здатен завантажувати більші моделі, швидкість не завжди буде кращою. Для дискретних GPU на Windows пропускна спроможність пам’яті зазвичай вища. На конкретних прикладах порівнюється, що сучасний високорівневий GPU дає помітно більшу швидкість читання/запису пам’яті, ніж Mac‑чип. Наслідок: Mac може дозволити собі більший розмір моделі, але виділений GPU частіше забезпечить більше токенів за секунду.

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

Що станеться, якщо модель більша за VRAM

Одна з найбільш практичних частин пояснення стосується сценарію, коли модель за розміром виходить за межі доступної відеопам’яті. Формально це не завжди фатально: якщо модель важить 10 GB, а GPU має лише 8 GB VRAM, система здатна все одно її завантажити.

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

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

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

Скільки параметрів потягне ваш ПК

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

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

якщо є 8 GB VRAM, зазвичай можна запускати модель з 7 мільярдами параметрів;

12–16 GB VRAM відкривають шлях до моделей на рівні 14B;

24 GB дозволяють працювати з моделями близько 32B;

64 GB і більше — це вже рівень, де стають реалістичними моделі приблизно на 70B параметрів.

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

Quantization: трохи якості в обмін на швидкість і розмір

Ще один ключовий шар локального вибору моделі — quantization. У практичній площині це набір варіантів однієї й тієї ж моделі з різними “Q‑рівнями”: повна версія без стиснення, потім варіанти Q6, Q4, Q3, Q2 тощо.

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

Позиція, яка чітко звучить у розборі, доволі прагматична: майже завжди краще брати найнижчу версію quantization, яку ваш комп’ютер здатен запускати. Аргументація проста. Втрата якості невелика, зате виграш у розмірі та швидкості — суттєвий. Менша модель швидше генерує токени і краще вписується в VRAM, що дозволяє уникнути згаданого вище сценарію з “витіканням” частини параметрів у RAM чи на диск.

У конкретному прикладі розглядається модель із 35 мільярдами параметрів, у якої повна версія займає 37 GB, а Q4 — помітно менше. Вибір падає саме на Q4, бо вона без проблем поміщається в доступну пам’ять і працює “відчутно швидше”, ніж більш важка повна модифікація.

Параметри проти пропускної здатності: де проходить реальний компроміс

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

Mac із великою unified memory може завантажувати більші моделі, та при цьому пропускна спроможність GPU‑пам’яті на високорівневих дискретних картках Windows, як правило, вища. Це приводить до того, що більша модель на Mac не обов’язково буде “кращою”, якщо на практиці вона генерує відповіді повільніше, ніж трохи менша, але швидша модель на потужному GPU.

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

Висновок: від VRAM до Q‑рівня — як зібрати реалістичний профіль моделі

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

спочатку визначити обсяг VRAM або доступної unified memory, а для Mac — одразу прийняти, що реально використати вдасться близько 75–80%;

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

орієнтуватися на приблизну відповідність “8 GB VRAM — 7B параметрів, 12–16 GB — 14B, 24 GB — 32B, 64 GB+ — близько 70B”, пам’ятаючи, що це саме орієнтири;

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

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

Джерело

YouTube: The Best LOCAL Agentic Coding Workflow (Complete Guide)

Останні місяці локальні мовні моделі зробили стрибок уперед: вони стали «неймовірно хорошими і відносно простими в запуску» — настільки, що сьогодні розробник може організувати повністю локальний agentic‑кодинг без інтернету, без API‑ключів і без оплати за токени. Канал Tech With Tim показує це на практиці, збираючи повний стек з LM Studio та Visual Studio Code.

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

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

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

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

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

Опус не потягнемо: апаратні межі локального AI

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

«Ми не здатні запускати Opus‑рівень моделей на нашому комп’ютері. Ми можемо запускати ті, що близькі до Sonnet або Haiku» — саме в цьому діапазоні, за оцінкою автора гайду, зараз лежить реалістичний максимум для десктопів і сучасних лаптопів з потужним GPU або великою unified memory.

Граничний розмір моделі диктує:

• відеопам’ять на Windows‑машинах;
• обсяг unified memory на нових Mac із чипами M‑серії.

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

На Mac можна, як правило, завантажити більшу модель завдяки єдиній пам’яті, але вона не завжди буде швидшою. На дискретному GPU Windows пропонує вищу пропускну здатність відеопам’яті, тож модель менша за обсягом може працювати швидше, ніж більша на Mac.

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

«Завантажити модель» недостатньо: що таке справжній agentic workflow

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

Повноцінний agentic‑workflow, описаний у гіді, складається з трьох шарів.

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

По‑друге, менеджер локальних LLM. У цьому сценарії таку роль відіграє LM Studio. Він дозволяє не тільки завантажувати й тримати на диску різні варіанти моделей, а й тонко налаштовувати їх: виставляти довжину контексту, рівень GPU offload, обирати quantization. Важливий момент — підтримка tool‑use основною моделлю: без цього агент не зможе викликати інструменти IDE, створювати й змінювати файли, виконувати команди, а перетвориться на звичайний чат‑бот, що лише «пояснює код».

По‑третє, інтеграція з середовищем розробки. Саме тут локальний AI перетворюється на реальний робочий інструмент. Сучасна версія Visual Studio Code вміє підключатися до локальних моделей через кастомний endpoint, працюючи з ними так само, як із хмарними постачальниками. Запускаючи в LM Studio локальний сервер, розробник експонує свої моделі в межах машини, а VS Code бачить їх як стандартний endpoint для chat‑completions і агентного режиму.

Додатково окремий плагін у VS Code підхоплює локальну модель автодоповнення, щоб навіть inline‑підказки працювали повністю офлайн.

Як виглядає такий стек у щоденній роботі

Після того як моделі підібрано під апаратні можливості, а LM Studio та VS Code пов’язані, розробник отримує повністю автономне середовище. У ньому можна писати запити в чаті IDE, обирати режим — «agent», «plan» чи «edit» — та давати моделі завдання від створення проєкту до рефакторингу файлів.

Усе запускається на одній машині: LM Studio бере на себе підняття моделей і логування запитів, VS Code — інтерфейс і прив’язку до файлової системи. Кожен токен, що виходить із моделі, породжується локально — без сторонніх серверів, без затримок на мережу і без ризику витоку коду в хмару.

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

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

Коли локальний AI реально виручає

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

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

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

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

Контроль, економія й обмеження: що дає локальний стек сьогодні

Повністю локальний agentic‑кодинг, побудований на зв’язці LM Studio та VS Code, демонструє, що автономний AI‑асистент для розробки більше не є екзотикою. Локальні моделі вже «стали неймовірно хорошими і відносно простими в запуску… ви можете робити повний локальний кодинг, без інтернету… без оплати за токени».

Втім, цей підхід вимагає:

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

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

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

Джерело

The Best LOCAL Agentic Coding Workflow (Complete Guide)

Ринок телевізорів у 2026 році отримав помітний технологічний зсув: Samsung вивела в масовий сегмент лінійку Micro RGB R95H, яку українським глядачам показує канал «Канал Лучкова». Це одна з перших спроб зробити мікросвітлодіодні панелі не екзотичним рішенням для шоурумів, а реальною заміною флагманських OLED і QLED у житлових кімнатах.

Micro RGB проти звичайних LED та OLED: у чому різниця

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

У Micro RGB підхід інший:

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

Це радикально змінює контроль над кольором: замість «перефарбованого» білого з’являється три незалежні джерела, які змішуються з дуже високою точністю. Результат — 100% покриття просторів BT.2020, що підтверджено лабораторією VDE (у ролику її називають VDI). Для порівняння:

• більшість OLED закривають приблизно 70–80% BT.2020;
• QLED дають трохи ширше покриття;
• Micro RGB — повне покриття стандарту.

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

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

Ще один ключовий момент: OLED — органічна технологія, потенційно схильна до вигоряння (хоч це і рідкість за адекватного використання). Micro RGB — неорганічні LED, де вигоряння як явище просто не закладене в природі панелі. Це важливо для користувачів, які:

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

Відтак умовно можна поділити аудиторію:

• темна кімната, культ чорного кольору, фільми Нолана — логічний вибір OLED;
• яскраве приміщення, великі вікна, акцент на вибуховому HDR та колориті — Micro RGB виглядає більш доцільно.

Micro RGB AI Engine Pro: коли процесор рахує кожен колір

Окремий пласт інновацій — обробка зображення. Для Micro RGB у Samsung створили спеціальний процесор Micro RGB AI Engine Pro. Завдання цього чипа істотно складніше, ніж у звичайних телевізорів:

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

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

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

Окремо працює AI Upscaling Pro — система, що масштабує старий або не надто якісний контент до 4K. Йдеться про:

• старі серіали Netflix,
• архівні YouTube-ролики.

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

Звук, що рухається разом із кадром, і новий Tizen

Об’ємний звук без обов’язкового саундбара

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

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

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

Одна з найцікавіших технологій — Object Tracking Sound Pro. Вона прив’язує звук до об’єкта в кадрі:

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

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

Додатково працює AI Sound Controller Pro — система, яка в реальному часі дозволяє:

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

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

• діалоги часто «тонуть» у саундтреках;
• баланс звуку від серіалу до серіалу сильно плаває.

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

Перероблений Tizen та Vision AI Companion

ПЗ телевізора також оновили. Інтерфейс Tizen змінили за аналогією зі смартфонами Samsung:

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

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

Окрема історія — Vision AI Companion. Це голосовий помічник на базі Bixby із інтеграцією Perplexity та Microsoft Copilot в одному інтерфейсі. Можливий сценарій:

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

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

Антиблік і розміри: Micro RGB з шоуруму в реальні вітальні

Ще одна технічна деталь — Glare Free. Це антивідблискове покриття, яке, за даними компанії, також верифіковано в лабораторії VDE. Раніше схожі покриття вже були в OLED-моделях Samsung, але в поєднанні з Micro RGB та Glare Free ефект особливо помітний:

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

Щодо форм-факторів, ситуація показова для всієї індустрії. Ще рік тому Micro RGB існував лише як:

• 115-дюймовий комерційний дисплей;
• з цінником близько 30 000 доларів.

Тепер R95H доступний у масових діагоналях:

• від 55 до 85 дюймів (у ролику окремо згадуються 65″ та 85″).

Тобто технологія за один рік зробила шлях від демонстраційного «монстра» до реальних розмірів для віталень, де 65–75 дюймів давно стали новою «золотою серединою».

Контент наздогнав екрани: для кого насправді Micro RGB

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

• брати Даффери після фіналу «Stranger Things» у грудні 2025-го вже встигли запустити кілька нових проєктів. Один із них — Borows на Netflix (нова надприродна містика в дусі «Stranger Things», але з героями пенсійного віку, реліз 21 травня, вже в топ-5 за переглядами);
• на Amazon з’являється Spider-Man Noir із Ніколасом Кейджем у ролі постарілого людини-павука в Нью-Йорку 30-х. Серіал можна дивитися:
• у чорно-білому «автентичному» режимі;
• у повнокольоровій версії — саме тут Micro RGB демонструє себе особливо яскраво, радикально змінюючи сприйняття нуарного світу;
• на Apple TV+ виходить новий сезон Silo (у ролику згадано як «Sй») із Ребеккою Фергюсон — одна з найяскравіших антиутопій останніх років, з рейтингом близько 90% на Rotten Tomatoes.

І, нарешті, кіноподія року — «Дюна. Частина третя», український реліз анонсовано на 18 грудня. Очевидно, що перший перегляд для багатьох відбудеться у кінотеатрі, але фільм, який візуально заточений під масштаб і деталі, — саме те, що хочеться передивлятися вдома на максимально здатному екрані.

На цьому тлі стає зрозуміло: Micro RGB — не про «просто дивитися YouTube на великому екрані». Це технологія для тих, хто:

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

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

Micro RGB навряд чи стане масовим стандартом на найближчі роки — і це нормально. Для тих, кому достатньо доброго чорного в темряві й базового HDR, OLED залишається дуже сильним вибором. Але для аудиторії, яка хоче:

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

R95H та інші Micro RGB-моделі стають новою віхою, з якої «як раніше» виглядатиме вже блідно.

Джерело

Samsung Micro RGB R95H – Хочу собі ТАКИЙ!