Waymo призупинила роботу своїх роботаксі на автострадах у Сан-Франциско, Лос-Анджелесі, Фініксі та Маямі, поки вдосконалює поведінку автопілота в зонах дорожніх робіт. Про це компанія підтвердила у коментарі для TechCrunch.

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

Рішення вивести роботаксі з автострад послідувало за попереднім кроком Waymo — призупиненням сервісу в Атланті та Сан-Антоніо (штат Техас) для усунення проблем із проїздом підтопленими ділянками. Минулого тижня компанія оголосила про відкликання програмного забезпечення, яке мало допомогти флоту уникати затоплених вулиць у Сан-Антоніо, де сервіс уже кілька тижнів не працює, поки Waymo шукає більш постійне рішення. Цього тижня принаймні один роботаксі застряг в Атланті, після чого Waymo також призупинила там роботу.

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

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

Особливо це відчутно в затоку Сан-Франциско: пересування автострадами допомогло Waymo суттєво скоротити час поїздок через півострів, які раніше могли тривати від 45 хвилин до понад години.

Джерело

TechCrunch

Попри деякі гучні одкровення в S-1 SpaceX напередодні виходу компанії на біржу, повний контроль Ілона Маска над компанією навряд чи став для когось сюрпризом.

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

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

Він володіє трохи менш ніж 850 млн акцій класу A з правом одного голосу на акцію та ще майже 5,6 млрд акцій класу B з правом 10 голосів на акцію. Сюди входить і мільярд акцій, прив’язаних до умовного «міста-компанії» SpaceX на Марсі з населенням у мільйон людей.

Якщо відкинути наукову фантастику, найбільше виграють від успішного IPO SpaceX і подальшого зростання акцій кілька людей, які мають від 5% компанії. Це інвестори з часткою не менше 5%.

Компанія поки не розкрила, скільки акцій планує розмістити й за якою ціною. Але на ринку очікують, що IPO може залучити близько $75 млрд при пост-мані оцінці у $1,7 трлн. За таких параметрів навіть 1% компанії коштуватиме $17 млрд.

Ось як розподіляються пакети акцій.

Ілон Маск, засновник, CEO, CTO та голова ради директорів. Загальний пакет акцій SpaceX: трохи понад 6,42 млрд акцій.

Антоніо Ґрасіас, інвестор і член ради директорів. Загальний пакет акцій SpaceX: трохи понад 503,4 млн акцій.

Ґрасіас — засновник і CEO Valor Management, давній друг Маска, про-маськівський член наглядових рад і фінансист. Він входив до ради директорів Tesla від часів стартапу і залишався там після IPO. Також він був у раді директорів сонячної компанії Маска SolarCity під час її суперечливого поглинання Tesla. Підтримував та входив до рад директорів Neuralink і The Boring Company. Ґрасіас також був серед фінансистів, які погодилися профінансувати невдалу спробу Маска ворожого поглинання OpenAI за $97 млрд на початку 2025 року.

Люк Носек, інвестор і член ради директорів. Загальний пакет акцій SpaceX: майже 33 млн акцій.

Носек — співзасновник венчурної фірми Gigafund і один із представників так званої «PayPal-мафії». На ранньому етапі він приєднався до Пітера Тіля у Founders Fund і провів першу інвестицію фонду у SpaceX. Тоді ж увійшов до ради директорів і залишається в ній донині. Gigafund також інвестує в інші компанії Маска — The Boring Company та Neuralink.

Ґвінн Шотвелл, операційна директорка (COO) SpaceX. Загальний пакет акцій SpaceX: майже 12,6 млн акцій.

Шотвелл працює в SpaceX із 2002 року, а посаду COO обіймає з 2008-го. Вона — інженерка-аерокосмійниця, яка фактично керує щоденними операціями компанії. В іншу епоху й з іншим засновником із контрольним пакетом хтось на кшталт Шотвелл, вірогідно, отримав би статус співзасновниці та більший пакет акцій. Втім, назвати її недооціненою складно. Наприклад, у 2025 році вона отримала великий пакет RSU (обмежених акцій), що підняло її загальну річну компенсацію до $85,8 млн.

Брет Джонсен, фінансовий директор (CFO). Загальний пакет акцій SpaceX: майже 9,6 млн акцій.

Брет Джонсен є CFO SpaceX із 2011 року. До цього він обіймав посади фінансового директора та фінансиста в напівпровідниковій галузі.

