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

У розмові на каналі Silicon Valley Girl співзасновник і CEO Duolingo Луїс фон Ан розповів, як саме з’явився курс шахів, чому його зробили двоє людей без інженерного бекграунду і без знання самого предмета, та яку роль у цьому зіграли сучасні AI?інструменти. Ця історія — не просто анекдот про «магію ШІ», а показовий кейс того, як змінюється розробка освітніх продуктів і як великі компанії можуть відкривати шлях «знизу вгору» для нових ідей.

Від «це просто гра» до освітньої місії: як шахи потрапили в Duolingo

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

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

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

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

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

«У нас немає для вас інженерів»: як обмеження штовхають до AI?рішень

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

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

У цій точці вступає в гру те, що в Duolingo називають «vibe coding» — підхід, коли люди без глибоких технічних навичок використовують AI?асистентів для створення прототипів, невеликих застосунків і внутрішніх інструментів. Компанія вже встигла зробити це частиною культури: проводила окремий день, коли кожен співробітник — від HR до фінансів — мав «завібкодити» щось своє, а в Slack працюють канали «best AI practices» та «AI fails», де діляться як успіхами, так і помилками.

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

Шість місяців на прототип: як AI перетворив двох співробітників на «команду продукту»

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

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

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

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

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

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

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

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

Від прототипу до продакшну: де закінчується «vibe coding» і починається інженерія

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

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

Це розділення ролей — ще один важливий урок. AI?асистенти й «vibe coding» чудово підходять для швидкого пошуку продукт?маркет фіту, створення MVP і тестування гіпотез. Але коли йдеться про продакшн?рівень, де продуктом користуються мільйони людей щодня, класична інженерія нікуди не зникає.

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

Шахи як тест на масштаб: сім мільйонів DAU і нова роль AI в EdTech

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

Це досягнення варто розглядати в кількох площинах.

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

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

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

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

Що ця історія означає для майбутнього роботи й продуктів

Курс шахів у Duolingo — це не лише про конкретний продукт. Це про зміну парадигми того, хто й як може створювати складні цифрові сервіси.

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

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

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

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

Висновок: шахи як пролог до нової ери освітніх продуктів

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

Це не історія про те, що «ШІ зробив усе сам». Це історія про те, як ШІ змінив ролі в команді, прискорив цикл від ідеї до прототипу, дозволив bottom?up?ініціативі прорватися в ядро продукту й водночас не скасував потребу в професійній інженерії на фінальному етапі.

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

Джерело

Duolingo CEO: You Only Need 2 People and 6 Months to Build the Next Big Product

Коли засновник Duolingo Луїс фон Ан (Luis von Ahn) говорить про штучний інтелект, у нього немає ані технооптимістичного пафосу, ані апокаліптичних прогнозів. У розмові на каналі Silicon Valley Girl він описує дуже приземлену картину: AI вже глибоко вбудований у роботу компанії, але щоразу впирається в межі якості, надійності та людського судження.

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

Шахи як полігон для AI: від сирих задач до тренованої моделі

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

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

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

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

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

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

Далі команда зосередилася на мобільному досвіді. Вони знову і знову збирали прототипи інтерфейсу, ігрових сценаріїв, уроків — і показували їх Луїсу фон Ану. Лише коли він, як CEO і головний «редактор» продукту, вирішив, що курс достатньо якісний, шахи отримали місце в основному застосунку.

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

AI?кодинг: швидкий старт, болісний дебаг і чому інженери все ще незамінні

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

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

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

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

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

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

Масове генерування контенту: чому більшість AI?історій не доходить до користувача

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

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

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

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

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

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

Людське судження як останній фільтр: від мобільних прототипів до дорожньої карти предметів

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

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

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

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

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

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

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

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

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

Водночас спроба формалізувати використання AI через систему оцінювання продуктивності виявилася невдалою. Коли Duolingo тимчасово включив «AI?продвинутость» у performance review, співробітники почали ставити логічне запитання: чи очікує від них керівництво використання AI «заради галочки», навіть там, де це не додає цінності?

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

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

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

Майбутнє AI в освіті: менше магії, більше ремесла

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

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

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

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

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

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

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

Джерело

Duolingo CEO: You Only Need 2 People and 6 Months to Build the Next Big Product — Silicon Valley Girl

У розмові з YouTube?каналом Silicon Valley Girl співзасновник і CEO Duolingo Луїс фон Ан розкрив, як компанія інтегрує штучний інтелект не лише в продукт, а й у щоденну роботу співробітників. Мова йде не про черговий «AI?маніфест», а про досить приземлену, але послідовну культуру: від внутрішнього «золотого правила» до обов’язкового дня vibe coding для всієї компанії, Slack?каналів з провалами та саморобних дашбордів KPI.

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

Золоте правило Duolingo: AI тільки якщо виграє учень

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

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

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

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

Це створює помітний контраст із компаніями, де штучний інтелект стає новою метрикою лояльності: «доводь, що ти достатньо AI?native, інакше відстанеш». У Duolingo AI — це інструмент, а не культ.

День загального vibe coding: коли HR і фінанси теж пишуть код

Один із найяскравіших елементів AI?культури Duolingo — це спеціальний день, коли буквально кожен співробітник мав «vibe code» щось своє. Не лише інженери, а й люди з HR, фінансів та інших нефахових з точки зору розробки команд.

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

Такий формат вирішує одразу кілька завдань.

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

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

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

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

Slack?канали «best AI practices» і «AI fails»: як нормалізувати помилки

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

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

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

