Онлайн-курси з машинного навчання давно стали стандартним стартом для тих, хто хоче увійти в 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»

Український канал HackYourMom запросив до розмови Осіріса — очільника хакерського угруповання 4b1d (Forbid), яке відверто позиціонує себе як «заборонене» на території Росії й діє без масок та спроб анонімізації. Угруповання спеціалізується на атаках проти російських компаній, використовуючи переважно ransomware, і фінансує свою діяльність за рахунок цих операцій, не отримуючи підтримки від держави.

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

«Заборонені» на території Росії: хто такі 4b1d

Угруповання 4b1d, яке Осіріс вимовляє як Forbid, позиціонує себе максимально прямо: назва означає «заборонений». У розмові він підкреслює, що «заборонений» насамперед «на території Аркастану» — так він іронічно називає Росію.

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

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

Джерело фінансування 4b1d Осіріс формулює без евфемізмів: це ransomware-операції проти російських цілей. Злам, шифрування, вимагання викупу — і саме з цих грошей, за його словами, живе команда. Він згадує, що навіть публікував фрагменти переписки з директором одного з заводів, який заплатив за розшифрування.

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

Від шкільного Wi?Fi до власного угруповання: шлях Осіріса

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

Перші кроки в хакінгу він робив ще у школі — між п’ятим і восьмим класами. У школі був лаборант, який постійно змінював пароль від Wi?Fi, а учні хотіли після уроків грати в World of Tanks Blitz. Осіріс навчився ламати шкільну мережу, діставав пароль і продавав його однокласникам по 5 гривень.

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

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

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

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

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

Від готельних CRM до SCADA: як мислить хакер, який «сидить глибоко»

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

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

Схема виглядала так. Поруч із готелем, у якому він жив, був інший готель. Осіріс виявив приховану Wi?Fi-мережу, яка використовувалася для внутрішніх потреб. За допомогою невеликого пристрою — по суті, деавтентифікатора й «evil twin» точки доступу — він глушив справжню мережу й піднімав власну з тим самим SSID.

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

Далі він підключався до внутрішньої мережі готелю. Через сканування (наприклад, nmap) бачив усі пристрої в мережі, оскільки вона не була сегментована на підмережі. За відкритими портами 80 або 443 він ідентифікував веб-застосунки, заходив у веб-інтерфейси й знаходив CRM-систему готелю — ту саму, де зберігалися бронювання, дані клієнтів і співробітників.

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

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

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

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

Найгучніші атаки 4b1d: від автосалонів Lada до лабораторії «Газпрому»

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

Одним із помітних епізодів став злам мережі автосалонів Lada Bright Park. За словами Осіріса, 4b1d зламало й зашифрувало 10 автосалонів цієї мережі в Росії. Деталі технічної реалізації в цьому фрагменті розмови не розкриваються, але формат атаки типовий для ransomware: шифрування інфраструктури, блокування бізнес-процесів, подальші переговори про викуп.

Ще масштабнішою за наслідками була атака на мережу магазинів будівельних матеріалів «МиниМакс» — російський аналог українського «Епіцентру». Осіріс підтверджує, що 4b1d зашифрувало близько 4 тисяч комп’ютерів і знищило близько 200 серверів компанії. Важливий нюанс: під удар потрапили й SCADA-системи — тобто системи диспетчерського керування й збору даних, які часто відповідають за виробничі процеси, логістику, складські операції.

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

Окремий блок — атаки на структури, пов’язані з «Газпромом». Осіріс розповідає про злам компанії «Газтех» (ПАО «Газтех»), яку він описує як наукову лабораторію для «Газпрому». За його словами, у результаті атаки компанія втратила всі локальні дані.

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

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

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

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

Ransomware як економіка війни: чому 4b1d не потребує «спонсора»

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

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

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

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

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

Висновок: нова реальність кіберфронту

Історія Осіріса та угруповання 4b1d — це концентрований зріз нової реальності кіберфронту у війні між Україною та Росією.

З одного боку, це класична історія хакера-самоучки: важке дитинство, низькі оцінки в школі, технічний коледж, ранні експерименти зі шкільним Wi?Fi, подальші зломи готельних CRM у Єгипті й конфлікт із законом. З іншого — це історія людини, яка перетворила свої навички на інструмент війни, очолила власне угруповання й почала системно бити по російських компаніях і структурах, пов’язаних із критичною інфраструктурою та військовим управлінням.

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

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

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

Джерело

Хакер Osiris з 4b1d про взлом ГазПром, та заробіток на RansomWare

Штучний інтелект стрімко змінює те, як створюється програмне забезпечення, і один із найрадикальніших голосів у цій трансформації — Борис Черні, творець і керівник продукту Claude Code в Anthropic. Менш ніж за рік його команда побудувала інструмент, який, за оцінкою Semianalysis, уже генерує близько 4% усіх публічних комітів на GitHub, а до кінця року може сягнути 20%. На цьому тлі Черні формулює тезу, яка ще кілька років тому звучала б фантастично: «кодування в основному вирішене», а світ рухається до реальності, де програмувати зможе кожен, а звична роль «software engineer» поступиться місцем ширшій ролі «builder».

