Чому AI-курси для інженерів не працюють і що працює натомість
Більшість навчання з AI вчить промптів та інструментів. Але вузьке місце в іншому: коли генерація майже безкоштовна, головною навичкою стає перевірка.
Типовий сценарій виглядає так. Компанія купує ліцензії на AI-асистента, проводить дводенний курс, учасники ставлять 4,7 з 5 у формі зворотного зв’язку. Через місяць хтось користується інструментом щодня, хтось — як розумним автодоповненням, а більшість повернулась до того, як працювала раніше. Звіт про навчання при цьому виглядає успішним: усі пройшли, усім сподобалось.
Я проєктую навчальні програми для інженерних команд, і останнім часом — переважно про AI. Мій висновок простий: курс про інструмент не змінює те, як люди працюють. Нижче — чому, і що я роблю натомість.
Чому класичний курс не спрацьовує
Він вчить інструмента, а не роботи
Більшість програм побудовані навколо продукту: ось чат, ось автодоповнення, ось агентний режим, ось десять корисних промптів. Але інструменти змінюються щокварталу. Те, що на курсі показали як «правильний спосіб», за пів року застаріває, а курс — ні.
Навичка, яка лишається, — не «як користуватись конкретним асистентом», а «як розбити задачу так, щоб частину можна було делегувати, і як переконатись, що делеговане зроблено правильно». Цього на курсах про інструмент майже не вчать.
Промпти — не вузьке місце. Перевірка — так
Генерація коду, конфігурацій, тестів і документації стала майже безкоштовною. Перевірка не подешевшала. Хтось усе одно має прочитати diff, зрозуміти, чи він робить те, що треба, і чи не ламає щось поруч.
Тут є неприємна деталь: люди погано оцінюють, наскільки AI їм насправді допомагає. У дослідженні METR 2025 року досвідчені open-source розробники з AI виконували задачі на 19% довше. До експерименту вони очікували прискорення на 24%, а після нього були впевнені, що прискорились на 20%. Пізніші дані METR на нових інструментах уже показують невелике прискорення, але самі автори визнають: чесно виміряти ефект стає дедалі складніше, а самооцінка розробників ненадійна.
Висновок для навчання: якщо інженер не вміє швидко і критично перевіряти результат, швидша генерація просто переносить роботу з написання на рев’ю, а іноді — на інциденти в продакшні.
Навчання відірване від реальних задач
Курс проходить на демо-проєкті: todo-застосунок, вигаданий мікросервіс, чистий репозиторій. Потім інженер повертається до свого моноліту, внутрішніх бібліотек, legacy-пайплайнів і обмежень безпеки. Перенести навичку з чистого прикладу в такий контекст — окрема робота, і зазвичай її ніхто не робить.
У навчальному дизайні це давно відома проблема: знання погано переносяться між різними контекстами, якщо перенесення спеціально не тренувати. AI-навчання тут не виняток.
Вимірюється задоволення, а не поведінка
Майже всі AI-програми звітують першим рівнем моделі Кіркпатріка: «чи сподобалось». Іноді другим: «чи склали тест». Майже ніхто не дивиться на третій — чи змінилась поведінка на робочому місці. А саме він і цікавить бізнес.
Без замірів до і після неможливо відрізнити реальний ефект від ентузіазму перших тижнів.
Навчають людину, а змінюватись має команда
Навіть якщо окремий інженер навчився добре працювати з AI, він повертається в команду, де правила не змінились. Як рев’юїти код, який згенерував агент? Чи позначати такі зміни? Хто відповідає, якщо згенерований тест насправді нічого не перевіряє? Поки команда про це не домовилась, індивідуальна навичка впирається в стелю.
Що працює натомість
Я перестав будувати програми навколо питання «як користуватись інструментом» і будую їх навколо іншого: як працювати, коли генерація дешева, а перевірка — ні.
Навчання на власному беклозі. Кожна сесія — на реальній задачі з поточного спринту учасника. Не демо-проєкт, а справжній тікет у справжньому репозиторії, з усіма його обмеженнями. Так перенесення знань відбувається одразу, а не «колись потім».
Тренування перевірки, а не генерації. Найкорисніша вправа, яку я знаю: інженер отримує AI-згенерований результат з помилками — від очевидних до тонких — і має їх знайти. Це калібрує довіру: люди швидко бачать, де модель стабільно помиляється в їхньому стеку, а де їй можна довіряти більше.
Декомпозиція і контекст як інженерна навичка. Добре сформульована задача для агента — це по суті маленька специфікація: мета, обмеження, критерії готовності, що не чіпати. Інженери, які вміють так писати, отримують кращі результати незалежно від інструмента. І ця навичка не застаріває разом з версією продукту.
Розуміння, коли AI не використовувати. Окремий блок про задачі, де AI сповільнює: незнайомий код, де інженер не зможе перевірити результат; критичні зміни безпеки; ситуації, коли пояснити контекст довше, ніж зробити самому.
Командні домовленості. Наприкінці програми команда фіксує свої правила: як рев’юїти AI-згенерований код, що можна делегувати агентам, а що ні, як позначати такі зміни. Це документ на сторінку, але саме він переводить навичку з індивідуальної в командну.
Заміри до і після. Не опитування задоволення, а поведінкові метрики, які команда й так збирає: час від початку роботи над задачею до merge, кількість повернень з рев’ю, частка змін, які довелось виправляти після релізу. Самооцінку теж варто збирати, але як окремий сигнал, пам’ятаючи, що вона систематично оптимістична.
Мінімальний дизайн програми
Ось форма, з якої я зазвичай починаю. Вона розрахована на одну команду і шість тижнів без відриву від роботи.
| Тиждень | Фокус | Результат |
|---|---|---|
| 0 | Базовий рівень: метрики команди, короткий опитувальник, вибір реальних задач | Точка відліку |
| 1 | Декомпозиція і контекст: як ставити задачу AI | Шаблон постановки задачі для свого стеку |
| 2 | Перевірка: вправи з пошуку помилок в AI-результатах | Список типових помилок моделі у своєму коді |
| 3–4 | Робота на реальних тікетах, щотижнева клініка 90 хв | Закриті задачі з беклогу, розібрані випадки |
| 5 | Коли AI не використовувати; ризики і безпека | Межі делегування для команди |
| 6 | Командні домовленості, повторні заміри, ретро | Правила команди і порівняння до/після |
Головне тут не розклад, а принципи: реальні задачі замість демо, перевірка замість генерації, команда замість окремої людини, заміри замість анкет.
У чому я досі не впевнений
Кілька питань, на які в мене поки немає хорошої відповіді:
- Як чесно вимірювати продуктивність. Метрики потоку задач показують зміни, але на них впливає забагато іншого. Навіть METR переробляє свою методологію.
- Чи мають джуніори спочатку вчитись без AI. Перевіряти можна лише те, що розумієш. Але вчитись в ізоляції від інструментів, з якими потім працюватимеш, теж дивно.
- Як швидко знецінюється навчання. Якщо принципи стабільні, а інструменти змінюються щокварталу, скільки часу має йти на одне й на друге?
Якщо ви проводили або проходили AI-навчання в інженерній команді, мені цікаво, що спрацювало у вас, а що ні.
Це перший випуск серії «AI після демо» — нотаток про те, як AI приходить у реальну інженерну роботу. Наступний випуск — лабораторна: одне DevOps-завдання, кілька AI-інструментів і реальні заміри.
Джерела: METR: дослідження продуктивності розробників з AI, 2025 · METR: оновлення даних, лютий 2026