Така відкритість має кілька наслідків.

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

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

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

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

Саморобні дашборди й міні?додатки: як AI розширює повноваження «нетехнарів»

Один із найпомітніших практичних ефектів такої культури — те, як співробітники Duolingo почали використовувати AI для створення власних інструментів. Усередині компанії стало майже нормою, що люди самі будують дашборди для своїх KPI та невеликі внутрішні застосунки.

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

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

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

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

Коли AI стає метрикою: чому Duolingo відмовився від «обов’язкового AI» у performance review

На певному етапі Duolingo спробував формалізувати важливість AI?інструментів ще жорсткіше: використання штучного інтелекту включили до системи performance review. Співробітникам надіслали мемо, де прямо говорилося, що частина оцінки їхньої роботи залежатиме від того, як вони застосовують AI.

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

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

Цей епізод важливий із кількох причин.

По?перше, він показує, наскільки легко навіть прогресивні компанії можуть скотитися до AI?формалізму: коли технологія стає не інструментом, а KPI. Включення AI до performance review виглядає логічним кроком, але на практиці швидко створює перекоси.

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

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

Як ця культура впливає на продукт: від мов до шахів

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

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

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

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

Висновок: AI як інфраструктура, а не як ідеологія

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

внутрішнє «золоте правило», яке змушує кожне AI?рішення виправдовувати себе перед користувачем, а не перед трендами;
відмова від формального обліку «AI?заміщуваних» задач, щоб не перетворювати технологію на інструмент тиску;
масовий день vibe coding, що знімає бар’єр між технічними й нетехнічними ролями;
Slack?канали, де успіхи й провали з AI стають колективним досвідом, а не приватною історією;
готовність відкотити рішення про включення AI до performance review, коли воно починає стимулювати використання «для галочки».

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

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

Джерело

Duolingo CEO: You Only Need 2 People and 6 Months to Build the Next Big Product

У світі корпоративних LLM?агентів одна з найскладніших задач — не стільки навчити модель відповідати клієнтам, скільки надійно оцінювати, чи дотримується вона бізнес?політик. У воркшопі на каналі AI Engineer співзасновник і CEO Agenta AI Махмуд Мабрук показує, як побудувати й оптимізувати LLM?«суддю» для авіалінійного сапорт?агента, використовуючи алгоритм GEPA та бібліотеку GPA. На відміну від загальних «якість відповіді: 1–5» оцінювачів, тут фокус — вузький: бінарне судження, чи порушив агент політику авіакомпанії в конкретному діалозі.

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

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

У більшості команд, що запускають LLM?агентів у продакшн, типовий сценарій виглядає однаково. З’являється потреба «моніторити якість», хтось підключає готовий «LLM?as?a?judge» з бібліотеки — часто з розмитою метрикою на кшталт «галюцинація / не галюцинація» — і інтегрує його в observability?дашборд. Графіки виглядають пристойно, але користувачі скаржаться, що агент працює погано. При розборі з’ясовується, що оцінювач майже нічого корисного не бачить.

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

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

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

Початковий «людяний» промпт: припускати відповідність, доки не доведено протилежне

Відправною точкою для оптимізації стає так званий seed judge — початковий промпт, який описує роль LLM?судді й формат відповіді. У цьому воркшопі він спеціально спроєктований так, щоб імітувати типову поведінку людини?рев’юера в сапорт?команді.

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

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

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

Коли промпт?інженіринг не рятує: 61% точності і майже повна сліпота до порушень

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

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

Seed?джадж позначає близько 98% кейсів як compliant. Тобто майже завжди вважає, що агент діяв за правилами. Враховуючи, що в обробленому датасеті приблизно 62% трейсів справді compliant, а 38% — non?compliant, така поведінка означає катастрофічно низький recall по порушеннях. Модель майже не бачить non?compliant випадків, систематично даючи хибно негативні оцінки.

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

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

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

GEPA та GPA: як працює оптимізація LLM?судді

Для виходу за межі слабкого seed?джаджа використовується GEPA — алгоритм оптимізації промптів, реалізований у бібліотеці GPA. Запуск відбувається через API Optimize Anything, який бере на себе всю рутину: від генерації кандидатних промптів до їх оцінки на датасеті.

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

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

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

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

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

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

Чому Парето?відбір важливіший за «середню оцінку»

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

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

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

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

Від слабкого seed?джаджа до надійного інструменту контролю

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

Seed?суддя, спроєктований за принципом «комплаєнс за замовчуванням», показує близько 61% точності й майже повністю ігнорує 38% non?compliant трейсів, позначаючи 98% кейсів як compliant. Це типовий приклад систематичного зсуву: модель «боїться» назвати порушення, якщо не може чітко його сформулювати, і в результаті перетворюється на джаджа, який майже ніколи не піднімає тривогу.

Оптимізація через GEPA та GPA’s Optimize Anything API змінює ситуацію принципово. Замість того, щоб покладатися на одну людську інтуїцію при написанні промпта, система автоматично досліджує широкий простір можливих інструкцій і конфігурацій, відбираючи ті, що краще узгоджуються з людською розміткою на реальних даних. При цьому Парето?відбір гарантує, що фінальний суддя буде не просто «середньо точним», а стійким до різних сценаріїв порушень політики.

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

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

Висновок: калібрований LLM?суддя — це не про «кращий промпт», а про системну оптимізацію

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