Айра Еренпрайс, інвестор і член ради директорів. Загальний пакет акцій SpaceX: 809 050 акцій.

Еренпрайс — засновник і керівний партнер венчурного фонду DBL Partners. Він входить до ради директорів SpaceX із лютого 2026 року, а також є членом ради Tesla.

Ренді Ґляйн, інвестор, член ради директорів. Загальний пакет акцій SpaceX: 277 800 акцій.

Ґляйн — співзасновник і керівний партнер фонду DFJ Growth.

І ще близько 400 інших венчурних інвесторів. За оцінками PitchBook, SpaceX залучила близько $30 млрд приватного капіталу від сотень інвесторів. Жоден із них не має достатньо великого пакета, щоб його потрібно було окремо розкривати, але, знову ж таки, навіть невеликий відсоток компанії може бути оцінений у мільярди доларів під час дебюту на біржі.

Джерело

TechCrunch

OpenAI тепер дозволяє застосувати можливості ШІ до ваших презентацій. Компанія оголосила, що ChatGPT став доступним у Microsoft PowerPoint. Чатбот може створювати нові слайди, а також редагувати та оновлювати вже наявні. Як і багато інших функцій ChatGPT, він працює на основі запитів природною мовою або витягує матеріали з підключених сервісів, зокрема Gmail, Outlook чи SharePoint. Функція для PowerPoint наразі перебуває в бета-версії, але більшість користувачів OpenAI уже можуть нею користуватися, включно з тими, хто має безплатний доступ, а також корпоративними передплатниками ChatGPT Business.

Подібну можливість із вересня пропонує конкурент Anthropic у своєму чатботі Claude. А Gemini від Google, своєю чергою, інтегрується з фірмовим сервісом Slides. На тлі потенційної підготовки OpenAI до надзвичайно високооцінюваного IPO логічно, що компанія намагається повторити якомога більше можливостей своїх конкурентів. PowerPoint певний час залишався винятком, адже ChatGPT вже працює в низці інших корпоративних інструментів, таких як Microsoft Excel і Google Sheets.

Джерело

Engadget

Після короткого тизеру власного чипа Thus AI компанія Anker офіційно анонсувала перші навушники з цим компонентом під час заходу Anker Day. Моделі Soundcore Liberty 5 Pro та Liberty 5 Pro Max використовують цей чип для забезпечення того, що виробник називає технологією Whisper Clear для більш чіткого голосу. Звичайний для такого класу функціонал — активне шумозаглушення (ANC), голосове керування та персоналізація звучання — тут на місці, але є й кілька унікальних інструментів. Серед них — AI Note-Taker у Liberty 5 Pro Max та зарядні кейси з екранами в обох моделей.

Спершу про те, що робить чип Thus у двох версіях Liberty 5 Pro. Він працює разом із вісьмома мікрофонами та двома датчиками кісткової провідності, щоб забезпечити оптимальну якість голосу в шумних місцях. Використовуючи модель штучного інтелекту, система відокремлює голос користувача від фонового шуму, щоб співрозмовник краще чув його під час дзвінків. Anker стверджує, що завдяки датчикам кісткової провідності система здатна вловлювати голос на нижчих рівнях гучності, якщо користувач перебуває в «помірно тихому оточенні». Чип Thus також відповідає за голосові команди: доступно близько 20 варіантів для різних дій та керування, а затримка реакції, за словами компанії, становить менше секунди.

І Liberty 5 Pro, і Liberty 5 Pro Max отримали Adaptive ANC 4.0 від Soundcore, яка за допомогою тих самих восьми мікрофонів обробляє аудіодані до 384 000 разів на секунду. Система безперервно відстежує зовнішній шум і звуки, що можуть потрапляти у вушний канал, після чого в реальному часі підлаштовує рівень шумозаглушення. Anker каже, що її алгоритм ANC може ефективно боротися з широким спектром шумів, включно з людськими голосами. Також компанія заявляє, що ефективність шумозаглушення в нових навушниках до двох разів вища, ніж у Liberty 4 Pro.

Щоб підлаштувати звук під індивідуальні особливості слуху, обидві моделі пропонують HearID 5.0. Ця функція створює персональний еквалайзер на основі короткого тесту слуху. Завдяки AI Sound Enhancement навушники застосовують відновлення аудіо, яке, за твердженням Anker, дозволяє повернути до 65% «якості», що зазвичай втрачається під час Bluetooth-компресії.