Коли 100% коду пише ШІ: як виглядає «вирішене» програмування

Особистий робочий процес Бориса Черні — показовий маркер того, наскільки далеко зайшли інструменти на кшталт Claude Code. Він стверджує, що з листопада 100% його коду написано Claude Code. Щодня він «відправляє» 10–20, інколи 30 pull request’ів, і при цьому не редагує жодного рядка вручну.

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

У масштабі компанії це перетворюється на відчутний зсув продуктивності. За словами Черні, продуктивність одного інженера в Anthropic, якщо міряти кількістю pull request’ів, зросла приблизно на 200% після впровадження Claude Code. Паралельно компанія за рік приблизно вчетверо збільшила розмір інженерної команди, а всі pull request’и автоматично проходять первинний рев’ю від Claude, після чого їх переглядає людина.

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

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

Від «чи варто вчитися кодувати?» до «кожен уже програмує»

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

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

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

Черні згадує, як на внутрішньому заході Anthropic у травні 2025 року він припустив, що до кінця року інженерам може вже не знадобитися IDE для написання коду. Ця фраза викликала відчутний подих здивування в залі. Проте якщо екстраполювати частку коду, яку вже тоді писав Claude, крива перетинала позначку 100% до кінця року. Сьогодні його власний робочий процес — фактичне підтвердження цієї траєкторії.

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

Коли кожен — product manager, а «software engineer» стає «builder»

Одна з найрадикальніших тез Черні стосується трансформації ролей у технологічних командах. Він прогнозує, що до кінця року «кожен буде product manager’ом і кожен кодуватиме». Традиційний титул «software engineer», на його думку, почне зникати, поступаючись місцем ролі «builder».

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

У такій моделі:

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

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

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

Від автодоповнення до співробітника: як ШІ сам шукає ідеї та баги

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

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

Це має кілька наслідків.

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

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

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

Anthropic, за словами Черні, будує свої моделі й продукти в логіці «код ? інструменти ? комп’ютер», де кожен наступний рівень означає більшу автономність і вплив на зовнішній світ. Саме тому компанія так наполягає на безпеці: коли ШІ не просто генерує текст, а діє в реальних системах — від GitHub до Gmail і Slack, — будь-яка помилка чи зловживання може мати значно серйозніші наслідки.

Коли ШІ виходить за межі інженерії: наступні професії в черзі

Claude Code починався як інструмент для розробників, але сьогодні Anthropic уже виводить подібну логіку в інші професійні сфери. Продукт Cowork, про який згадує Черні, демонструє, як «агент, що діє», приходить до нетехнічних ролей.

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

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

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

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

Болісний, але неминучий перехід

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

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

Сьогодні роль змінюється знову, але цього разу швидкість і масштаб зсуву значно вищі. Semianalysis фіксує, що вже зараз близько 4% усіх публічних комітів на GitHub створює Claude Code, і прогнозує зростання до 20% до кінця року. Spotify публічно говорить про те, що їхні найкращі розробники не пишуть код вручну. Сам Черні не редагує жодного рядка власного коду з листопада.

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

Висновок: програмування як нова грамотність

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

ШІ-агенти на кшталт Claude Code і Cowork роблять цей перехід практичним: вони знімають бар’єр у вигляді необхідності роками вивчати мови програмування й інструменти, дозволяючи людям одразу працювати на рівні намірів і результатів. Водночас вони підвищують ставки для тих, хто будує кар’єру в технологіях: відтепер недостатньо просто вміти писати код — потрібно вміти будувати системи, продукти й процеси разом із ШІ.

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

Джерело

Head of Claude Code: What happens after coding is solved | Boris Cherny — Lenny’s Podcast

За останні пів року один із найвідоміших інженерів сучасного вебу радикально змінив спосіб, у який пише код. Девід Хайнемайєр Ханссон (David Heinemeier Hansson, або DHH) — творець Ruby on Rails, автор Linux?дистрибутива Omachi та співзасновник 37signals (Basecamp, HEY) — ще зовсім недавно публічно скептично ставився до AI?інструментів програмування. Сьогодні він говорить про «agent?first» підхід, майже не набирає код руками і використовує агентів як основний інструмент побудови софту.

Ця трансформація не зруйнувала його ставлення до ремесла, естетики й якості — радше змінила саму «механіку» роботи: від ручного кодування до керування потужними інструментами, які виконують левову частку рутинної роботи. На тлі цього зсуву по?новому виглядають і Ruby on Rails, і Linux?дистрибутив Omachi, і сама культура розробки в 37signals.

Від скепсису до «agent?first»: що насправді змінилося

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

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