Щоб отримати LLM?оцінювача, якому можна довіряти, потрібен повноцінний цикл оптимізації, заснований на людській розмітці. GEPA в поєднанні з GPA’s Optimize Anything API пропонує саме такий підхід: старт із початкового промпта, ітеративне генерування кандидатів через мутації та мерджинг, систематична оцінка на датасеті й відбір за Парето?фронтом, який забезпечує стійкість до різних сценаріїв.

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

Джерело

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

У розробці агентів на базі великих мовних моделей (LLM) з’явився новий «стандарт»: оцінювати якість відповідей за допомогою іншої моделі — LLM-as-a-judge. На цьому будується ціла екосистема observability?платформ і бібліотек для «автоматичних» метрик на кшталт hallucination score. Але коли такі оцінки погано відкалібровані, вони не просто марні — вони небезпечні.

У своєму виступі на каналі AI Engineer Махмуд Мабрук, співзасновник і CEO Agenta AI, open?source LLMOps?платформи для побудови та оцінювання LLM?застосунків, демонструє це на практичному кейсі: побудові LLM?судді для клієнтського підтримувального агента авіакомпанії на базі бенчмарку Towbench. На цьому прикладі добре видно, чому універсальні «галюцинаційні» метрики вводять команди в оману, як правильно формулювати цілі оцінювання і чому прості бінарні метрики, підкріплені експертною розміткою, працюють краще за «розумні» шкали від 1 до 5.

Коли дашборд каже «все добре», а користувачі — ні

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

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

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

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

Чому LLM?оцінювання має починатися з бізнес?цілей, а не з «галюцинацій»

Ключова помилка багатьох команд — спроба застосувати універсальні, абстрактні метрики до конкретних бізнес?агентів. «Hallucination rate», «overall quality», «helpfulness score» звучать науково, але в реальному продукті вони часто нічого не говорять про те, що насправді важливо бізнесу.

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

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

Це особливо важливо як в офлайн?циклі розробки, так і в онлайн?моніторингу.

В офлайні швидкість розвитку агента визначається тим, наскільки швидко команда може пройти цикл: змінити промпт або архітектуру, прогнати A/B?оцінювання, зрозуміти, що стало краще чи гірше, і повторити. Людська розмітка дає високу якість, але кожна ітерація дорога й повільна. LLM?суддя може прискорити цикл, але лише за умови, що його оцінки добре корелюють із людськими. Якщо ж ні — команда швидко рухається в нікуди.

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

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

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

Кейс із Towbench особливо показовий тим, що він змушує дивитися на помилки агента не як на щось монолітне, а як на набір різних вимірів. У бенчмарку використовується агент авіакомпанії з доступом до інструментів і складною політикою, а також 599 розмовних трейсів із анотаціями. Після пост?обробки кожен трейс має бінарну мітку «комплаєнтний / некомплаєнтний» і текстове пояснення, чому саме відповідь вважається такою. Приблизно 62% трейсів — комплаєнтні, 38% — ні.

Щоб зрозуміти, як насправді ламається агент, потрібна не модель, а людина — предметний експерт. Саме він має пройтися по трейсах, залишити вільні коментарі, що пішло не так, а потім поступово згрупувати ці коментарі в класи помилок. Такий підхід до error analysis добре описаний у спільноті AI?інженерів і виявляється набагато продуктивнішим, ніж одразу вигадувати абстрактні метрики.

У випадку з авіаційним агентом цей аналіз вивів щонайменше чотири різні типи помилок.

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

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

По?третє, доставка інформації. Агент може виконати дію в бекенді, але не повідомити про це клієнта або зробити це так, що користувач не розуміє, що саме змінилося. З погляду системи все гаразд, але з погляду користувача — ні.

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

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

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

Чому бінарні метрики кращі за шкали 1–5 — і для людей, і для моделей

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

Навіть для людських анотацій узгодити шкалу 1–5 виявляється складно. Двоє експертів можуть погодитися, що відповідь «неправильна», але один поставить 2, інший — 3. Різниця в інтерпретації шкали, контекст, настрій — усе це вносить шум. Коли ж до цього додається LLM?суддя, який має навчитися відтворювати таку нечітку шкалу, завдання стає ще важчим.

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

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

Ця простота критично важлива для калібрування. Навіть з бінарною класифікацією побудувати LLM?суддю, який добре узгоджується з людськими анотаціями, виявляється нетривіальним завданням. Додавання додаткових рівнів складності у вигляді шкал 1–5 лише погіршує ситуацію.

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

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

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

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

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

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

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

Від ручної розмітки до автоматичного «data flywheel»

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

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

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

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

Висновок: менше магії, більше дисципліни

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

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

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

Джерело

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

Онлайн-курси з машинного навчання давно стали стандартним стартом для тих, хто хоче увійти в AI?інженерію. Але більшість програм або застрягають на теорії, або взагалі не торкаються продакшену й MLOps. На основі аналізу понад 50 курсів авторка каналу Marina Wyss – AI & Machine Learning виокремила п’ятірку програм, які найкраще закривають реальні потреби майбутнього ML?інженера.

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

Щоб уникнути вузькоспеціалізованих або надто дорогих варіантів, до списку потрапили лише:

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

Кожен курс оцінювали за чотирма критеріями, кожен — від 0 до 2,5 балів (максимум 10):

1. Повнота (comprehensiveness)
   Чи є і алгоритми, і продакшен / MLOps? Чи це лише теорія або тільки деплой?

2. Інтерактивність
   Скільки реального коду й практики проти пасивних лекцій? Чи є тести, завдання, проєкти?