Щодо автономності, Liberty 5 Pro та Pro Max працюють до 6,5 години від одного заряду з увімкненим ANC. Разом із зарядним кейсом загальний час використання становить до 28 годин для кожної моделі. Обидві підтримують мультипоінт-підключення Bluetooth, новий стандарт Bluetooth 6.1, а також сумісні з Apple Find My і Google Fast Pair. Крім того, навушники мають захист від пилу та вологи за стандартом IP55.

Головна відмінність між двома новинками — у «розумних» кейсах. Кейс Liberty 5 Pro має 0,96-дюймовий TFT-екран на передній панелі, тоді як у Liberty 5 Pro Max встановлено значно більший 1,78-дюймовий AMOLED-дисплей. Крім того, версія Pro Max оснащена функцією AI Note-Taker, яка в застосунку Soundcore може генерувати текстові конспекти зустрічей, розпізнаючи окремих спікерів і виділяючи список дій. Ця функція недоступна в Liberty 5 Pro, але Anker пропонує AI-переклад на обох моделях. У Liberty 5 Pro переклад працює в самих навушниках, а в Liberty 5 Pro Max — і в навушниках, і через кейс.

Обидві моделі, Liberty 5 Pro та Liberty 5 Pro Max, уже доступні за ціною $170 та $230 відповідно. Liberty 5 Pro пропонують у чорному, синьому, рожевому та білому кольорах, тоді як Pro Max доступна в чорному або золотистому варіантах.

Джерело

Engadget

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

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

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

У четвер компанія кілька разів відкладала старт і зрештою спробувала запустити ракету ближче до завершення запланованого вікна. Starship і його потужний прискорювач були повністю заправлені, відлік дійшов до позначки менше ніж T-40 секунд, але проблеми з різними системами ракети та стартового майданчика змусили SpaceX кілька разів перезапускати відлік.

Гендиректор SpaceX Ілон Маск написав у X, що «гідравлічний штифт, який утримує стрілу стартової вежі, не втягнувся». Він додав, що компанія спробує знову в п’ятницю о 17:30 за місцевим часом, якщо проблему «вдасться усунути цієї ночі».

Нова версія Starship означає значне оновлення як конструкції ракети, так і наземної інфраструктури. Одні з найсуттєвіших змін стосуються двигунів Raptor третього покоління: вони забезпечують більшу тягу у більш компактному виконанні. Прискорювач Starship V3 має бути простішим для «ловлення» стартовою вежею та отримав на одну решітчасту аеродинамічну поверхню (grid fin) менше.

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

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

Джерело

TechCrunch

Rust продовжує закріплюватися як одна з найцікавіших мов для системної та бекенд-розробки. У розмові на каналі The Pragmatic Engineer інженерка з команди Rust for Android у Google та мейнтейнерка Tokio Аліс Рюль окреслила простий, але показовий «пітч» на користь Rust — особливо для тих, хто приходить із TypeScript або C++.

Rust як природне продовження для TypeScript-розробників

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

У такій зв’язці TypeScript відповідає за інтерфейс і взаємодію з користувачем, а Rust — за «важку» частину: обробку запитів, API-сервери, сервіси з високим навантаженням, де важливі стабільність і передбачуваність поведінки.

Бекенд без нічних «пожеж»

Ключовий аргумент на користь Rust у бекенді — прагнення мінімізувати кількість помилок у продакшені. Коли мова йде про вебсервери та API, будь-який критичний збій може означати нічні дзвінки, аварійні розгортання та втрату довіри користувачів.

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

Для бекенд-команд це означає:

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

Rust між TypeScript і C++: різні «пітчі» для різних світів

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

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

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

Де Rust зараз найкраще «сідає»

З огляду на описані аргументи, Rust особливо добре підходить для:

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

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

Джерело

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

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

Від чату до конвеєра: що таке AI‑workflow у 2026 році

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

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

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

GenSpark виходить на рівень 3: власний конструктор AI‑workflow

GenSpark позиціонується як all‑in‑one AI‑workspace, і в межах цієї концепції платформа запустила окремий інструмент для побудови workflow — це і є її пропозиція рівня 3. Якщо чат і спеціалізовані інструменти (на кшталт AI Slides чи AI Docs) відповідають за разові задачі, то workflows — за повторювані процеси, які мають працювати без постійної участі людини.

У центрі системи — три ключові елементи: тригери, інтеграції та AI‑логіка в середині ланцюжка.

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