У 37signals це вже не теоретичний експеримент, а повсякденна практика. Один із найактивніших користувачів агентів у компанії, Джеремі, взявся за завдання, яке в «допоінтелектуальну» епоху навряд чи взагалі з’явилося б у беклозі: оптимізувати P1 — буквально найшвидші 1% запитів — зробити ще швидшими. Це не «пожежа» й не бізнес?критичний борг, а майже естетичне прагнення до досконалості продуктивності. Сам факт, що команда може дозволити собі такі проєкти, — прямий наслідок того, наскільки багато роботи тепер перекладається на агентів.

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

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

Ruby on Rails у новій реальності: токени, агенти й читабельність

Ruby on Rails народився як набір інструментів, які DHH створив для себе, коли в 2003 році будував Basecamp на Ruby, що тоді майже не мав веб?екосистеми. Він «подряпав власний свербіж», відкрив код — і фреймворк став одним із найвпливовіших у веб?розробці. Двадцять років потому Rails не просто живий: DHH досі «дуже сильно залучений» у його розвиток і бачить для нього нову хвилю популярності в епоху AI?агентів.

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

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

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

Omachi, Linux і агентний підхід до інфраструктури

Перехід DHH до «agent?first» мислення не обмежується кодом додатків. Він тісно пов’язаний із тим, як він працює з інфраструктурою — і тут у гру входить Omachi, його власний Linux?дистрибутив.

Близько двох років тому він повністю перейшов на Linux: спочатку Ubuntu, а потім вирішив «зробити власну систему з нуля», побудувавши її на базі Arch і Hyprland. Omachi почався як літній проєкт під час 24 Hours of Le Mans, де між заїздами багато «мертвого часу». Те, що стартувало як особистий експеримент, дуже швидко «злетіло»: за трохи більше ніж пів року дистрибутив зібрав близько 400 контриб’юторів, а десятки тисяч людей встановили його як щоденну систему.

Це класична для DHH історія: він створює «ідеальну систему для себе» — і виявляється, що існують тисячі людей із дуже схожими вподобаннями. Так було з Ruby on Rails, так із Omachi, так із іншими його проєктами на кшталт Kamal чи ініціативи «getting out of the cloud». Важливий момент: це не просто хобі. 37signals уже перевела більшість девелоперських машин на Linux, причому саме на власний дистрибутив. Компанія з першого дня деплоїть на Linux?сервери й залишається «Linux?шопом» на бекенді, тож зближення дев?середовища з продакшеном дає відчутну перевагу.

У цьому рішенні проглядається той самий агентний спосіб мислення, тільки на рівні організації: якщо ти створюєш інструмент, який реально працює, логічно максимально його використовувати. DHH як CTO прямо задає технічний курс: розробники вебу, Ruby й DevOps мають працювати на Linux, щоб бути ближче до продакшену й одночасно допомагати розвивати Omachi. «Відкритий вибір» ОС, який був на старті експерименту, поступився місцем стандартизації — так само, як нікому не дозволять у 37signals будувати новий сервіс на Django, коли вся компанія живе на Ruby on Rails.

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

Більше амбіцій, менше бар’єрів: як агенти змінюють масштаб ідей

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

Це стосується не лише мікрооптимізацій на кшталт P1. Вся історія 37signals — це послідовність проєктів, які на старті виглядали або нішевими, або відверто божевільними. У 2003 році Basecamp був побічним продуктом веб?консалтингу, який раптом «вистрілив» настільки, що компанія за рік повністю відмовилася від послуг і стала продуктовою. Через 20 років Basecamp залишається найбільшим і найважливішим продуктом 37signals — приклад того, як «перша ідея» може виявитися найкращою в кар’єрі.

У 2020 році компанія запустила HEY — платний email?сервіс, який напряму конкурує з Gmail. Це ринок, де один гравець, за оцінкою DHH, обробляє 80–85% всього email?трафіку в США. Він сам користувався Gmail близько 17 років, із перших інвайтів, і за цей час накопичив довгий список речей, які його не влаштовували. HEY став спробою втілити ці думки в альтернативний продукт — із багатомільйонними інвестиціями в R&D і майже дворічною розробкою до запуску.

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

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

Краса, смак і ремесло в епоху AI: чому роль людей не зникає

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

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

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

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

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

Висновок: нова роль інженера — диригент агентів і хранитель смаку

Історія Девіда Хайнемайєра Ханссона — це не лише історія Ruby on Rails, Basecamp, HEY чи Omachi. Це історія людини, яка послідовно ставиться до програмування як до ремесла, де краса й правильність нерозривні, і водночас не боїться радикально змінювати інструменти, коли з’являється щось справді корисне.

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

У цьому світі фреймворки на кшталт Ruby on Rails отримують нове життя як токен?ефективні, читабельні й добре структуровані середовища для агентів. Власні інструменти, як Omachi, стають не просто особистими забавками, а стратегічною інфраструктурою, яка дозволяє будувати більш амбітні системи швидше й упевненіше. А компанії, що готові стандартизувати стек і мислити «agent?first», отримують змогу братися за проєкти, які ще вчора здавалися надто дорогими чи ризикованими.

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

Джерело

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