3. Ціна
   Наскільки вигідна модель оплати з огляду на обсяг і якість контенту?

4. Рейтинги / відгуки
   Формальні оцінки на платформах або, якщо їх немає, — сила спільноти й якість відгуків.

Далі — п’ятірка курсів, які набрали найвищі сумарні бали.

Класика для фундаменту: Machine Learning Specialization (Coursera)

Підсумковий бал: 8,0 / 10
Сильна сторона: глибоке розуміння алгоритмів
Слабка сторона: повна відсутність продакшену

Спеціалізація Ендрю Нґ на Coursera — один із найвідоміших курсів з ML у світі: понад 4,8 млн слухачів і рейтинг 4,9/5. Програма складається з трьох курсів:

• Курс 1:
• лінійна регресія
• логістична регресія
• базові нейронні мережі

• supervised learning

• Курс 2:

• глибші нейронні мережі
• оптимізація
• регуляризація

• вступ до TensorFlow

• Курс 3:

• unsupervised learning (k-means, PCA)
• рекомендальні системи
• короткий вступ до reinforcement learning

Оновлена версія повністю на Python з використанням NumPy, scikit?learn, TensorFlow. Сильний бік — інтуїтивне пояснення математики й того, чому алгоритми працюють саме так.

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

• деплой моделей;
• MLOps;
• моніторинг, CI/CD, продакшен?пайплайни.

Оцінка за критеріями:

• Повнота: 1,5 — глибока теорія, нуль продакшену.
• Інтерактивність: 2,0 — ноутбуки, квізи, лабораторні, але без проривних форматів.
• Ціна: 2,0 — $49/міс, без безкоштовного аудиту.
• Рейтинги: 2,5 — майже ідеальний рейтинг і мільйони слухачів.

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

Безкоштовний MLOps?хаб: Made with ML

Підсумковий бал: 8,1 / 10
Сильна сторона: реальний продакшен?лайфцикл
Слабка сторона: слабка структурованість фундаменту

Made with ML — безкоштовний ресурс із понад 45 000 зірок на GitHub, створений Гоку Махандасом, який роками допомагав великим компаніям запускати ML?системи. Проєкт складається з двох частин:

1. Foundations
2. Python, NumPy, Pandas
3. PyTorch
4. лінійна та логістична регресія
5. базовий deep learning

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

1. Основний курс з MLOps
   Покриває повний продакшен?цикл:

2. дизайн продукту

3. підготовка даних
4. тренування моделей
5. експеримент?трекінг
6. тюнінг гіперпараметрів
7. оцінка моделей
8. деплой та подальші етапи

Формат — текст + кодові ноутбуки. Немає:

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

Є можливість приєднатися до живого когорту (~$150) з одноденним інтенсивом, GPU?доступом і спільнотою, але основний контент залишається безкоштовним.

Оцінка за критеріями:

• Повнота: 2,1 — відмінний MLOps, але алгоритми не покриваються настільки глибоко, щоб бути єдиним джерелом.
• Інтерактивність: 1,5 — є ноутбуки, але мало структурованих вправ.
• Ціна: 2,5 — повністю безкоштовно.
• Рейтинги: 2,0 — немає формальних оцінок, але сильна GitHub?спільнота й позитивні відгуки.

Це один із найкращих безкоштовних ресурсів, якщо ціль — зрозуміти MLOps і продакшен?ML, а не вивчати алгоритми з нуля.

Практика алгоритмів: Machine Learning Scientist (DataCamp)

Підсумковий бал: 8,6 / 10
Сильна сторона: широка й практична робота з алгоритмами
Слабка сторона: немає продакшену

Кар’єрний трек Machine Learning Scientist на DataCamp — це:

• 26 курсів
• 85 годин інтерактивного контенту

Фокус — на тому, як застосовувати алгоритми на практиці. Програма охоплює:

• supervised learning зі scikit?learn
• unsupervised learning
• лінійні класифікатори
• деревоподібні моделі (tree?based)
• deep learning з PyTorch
• NLP
• feature engineering
• зниження розмірності
• тюнінг гіперпараметрів
• аналіз часових рядів
• валідація моделей
• розподілене ML зі Spark

Формат DataCamp — коротке відео + одразу код у браузерному IDE. Це підтримує темп і зменшує ризик «відключитися» на довгих лекціях. Додатково:

• інтегрована AI?допомога для підказок;
• три проєкти (агропрогнозування, кластеризація, прогнозування).

Підписка коштує приблизно $35/міс і відкриває доступ до всієї платформи, не лише до цього треку.

Оцінка за критеріями:

• Повнота: 1,7 — широкий спектр алгоритмів, але немає деплою й MLOps.
• Інтерактивність: 2,5 — постійне кодування, сильна сторона DataCamp.
• Ціна: 2,2 — конкурентна вартість за обсяг контенту й доступ до всієї платформи.
• Рейтинги: 2,2 — 4,9/5 у треку та хороші загальні відгуки про DataCamp.

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

MLOps у форматі «зроби сам»: Machine Learning Engineer (DataCamp)

Підсумковий бал: 8,7 / 10
Сильна сторона: практичний MLOps і продакшен?інфраструктура
Слабка сторона: алгоритми майже не розкриті

Кар’єрний трек Machine Learning Engineer на DataCamp — це:

• 14 курсів
• близько 44 годин інтерактивного контенту

Фокус — майже повністю на продакшені:

• основи supervised learning (коротко, для контексту);
• Docker для контейнеризації;
• MLflow для експеримент?трекінгу й реєстру моделей;
• побудова data pipelines (ETL, ELT);
• data version control;
• CI/CD для ML;
• моніторинг моделей у продакшені.

Протягом треку слухачі працюють над проєктами:

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

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

Оцінка за критеріями:

• Повнота: 1,9 — сильний MLOps, але алгоритми залишаються поза фокусом.
• Інтерактивність: 2,5 — той самий hands?on формат DataCamp.
• Ціна: 2,2 — ті ж ~$35/міс за доступ до всієї платформи.
• Рейтинги: 2,1 — 4,7/5 у треку та хороші загальні оцінки.

У поєднанні з треком Machine Learning Scientist DataCamp фактично дає повний шлях: від алгоритмів до продакшену — за умови, що слухач готовий пройти обидві програми.

Все в одному й безкоштовно: ML ZoomCamp

Підсумковий бал: 8,8 / 10
Сильна сторона: баланс теорії й продакшену в одному курсі
Слабка сторона: вища «планка входу» для самостійного формату

ML ZoomCamp — чотиримісячний курс (~160 годин), який поєднує алгоритми й продакшен в одній програмі. Це єдиний курс у добірці, що системно закриває обидві частини ролі ML?інженера.

Алгоритмічна частина:

• регресія
• класифікація
• метрики оцінки
• дерева рішень
• ансамблеве навчання
• нейронні мережі
• deep learning з TensorFlow і PyTorch

Математика тут не така глибока, як у курсі Ендрю Нґ, але покриває необхідний набір алгоритмів із реалізацією на Python.

Продакшен?частина:

• збереження моделей (model persistence)
• побудова API з FastAPI
• контейнеризація з Docker
• serverless?деплой на AWS Lambda
• оркестрація з Kubernetes

У курсі є активна Slack?спільнота з тисячами учасників, які допомагають одне одному з домашніми завданнями, проєктами та кар’єрними питаннями. Лекції доступні на YouTube, матеріали — у відкритому доступі на GitHub.

Важливі нюанси:

• Живий когорт запускається приблизно раз на рік; дати на 2026 рік ще не оголошені.
• У self?paced форматі:
• немає перевірки домашніх завдань;
• немає peer?review;
• немає сертифікату;
• інтерктивність значно нижча.

Крім того, слухач самостійно налаштовує середовище:

• Python;
• Docker;
• інші інструменти.

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

Оцінка за критеріями:

• Повнота: 2,2 — найсильніший баланс теорії й продакшену в одному курсі.
• Інтерактивність: 2,1 — висока в когорті (домашки, проєкти, peer?review), низька в self?paced.
• Ціна: 2,5 — повністю безкоштовно.
• Рейтинги: 2,0 — немає формальних оцінок, але є позитивний фідбек від випускників і активна спільнота.

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

Як комбінувати курси залежно від цілі

Головний висновок: одного ідеального курсу не існує. Кожен із п’ятірки закриває свою частину пазла:

• Для фундаменту алгоритмів
• Machine Learning Specialization (Coursera)

• Machine Learning Scientist (DataCamp)

• Для MLOps і продакшену

• Made with ML

• Machine Learning Engineer (DataCamp)

• Для балансу «все в одному»

• ML ZoomCamp

Оптимальна стратегія для тих, хто цілиться в роль ML?інженера:

• поєднати теоретично сильний курс (Coursera або DataCamp Scientist)
• з практичним MLOps?курсом (Made with ML, DataCamp Engineer або ML ZoomCamp).

Джерело

YouTube: I Tried 50 Machine Learning Courses: Here are The BEST 5

Дискусія навколо Model Context Protocol (MCP) та командних інтерфейсів (CLI) різко загострилася після того, як CTO Perplexity оголосив про перехід від MCP до API та CLI, а CEO Y Combinator підтримав тренд, виклавши набір із 28 skills для Claude Code без жодного MCP. Канал Beer::Сode на цьому тлі розбирає, як обидва підходи працюють «під капотом» і де кожен із них справді має сенс.

Як MCP роздуває контекст і чому це дорого

MCP задуманий як універсальний протокол, що дозволяє AI-агентам підключатися до зовнішніх сервісів — GitHub, Gmail, Slack тощо. Кожен MCP-сервер реєструє набір інструментів, і кожен інструмент описується JSON-схемою: назва, опис, параметри, типи.

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

Claude Code частково зняв це обмеження у версії 2.1.7: інструменти MCP підвантажуються «по запиту», а не висять у контексті постійно. Але це радше виняток: Cursor і VS Code мають лише часткові рішення, а GitHub Copilot та інші досі завантажують усе одразу.

Навіть із оптимізацією залишається дві фундаментальні проблеми MCP:

1. Вартість токенів при довготривалому використанні.
   На прикладі запиту «покажи мої pull requests»:

2. MCP-виклик:

   • схема інструмента — приблизно 800 токенів;
   • JSON-RPC-обгортка — близько 50 токенів туди і 50 назад;
   • плюс результат.

   Разом — орієнтовно 1200 токенів.

3. Надійність з’єднання.
   MCP-сервер — це окремий процес, локальний або віддалений, який проксуює запити до API. Це:

4. додаткова точка відмови (якщо сервер впав, завис, не встановив TCP-з’єднання — агент нічого не отримає);
5. два стрибки замість одного: агент ? MCP ? API і назад тією ж дорогою.

CLI, натомість, — це локальний бінарник, який напряму викликає API. Менше шарів — менше шансів на збій.