По‑друге, інтеграції. Workflows у GenSpark підключаються до популярних сервісів, які формують основу робочого стеку знань і комунікацій. Серед них — Gmail, Google Calendar, Google Drive, Google Contacts, Notion, Slack, Outlook. Завдяки цьому платформа може не просто «бачити» дані, а й читати, аналізувати та оновлювати їх: підтягувати події з календаря, переглядати вхідні листи, створювати нотатки в Notion, надсилати повідомлення в Slack або формувати документи в Google Drive.

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

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

Як працює ранковий брифінг: від тригера до пріоритетного списку справ

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

Логіка такого workflow складається з кількох етапів.

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

Далі система звертається до інтегрованих сервісів. З Gmail вона забирає нові листи за ніч, з Slack — непрочитані повідомлення в обраних каналах чи від конкретних людей, з Google Calendar — події на поточний день, з Notion — відкриті задачі або проєктні сторінки, з Google Contacts — інформацію про людей, з якими заплановані зустрічі. Outlook може виступати альтернативою Gmail та Calendar для користувачів Microsoft‑екосистеми.

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

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

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

Чому «розумні» workflows — це більше, ніж Zapier з AI‑моделлю

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

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

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

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

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

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

Навіть найрозумніший workflow втрачає сенс, якщо його запуск стає фінансово болючим. Щоденний ранковий брифінг, що аналізує десятки листів, подій і нотаток, — це регулярне навантаження на AI‑моделі. У 2023–2024 роках багато користувачів стикалися з тим, що ліміти на токени чи запити швидко вичерпувалися, особливо при використанні потужних моделей на кшталт Claude Opus.

GenSpark намагається зняти це обмеження. Для платних користувачів у 2026 році платформа пропонує фактично безлімітний доступ до топових AI‑моделей — GPT, Claude, Gemini — за умови відсутності зловживань. Це означає, що користувачеві не потрібно постійно рахувати запити або економити на якості моделі для щоденних сценаріїв. У чаті можна перемикатися між режимами light, standard та ultra, причому ultra використовує Opus 4.7 як «топову» модель без жорстких лімітів.

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

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

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

Що означає перехід на рівень 3 для «одиночних команд»

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

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

Рівень 3 у цьому сенсі — проміжна ланка між «ручним» використанням AI і повністю автономними агентами. На відміну від рівня 4, де системі задають лише загальну ціль («запусти лендинг нового продукту»), workflows усе ще працюють за заздалегідь визначеним сценарієм. Але всередині цього сценарію вони мають свободу інтерпретувати дані й приймати дрібні рішення — наприклад, які листи вважати важливими, які задачі підняти вгору списку, які зустрічі потребують підготовки.

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

Висновок: коли AI стає частиною вашого робочого ранку

Рівень 3 використання AI — workflows — показує, як штучний інтелект виходить за межі «розумного чату» й починає працювати як невидимий бекенд вашого робочого дня. GenSpark, запустивши власний конструктор workflow з підтримкою тригерів, інтеграцій із ключовими сервісами та AI‑reasoning у середині, демонструє, як це може виглядати на практиці.

Ранковий брифінг — лише один, але показовий сценарій. Він поєднує час‑тригери, інтеграції з Gmail, Google Calendar, Google Drive, Google Contacts, Notion, Slack, Outlook і здатність AI перетворювати сирі листи та події на структурований, пріоритизований план дій. У поєднанні з економічною моделлю «безлімітного» доступу до топових моделей і генерації зображень це робить щоденні автоматизації не лише технічно можливими, а й фінансово доцільними.

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

Джерело

The Complete Guide to AI Agents in 2026 (And How to Actually Use Them)

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

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

Дві екосистеми в одній бригаді: «Хмарка» для логістики, кастомний софт для бою

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

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

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

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

Чому бойовим НРК не вистачає стандартних рішень

Коли Малкуш ще працював інженером і пілотом, він уже критикував загальну тенденцію ринку: виробники масово робили великі гусеничні платформи, тоді як на передовій потрібні були малі, дешеві, швидкі колісні НРК. За дев’ять місяців ситуація змінилася: з’явилися виробники, які дають більш-менш готові рішення, у тому числі з інтегрованим софтом. Частина підрозділів пішла в «Хмарку». Але ударний підрозділ «Азову» зупинився на власному ПЗ.

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

швидкість реакції системи керування;

гнучкість у налаштуванні під конкретну місцевість і сценарій;

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

інтеграція з каналами зв’язку, які постійно еволюціонують.

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

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