Чому CLI виявився дешевшим і простішим

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

Моделі навчалися на відкритих репозиторіях і документації, де приклади CLI-команд для GitHub, AWS, Docker та інших інструментів зустрічалися мільйони разів. Для таких популярних CLI агент уже «знає» синтаксис і може одразу сформувати команду без додаткових підказок.

Якщо CLI знайомий моделі:

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

Разом — близько 315 токенів.

Якщо CLI незнайомий:

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

Кожен крок — орієнтовно 50–200 токенів. Навіть у такому сценарії сумарно виходить близько 515 токенів — удвічі дешевше за MCP.

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

Встановлення: npm vs одна команда

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

• MCP-сервер:
• npm install;
• налаштування токенів у змінних середовища;
• перезапуск coding-агента, щоб підтягнути конфіг.
• CLI:
• одна команда встановлення;
• нативна авторизація;
• інструмент готовий до роботи.

Це робить CLI привабливим для швидкого підключення інструментів до AI-агентів без додаткової інфраструктури.

Де MCP незамінний: persistent connection і складні сценарії

Попри вищу вартість і додаткові точки відмови, MCP має одну ключову перевагу — постійне з’єднання (persistent connection).

CLI працює за схемою «запит–відповідь–завершення». Для одноразових операцій це ідеально: створити pull request, задеплоїти сервіс, прочитати пошту.

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

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

У таких випадках MCP дає:

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

Звідси просте робоче правило:

• потрібне постійне з’єднання в реальному часі (браузер, canvas, моніторинг) — має сенс MCP;
• одноразові запити «зробив і забув» — логічніше CLI.

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

Не всі сервіси мають готовий CLI, і не для всіх існують MCP-сервери. Є кілька шляхів, як це обійти.

Варіант 1: написати CLI самостійно

Приклад: сервіс Focus To-Do для управління задачами.

• Готового MCP-сервера немає.
• CLI теж відсутній.

Рішення:

1. Зробити реверс-інжиніринг: подивитися файли застосунку, проаналізувати запити.
2. Разом із Claude Code розібрати формат даних і ендпоінти.
3. На основі цього згенерувати CLI на Python — близько 800 рядків коду.
4. Підключити його як плагін у Claude Code зі skill’ом для Focus To-Do.

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

Варіант 2: CLI Anything для open source

Інший шлях — використати репозиторій CLI Anything:

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

Обмеження очевидне: це працює лише для відкритих репозиторіїв.

Безпека: ширший доступ CLI проти обмежених MCP-інструментів

З точки зору безпеки CLI і MCP поводяться по-різному:

• MCP:
• кожен інструмент має чітко описані операції й параметри;
• дозволи обмежені рамками конкретного tool’а;

• легше гарантувати, що агент не вийде за межі дозволеного.

• CLI через Bash:

• це довільна bash-команда;
• агент потенційно отримує значно ширший доступ до системи.

Щоб це контролювати, у CLI-підході вводять структурні обмеження:

• GET-операції можуть бути дозволені напряму;
• POST/DELETE — лише з явним підтвердженням;
• критичні дії — через додаткові перевірки.

Це не обов’язково безпечніше, ніж просто прописати в skill’і «ніколи не видаляй дані», але це інший тип трейд-офу, який потрібно усвідомлено приймати.

Практичний висновок: комбінувати, а не протиставляти

Позиція Perplexity про перехід від MCP до CLI має під собою технічні підстави:

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

Водночас MCP займає свою нішу там, де потрібне:

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

Робочий підхід, який пропонується:

• CLI — скрізь, де це можливо: одноразові операції, інтеграції з API, автоматизація рутинних дій.
• MCP — там, де без постійного з’єднання ніяк: браузер, Figma, canvas, real-time моніторинг.

Практична рекомендація для команд, що вже працюють із MCP:

1. Подивитися, які MCP-сервери зараз підключені.
2. Для кожного перевірити, чи існує CLI-альтернатива.
3. Замінити хоча б один MCP на CLI і порівняти вартість, надійність і зручність.

Source

https://www.youtube.com/watch?v=9Tu8usEv8EU

Епоха, коли достатньо було зазубрити сотню задач з LeetCode, стрімко завершується. Формати технічних співбесід розійшлися в різні боки: від повної заборони ШІ до інтерв’ю, де використання AI — обов’язкова умова. На Pragmatic Summit, де зібралися сотні інженерів і хіринг-менеджерів, обговорювали саме це — і їхні висновки, які систематизувала Marina Wyss – AI & Machine Learning, показують: готуватися «як завжди» вже небезпечно.

Фрагментована реальність: чому більше не існує єдиного формату

Ринок технічних інтерв’ю сьогодні не просто змінився — він розколовся. Дані CoderPad за 2026 рік показують, що:

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

Паралельно:

• 43% технічних оцінювань усе ще містять алгоритмічні задачі у стилі LeetCode;
• 78% розробників в опитуванні HackerRank вважають, що такі тести не відображають реальну роботу;
• 56% прямо кажуть, що алгоритмічні питання взагалі не релевантні їхнім щоденним задачам.

Натомість зростає частка:

• парного програмування;
• системного дизайну;
• симуляцій реальних сценаріїв (кожен формат — на рівні 30–38% оцінювань).

Результат: компанія А може вимагати «чистий» код без ШІ за 45 хвилин, компанія B — дати домашнє завдання з явним закликом користуватися Claude чи Cursor, а компанія C — будувати оцінку майже виключно на вашому GitHub. Це не варіації одного іспиту, а чотири різні ігри з різними правилами.