Власний софт як відповідь на перехід до віддаленого керування

Ще один фактор, який тисне на архітектуру ПЗ, — це перехід до віддаленого керування НРК. У підрозділі Малкуша Starlink уже став фактичним стандартом зв’язку, а прямий радіоканал розглядається як технологія, що поступово відходитиме в минуле.

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

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

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

кілька пілотів одночасно працюють із різними машинами;

забезпечується взаємодія між НРК і іншими підрозділами;

інтегруються різні канали зв’язку (Starlink, LTE, ретранслятори);

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

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

«Хмарка» як стандарт для логістики: чому там вона доречна

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

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

оператори працюють у знайомому середовищі незалежно від конкретної моделі НРК;

командири отримують уніфіковану картину руху техніки;

можна централізовано оновлювати ПЗ і протоколи безпеки.

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

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

Малі колісні НРК, Starlink і батареї: як софт зав’язаний на «залізо»

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

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

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

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

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

Командний пункт як центр тяжіння: чому бойовий софт не можна «винести в Київ»

Перехід до віддаленого керування НРК через Starlink породжує спокусу уявити собі майбутнє, де пілоти сидять у Києві чи Львові, а роботи воюють на фронті. У публічному просторі вже з’являлися історії про ППО-дрони, якими керують за тисячі кілометрів. На цьому тлі виникають ідеї залучати цивільних як пілотів, які «просто» керуватимуть джойстиком.

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

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

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

Баланс між державним стандартом і фронтовим R&D

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

З іншого боку, фронтові підрозділи, які займаються бойовими НРК, змушені рухатися швидше, ніж може собі дозволити будь-яка централізована структура. Вони експериментують із платформами, батареями, каналами зв’язку, тактиками. Їм потрібен софт, який можна змінювати так само швидко, як і «залізо».

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

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

Висновок: НРК як софтова війна

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

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

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

Джерело

Ударні НРК, віддалене керування, власний софт, маскування. Спецвипуск fpv #28 з Михайлом Малкушем

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

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

Малі колісні проти великих турельних: різні філософії війни

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

Підрозділ активно використовує малі колісні НРК типу «Гієна» та «Мангал». «Мангал» виробляє компанія «Буревій», виробник «Гієни» залишається непублічним. Обидві платформи, попри свої нюанси, Малкуш називає «робочою історією» — за умови доопрацювання під бойові реалії.

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

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

Енергетика й «Мангал»: чому доводиться подвоювати батареї

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

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

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

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

Статистика, яка б’є по міфах: сотні роботів — одиниці уражень

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

Один із виробників турельних НРК з кулеметом за чотири місяці відвантажив близько 500 комплексів. Результат — лише одне підтверджене ураження. Інший виробник, який поставив сотні подібних виробів, станом на осінь 2024 року мав нуль підтверджених уражень.

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

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

У сучасній війні будь-який великий, повільний об’єкт на відкритій місцевості стає легкою здобиччю для FPV-дронів, артилерії й протитанкових засобів. Турельні НРК з кулеметами, які рухаються зі швидкістю близько 6 км/год, фактично перетворюються на «стоячу велику ціль». Цю формулу Малкуш використовує не як метафору, а як точний опис того, як їх бачить ворог.

Швидкість 6 км/год як вирок: коли робот — це просто мішень

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

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

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

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

Дальність вогню: міфічний кілометр проти реальних 10–100 метрів

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

Практика виявилася іншою. За спостереженнями Малкуша, більшість уражень, яких вдається досягти турельним НРК, відбувається на дистанціях 10–100 метрів. Тобто фактично в межах ближнього бою, де перевага «дальності» кулемета нівелюється, а на перший план виходять маневреність, швидкість і можливість сховатися.

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

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

Маскування як забута інженерія: чому великі платформи «світяться»

Окрема лінія критики Малкуша — маскування. За його словами, виробники НРК приділяють цьому аспекту вкрай мало уваги, особливо коли йдеться про великі турельні платформи.

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

Підрозділ Малкуша вже має власний досвід роботи з великими НРК. Два їхні турельні роботи оснащені кулеметами Browning і настільки габаритні, що просто не вміщаються в автомобіль T5. Це яскравий індикатор масштабу платформи. Такі машини складно не лише сховати, а й банально доставити на позицію без привернення уваги.

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

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

Нішевий інструмент, а не універсальна зброя

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

На його думку, великі повільні НРК з кулеметами можуть бути корисними як спеціалізований інструмент у погану погоду, коли БПЛА не літають. У таких умовах зменшується загроза з боку FPV-дронів і розвідувальних коптерів, а отже, у важких платформ з’являється більше шансів вийти на позицію й відпрацювати по противнику.

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

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

Висновки: ринок НРК потребує тверезої статистики, а не красивих відео

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

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

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

Джерело

Ударні НРК, віддалене керування, власний софт, маскування. Спецвипуск fpv #28 з Михайлом Малкушем

Керівник напряму Gemini в Google Джош Вудворд понад 16 років працює в компанії, починавши ще стажером. Сьогодні він відповідає за продукти на кшталт Gemini, Google Labs та AI Studio й фактично формує бачення того, як штучний інтелект вбудовується в повсякденну роботу людей. Одна з ключових ідей, яку він просуває, — це «персональний контекст»: як змусити моделі працювати не в абстракції, а з вашими власними листами, документами, нотатками й знаннями.

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

Notebook LM: коли особисті джерела перетворюються на подкасти й майндмепи

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

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

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

Явний вибір контексту як елемент контролю

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

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

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

Від Notebook LM до Gemini: прозорий вибір джерел як стратегія

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

У класичній моделі чат‑бота користувач бачить лише поле вводу тексту. У новій парадигмі поруч із запитом з’являється ще один вимір — вибір контексту. Чи має Gemini дивитися в Gmail? Чи можна йому читати календар? Чи потрібно обмежитися лише конкретною текою в Drive?

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

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

Personal Intelligence: одна кнопка до Gmail, Calendar і Drive

Ще один важливий елемент бачення Джоша — внутрішній проєкт Google під назвою Personal Intelligence. Його задум полягає в тому, щоб за бажання користувача Gemini міг використовувати як контекст увесь масив даних із Gmail, Calendar та Drive, але підключення цього масиву відбувалося максимально просто й прозоро.

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

Для Джоша це не теоретична можливість, а щоденна практика. Він особисто вмикає Personal Intelligence, дозволяючи Gemini бачити його Gmail, Calendar і Drive. Паралельно він підтримує окремі «нотатники», синхронізовані з Gemini, куди складає власні найкращі тексти й конспекти, а також виділені фрагменти з книжок, які зберігає через Readwise. У підсумку модель працює не з абстрактним «корпусом інтернету», а з дуже конкретним зрізом його життя й мислення.

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

Чому організація даних раптом стала критичною

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

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

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

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

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

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

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

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

Якою має бути «особистість» Gemini і чому він не ваш друг

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

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

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

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

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

Від контент‑генератора до інструмента мислення

У сумі всі ці елементи — Notebook LM, Personal Intelligence, явний вибір джерел, керована особистість — формують іншу роль AI у житті користувача. Замість «машини для текстів» Gemini поступово стає інструментом мислення, який працює поверх особистого інформаційного шару.

Коли модель може:

• читати ваші документи й нотатки,
• розуміти структуру календаря й листування,
• перетворювати контент на різні формати — від подкастів до майндмепів,
• змінювати тональність від м’якої до жорстко критичної,

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

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

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

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

Персональний контекст стає новою формою цифрової грамотності. Вміння:

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

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

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

Джерело

Head of Gemini: You’re Using 5% of What Gemini Can Actually Do | Josh Woodward

OpenAI додала до Codex новий «режим цілей» (/goal), який дозволяє запускати довгі, чітко окреслені задачі й тримати модель працюючою над ними годинами або навіть днями — у застосунку, IDE-розширенні та CLI.

Що таке «режим цілей» у Codex

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

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

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

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

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

Як правильно формулювати цілі

Ефективність режиму цілей напряму залежить від якості формулювання. Рекомендації прості:

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

Якщо сформулювати ціль складно, Codex може допомогти:

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

Керування довгими задачами: steering, side-чати, пауза

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

• Steering (керування курсом)
  Можна надсилати додаткові повідомлення, щоб скоригувати напрям роботи: змінити підхід, уточнити вимоги, додати нові обмеження.

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

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

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

Масштаб: до сотні годин на одну задачу

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

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

Джерело

Run long tasks in Codex using goals — OpenAI

У 2026 році розмови про AI‑агентів і автономні системи легко затіняють більш приземлене, але критично важливе питання: де саме все це реально працює. Канал Tech With Tim у великому гайді про AI‑агентів використовує GenSpark як базову платформу — не лише тому, що це спонсор, а тому що в одному середовищі зібрані чат, інструменти, робочі процеси й агенти. На цьому тлі GenSpark виглядає як показовий приклад того, яким стає «робочий стіл» для ШІ у 2026‑му: від вибору моделей до готових слайдів із зображеннями, згенерованими GPT Image 2.