Чотири основні режими технічних співбесід

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

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

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

Мета — зберегти старий сигнал: чи здатна людина написати коректний код з нуля під тиском часу.

Водночас саме в цій моделі найсильніше відчувається «AI-хаос» у воронці найму:

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

У відповідь компанії вводять додаткові рівні верифікації:

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

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

2. AI-native інтерв’ю: коли ШІ — частина завдання

На протилежному полюсі — компанії, які не просто дозволяють ШІ, а очікують, що кандидат вміє з ним працювати.

Прикладом став пілот Meta з AI-enabled coding interviews, де кандидатам прямо на співбесіді надають AI-асистента. Логіка проста: якщо ШІ — частина реальної роботи, оцінювати людину без нього не має сенсу.

Але тренд іде ще далі. Поширюється двоетапна модель:

1. Домашнє завдання з явним дозволом (або вимогою) використовувати ШІ.
   Кандидат може залучати Claude, Cursor, Codex чи інші інструменти.

2. Живе парне програмування на основі цього коду.
   На цьому етапі перевіряють:

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

Фокус зміщується з «написати все самостійно» на:

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

У світі, де ШІ за секунди видає тисячі рядків, ключовою стає не швидкість набору, а здатність:

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

AI-native формат не означає «AI усе зробить за вас». Він перевіряє, чи людина не віддає мислення «на аутсорс» моделі, а керує нею, перевіряє й розуміє.

3. Портфоліо як інтерв’ю: GitHub замість live-coding

Ще один помітний тренд — зміщення фокусу з абстрактних задач на реальні проєкти кандидата.

У такому форматі:

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

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

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

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

4. «ML з нуля»: коли фундамент усе ще вирішує

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

• логістична регресія;
• K-means;
• інші класичні методи.

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

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

У цій ніші інтерв’ю змінюються повільніше, і «ML з нуля» залишається окремим, стабільним режимом оцінювання.

Що шукають хіринг-менеджери незалежно від формату

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

T-shaped інженер

Ключове поняття, яке часто звучить, — T-shaped engineer:

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

Очікування «я займаюся тільки фронтендом» або «я лише бекенд» дедалі частіше вважаються нереалістичними. Від інженера чекають:

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

Продуктове мислення

Важливим стає не лише «чи можеш ти це реалізувати», а й:

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

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

Комфорт з невизначеністю й хаосом

Особливо для ролей, пов’язаних з AI, де:

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

Цінуються люди, які:

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

Комунікація

Незалежно від формату інтерв’ю, завжди перевіряється:

• чи можете ви пояснити свої trade-off’и;
• чи здатні аргументувати рішення;
• чи вмієте проговорити ризики й обмеження.

Якщо мислення не можна донести, воно практично не існує для співрозмовника.

Найефективніша стратегія: не вгадувати, а запитати

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

Робоча формула запиту до рекрутера може виглядати так:

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

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

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

Якщо у відповідь — лише розмиті формулювання на кшталт «production-level coding skills», варто уточнювати, що це означає на практиці: LeetCode, рефакторинг, дебаг, системний дизайн тощо. Іноді за красивими словами ховається звичайний алгоритмічний раунд.

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

Як готуватися, якщо інтерв’ю ще немає

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

Оптимальна стратегія:

1. Будувати реальні проєкти з використанням ШІ — і розуміти кожен рядок коду.
   Це:
2. готує до форматів «домашнє завдання + розширення на співбесіді»;
3. створює портфоліо для GitHub-орієнтованих компаній;
4. тренує AI-native навички: постановку задачі, перевірку, дебаг, рефакторинг;

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

6. Підтримувати базову форму в алгоритмах і структурах даних.
   Не обов’язково «гріндити» по 5 годин на день, але:

7. LeetCode Medium не має ставати катастрофою;
8. регулярна практика допомагає не «випасти» з класичного формату.

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

Джерело

YouTube: Coding interviews are completely different now (here’s why)

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

Йдеться не тільки про Іран. Центральна система відеоспостереження цієї країни побудована на російських технологіях, які виросли з колишнього сервісу розпізнавання облич FindFace у «ВКонтакте». Ті самі розробники згодом працювали за контрактами ФСБ, а Росія сама вибудувала гігантську мережу камер, включно з під’їздами житлових будинків. Усе це сьогодні розглядається як потенційна «дірка» в обороні, якою можуть скористатися іноземні спецслужби. Для України, де масово встановлюють китайські камери на кшталт Hikvision, уроки з Ірану та Росії виглядають особливо тривожно.

200 літаків в небі: як працює сучасна координація ударів

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

Ролі партнерів були чітко розведені. США зосередилися на ударах по суто військових цілях: інфраструктурі, об’єктах ППО, складах, базах. Ізраїль, своєю чергою, спрямовував удари по об’єктах військово?політичного керівництва Ірану — центрах прийняття рішень, штабах, вузлах управління. Такий поділ завдань не випадковий: він відображає як політичні обмеження, так і різну спеціалізацію сторін.

Ключовим елементом підготовки став не лише збір розвідданих із супутників, БПЛА та агентурних джерел. Вирішальну роль відіграв контроль над очима самого Ірану — його централізованою системою відеоспостереження.

Злам «великого ока»: як відеоспостереження перетворилося на вразливість

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

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

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

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

Російська мережа камер: інструмент стеження чи подарунок для чужих спецслужб

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

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

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

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

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