Цей матеріал розбирає GenSpark саме як all‑in‑one AI‑workspace: як сервіс виріс до 250 млн доларів річного run rate за рік, як працює єдиний інтерфейс до GPT, Claude та Gemini, чому автоматичний вибір моделі важливіший, ніж здається, і як спеціалізовані інструменти на кшталт AI Slides виводять користувача далеко за межі «просто чату».

Вибухове зростання: що означають 250 млн доларів за 12 місяців

GenSpark у відео описують як «all‑in‑one AI workspace», який за 12 місяців пройшов шлях від нуля до 250 мільйонів доларів annual run rate. Для індустрії це показник не лише агресивного зростання, а й того, що ринок швидко консолідується навколо платформ, які пропонують не один «чарівний бот», а цілу операційну систему для роботи з ШІ.

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

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

Єдиний інтерфейс до GPT, Claude, Gemini: чому це важливо

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

У типовому сценарії 2026 року це виглядає так: користувач відкриває чат GenSpark, вводить запит, а далі платформа:

1. Має доступ до кількох топових моделей — GPT, Claude, Gemini.
2. Автоматично обирає, яку модель використати для цього запиту.
3. Повертає відповідь у єдиному інтерфейсі, не змушуючи людину думати про модельні нюанси.

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

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

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

Режими light, standard, ultra: як користувач керує «потужністю» ШІ

Попри автоматичний вибір моделі, GenSpark не забирає в користувача контроль повністю. У чаті доступні три режими: light, standard і ultra. В ultra‑режимі під капотом працює Opus 4.7 — одна з топових моделей, орієнтована на глибше міркування.

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

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

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

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

Від чату до готового продукту: як працюють AI Slides, Docs, Sheets та інші інструменти

GenSpark намагається розірвати зв’язку «ШІ = чат», пропонуючи набір попередньо налаштованих інструментів, кожен із яких орієнтований на створення конкретного типу результату. У меню «New» користувач бачить AI Slides, Sheets, Docs, Developer, Video, Chat, AI Image та інші — фактично це набір «міні‑агентів», кожен із доступом до власних інструментів і робочої логіки.

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

1. Спочатку в чаті GenSpark формується великий текстовий масив — наприклад, той самий детальний розбір AI‑інструментів для коду.
2. Потім цей текст копіюється в AI Slides із інструкцією: «Створи п’ятисторінкову презентацію PowerPoint з ключовими деталями з тексту вище».
3. Далі вступають у гру режими AI Slides — creative та guide.

Creative‑режим вмикає генерацію візуалів за допомогою моделей на кшталт GPT Image 2. Замість сухих текстових слайдів користувач отримує слайди з інфографікою та ілюстраціями, згенерованими ШІ. У демонстрації окремо підкреслюється, що всі зображення на слайдах — це саме результат роботи GPT Image 2, а не статичні шаблони чи HTML‑рендеринг.

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

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

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

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

Результат — п’ять слайдів із текстом і зображеннями, які можна:

• редагувати за допомогою AI‑редактора (спростити, розширити, переформулювати),
• переглядати в режимі презентації,
• експортувати у форматах PDF, PowerPoint, Google Slides.

Таким чином, ланцюжок «чат → AI Slides → експорт» перетворює абстрактний «рівень 1» (інформація в чаті) на «рівень 2» (готовий продукт, який можна показати клієнту чи аудиторії) без ручного копіювання й верстки.

Важливо, що AI Slides — лише один із інструментів. У тому ж меню поруч живуть Sheets, Docs, Developer, Video, AI Image. Усі вони побудовані за схожим принципом: кожен інструмент — це спеціалізований агент із доступом до відповідних можливостей (таблиці, текстові документи, код, відео, зображення), який має завдання не просто «відповісти», а створити завершений артефакт.

Веб‑пошук і довгі відповіді: як чат GenSpark стає дослідницьким інструментом

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

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

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

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

• передати в AI Slides для створення презентації,
• використати в Docs для формування звіту,
• розбити на завдання в інших інструментах.

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

Безліміт і кредити: як змінюється економіка використання ШІ

Фінансова модель використання ШІ‑інструментів у 2026 році залишається болючою темою: більшість професійних користувачів змушені рахувати токени, стежити за лімітами й обмежувати себе в складних завданнях. На цьому тлі GenSpark робить кілька показових кроків.

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

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

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

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

Висновок: від «бота в браузері» до повноцінного робочого середовища

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

• єдиний інтерфейс до кількох топових моделей,
• можливість не думати про вибір моделі, але керувати «потужністю» через режими light/standard/ultra,
• інтегрований веб‑пошук, що перетворює чат на дослідницький інструмент,
• набір спеціалізованих інструментів — від AI Slides до Docs, Sheets, Developer, Video й AI Image, — які створюють не відповіді, а готові артефакти.

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

У найближчі роки саме такі платформи‑workspaces, а не окремі боти, ймовірно, визначатимуть, як виглядатиме повсякденна робота з ШІ — від першого запиту до фінального слайду.

Джерело

The Complete Guide to AI Agents in 2026 (And How to Actually Use Them) — Tech With Tim

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

Два вікенди до Google I/O: як народився голосовий Gemini для роботи з файлами

Один із найяскравіших моментів останнього Google I/O — демонстрація голосової функції Gemini, яка поводиться не як диктофон, а як повноцінний асистент, що «розуміє» ваше цифрове життя. Користувач говорить до комп’ютера, а система не просто розпізнає текст, а:

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

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

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

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

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

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

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

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

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

Для користувача це означає радикальне скорочення кількості кроків. Те, що раніше вимагало:

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

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

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

Країни, де голос уже перемагає: як змінюється поведінка користувачів Gemini

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

Причин кілька.

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

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

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

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

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

У сукупності ці фактори пояснюють, чому в окремих країнах голос уже перемагає текст як основний інтерфейс для AI. І чому Google так агресивно інвестує саме в голосові сценарії навколо Gemini.

Коли одна фраза замінює десяток кроків: прискорення роботи через голос

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновок: розмова замість рутини

Голосові можливості Gemini, які ще недавно були експериментом на вихідних, за кілька тижнів перетворюються на масову функцію: пошук по Drive і Gmail із голосу, складання листів за усними інструкціями, редагування документів у Docs Live в режимі діалогу. Паралельно Google фіксує ринки, де голос уже став основним способом взаємодії з AI, і розвиває діалектні голосові відповіді, щоб зробити цю взаємодію ще природнішою.

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

Джерело

Head of Gemini: You’re Using 5% of What Gemini Can Actually Do | Josh Woodward

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

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

Від інженера до командира: як змінюється оптика на НРК

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

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

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

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

Дві лінії роботи: оборона і наступ з роботами

Ударні НРК в «Азові» не сприймаються як екзотичний додаток до БПЛА чи артилерії. Для підрозділу Малкуша це окремий інструмент, який працює в двох чітких режимах: оборонному та наступальному.

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

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

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

Чому великі гусеничні платформи програють малим колісним

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

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

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

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

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

На цьому фоні концепція малих колісних НРК виглядає не просто альтернативою, а логічною відповіддю на вимоги сучасного поля бою.

«Гієна» і «Мангал»: чому ставка робиться на малі колеса

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

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

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

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

Подвоєні батареї як стандарт: як «Азов» переробляє серійні НРК

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

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

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

Це важливий сигнал для ринку: навіть ті виробники, які вже навчилися давати «готове рішення зі всім, що треба», як каже Малкуш, не завжди влучають у реальні потреби фронту. Підрозділи, які активно воюють, змушені брати на себе частину R&D — від батарей до зв’язку.

Ударні проти логістичних: різні ролі, різні екосистеми

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

Логістичні НРК у «Азові» працюють на державній системі «Хмарка» — це розробка Центру інновацій, фактично військова платформа управління. Вона заточена під задачі підвозу, евакуації, роботи в тилу й на лінії зіткнення, але без прямого контакту з ворогом у форматі «вогневого бою».

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

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

Від радіо до мережі: як змінюється зв’язок і тактика застосування

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

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

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

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

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

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

Роботи замість людей: переформатування оборони як стратегія

У розмові про майбутнє Малкуш формулює просту, але показову тезу: оборону треба переформатовувати так, щоб «змусити роботів воювати». Це не метафора, а практичний вектор розвитку.

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

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

Висновок: еволюція через фронтовий досвід, а не презентації

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

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

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

Джерело

Ударні НРК, віддалене керування, власний софт, маскування. Спецвипуск fpv #28 з Михайлом Малкушем