Український контекст: китайські камери як потенційний «троянський кінь»

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

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

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

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

контролювати, які оновлення отримує система і коли;

вбудовувати приховані механізми доступу;

збирати метадані про роботу мережі;

використовувати вразливості, про які знає лише він.

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

Від інструмента контролю до стратегічної вразливості

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

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

майже реальний час спостереження за ключовими об’єктами;

історичні дані про переміщення людей і техніки;

можливість виявляти приховані маршрути та об’єкти;

інструмент для планування точкових ударів по військових і політичних цілях.

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

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

Що означає іранський кейс для української стратегії безпеки

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

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

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

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

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

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

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

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

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

Джерело

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

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

Як одна фраза про LEGO підняла капіталізацію Rheinmetall

Армін Паппергер публічно заявив, що в українських FPV-дронах «немає нічого інноваційного». Його цитата стала мемом: «Це просто гра з LEGO. Яка тут інновація з боку України? У них немає якогось технологічного прориву. Вони створюють інновацію за допомогою своїх маленьких безпілотників і кажуть: “Вау, і це чудово. Ну і гаразд, але це не технологія Lockheed Martin, General Dynamics чи Rheinmetall”».

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

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

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

Skynex, «Пума» і 130-мм гармата: як виглядає інновація по Rheinmetall

Щоб зрозуміти контраст, варто подивитися, що саме Rheinmetall вважає своїми інноваційними продуктами. У переліку ключових розробок компанії — бойова машина піхоти Puma (проєкт ще з 2000-х), платформи на кшталт Lynx, нові танкові концепти та системи протиповітряної оборони.

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

Ще один великий проєкт Rheinmetall — нова 130мм танкова гармата. Це типова для оборонної індустрії історія: багаторічні інвестиції, складні матеріали, високоточна механіка, інтеграція в перспективні танкові платформи. Для традиційного ВПК саме такі речі й є «справжньою технологією».

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

Але саме тут і виникає ключове питання: чи можна сьогодні ігнорувати інновацію, яка відбувається не в цехах Rheinmetall, а в гаражах, майстернях і невеликих R&D?командах, які за рік змінюють тактику війни?

Українські FPV проти Shahed і китайських «аналогів»: дальність як нова валюта війни

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

Українські виробники FPV-перехоплювачів заявляють про дальність польоту 50–80 км. Це не лабораторні цифри, а практичні показники, які обговорюють із закордонними військовими. Для порівняння, типові китайські FPV-дрони, які іноземні армії купують «з полиці», часто мають реальну дальність близько 2 км. У кращому разі — трохи більше, але це все одно інший масштаб.

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

Паралельно Естонія та Польща готуються наступного року виробити близько 10 000 мікроракет для збиття Shahed і продавати їх, у тому числі Україні. На перший погляд, це логічний шлях: ракета проти дрона, класична схема ППО. Але українські розробники, які працюють з FPV-перехоплювачами, ставлять під сумнів економічну й технічну доцільність такого підходу.

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

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

Власна цифрова відеолінка замість «китайської магії»

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

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

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

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

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

Економіка війни: чому «дешевий» FPV може бути дорожчою інновацією, ніж 130мм гармата

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

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

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

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

Цей підхід уже виходить за межі України. Коли ізраїльські військові, які купили китайські FPV і отримали реальну дальність близько 2 км, приїжджають в Україну й питають, як досягти 40 км, це непряме визнання: «домогосподарки з 3D-принтерами» створили щось, чого не дає готовий китайський ринок. Відповідь українських розробників проста й водночас показова: потрібні інші наземні станції, інша архітектура зв’язку, інша підготовка екіпажів. Тобто потрібна не просто «залізяка», а ціла система.

І тут ми повертаємося до тези Паппергера. Так, це не технологія Lockheed Martin, General Dynamics чи Rheinmetall. Це інша технологічна парадигма — швидка, модульна, гнучка, побудована на масовості й постійному оновленні. Вона погано вписується в бізнес-моделі великих корпорацій, але чудово працює там, де війна триває щодня.

Чому конфлікт із Rheinmetall важливий не лише для України

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

З одного боку — Skynex, нові танки, 130мм гармати, мікроракети проти Shahed. З іншого — FPV-перехоплювачі з дальністю 50–80 км, власні цифрові відеолінки, наземні станції, які збирають невеликі команди інженерів і операторів. Перший шлях дає політичну вагу, великі контракти, стабільні бізнес-моделі. Другий — реальну гнучкість на полі бою й можливість швидко масштабувати рішення.

Ринок уже реагує на цю дилему. Заяви Паппергера підняли акції Rheinmetall, але водночас посилили увагу до того, що саме робить Україна в сфері FPV. Країни, які стикаються з загрозою Shahed, дивляться не лише на Skynex чи мікроракети, а й на українські перехоплювачі. І що більше буде практичних кейсів їхнього застосування — тим складніше буде відмахуватися від них як від «LEGO для домогосподарок».

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

Висновок

Скандал із заявами Арміна Паппергера став зручним приводом подивитися на українські FPV-дрони без комплексу меншовартості. Так, це не Skynex і не 130мм гармата. Але саме вони сьогодні задають темп інновацій на полі бою, змушують переглядати підходи до ППО, демонструють, що «LEGO-інженерія» може бути не менш революційною, ніж багатомільярдні програми великих корпорацій.

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

Джерело

Подкаст УТ?2: «Глава Rheinmetall був правий? Іран. Як покращити експорт зброї. Нарешті норм інвестиції. fpv #25»