Як зберегти якість коду, коли джуніори користуються ШІ

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

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

Як виглядає проблема

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

Важливо не поспішати з висновком про причину. Ті самі симптоми можуть мати різне походження:

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

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

Що відомо про навчання з ШІ

Одне з найближчих до цієї ситуації контрольованих досліджень опубліковане в січні 2026 року. У ньому взяли участь 52 переважно молодші розробники, які принаймні рік щотижня писали на Python, мали досвід з ШІ-асистентами, але раніше не працювали з бібліотекою Trio для асинхронного програмування. Кожен мав реалізувати дві функції з Trio, а одразу після цього пройти тест на розуміння: читання коду, налагодження, написання коду і концептуальні питання. Одна група мала доступ до ШІ-асистента в бічній панелі чату, який на запит міг видати правильний код, інша писала вручну.

Результати такі. У групі з ШІ середній бал тесту становив 50%, у групі без ШІ — 67%. Різниця між середніми — 17 процентних пунктів; відносно результату групи без ШІ це приблизно на чверть нижче. Найбільший розрив був у питаннях на налагодження. Група з ШІ в середньому впоралася приблизно на дві хвилини швидше, але ця різниця не була статистично значущою — тобто прискорення як ефект дослідження не довело.

Цікаво, що всередині групи з ШІ результати сильно відрізнялися. Ті, хто ставив асистенту концептуальні питання, просив код разом із поясненням або після генерації уточнював, як працює отримане рішення, в середньому мали 65% і вище. Ті, хто повністю делегував задачу чи налагодження, мали в середньому менше 40%. Але ці підгрупи дуже малі — від двох до семи людей, і аналіз не встановлює причинного зв’язку між стилем роботи й результатом.

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

Два більш ранні контрольовані дослідження дають додатковий контекст. В одному дослідженні 2022 року учасники з доступом до тодішнього ШІ-помічника писали менш безпечний код і водночас частіше вважали його безпечним; ті, хто менше довіряв асистенту і активніше переформульовував запити, допускали менше вразливостей. Це аргумент на користь обов’язкової перевірки, але не вимірювання сучасних моделей. В окремому експерименті 2023 року учасники, які користувалися ШІ-помічником, реалізували HTTP-сервер на JavaScript на 55,8% швидше, ніж контрольна група. Це одна обмежена задача, і швидкість її виконання нічого не говорить про засвоєння навичок чи якість подальшого супроводу.

Правила роботи з помічником

Правила мають бути короткими, щоб їх справді виконували. Ось набір, який можна взяти за основу і адаптувати.

1. Спочатку задача своїми словами. До звернення до ШІ розробник записує, що потрібно зробити, які обмеження є і який підхід він бачить. Навіть два-три речення.
2. Підказка, а не готове рішення — у режимі навчання. Запит формулюється як «який підхід тут доречний і чому», «що я пропускаю», «поясни цю помилку», а не «напиши функцію».
3. Перевірка реалізації. Кожна згенерована частина запускається, покривається тестом і перечитується. Невідомі функції бібліотек перевіряються в документації.
4. Список невідомого. Перед відправкою на рев’ю автор чесно перелічує, що в рішенні він не до кінця розуміє. Це не привід для покарання, а матеріал для наставника.

Різницю між режимами найкраще видно на самих запитах. Ось як може виглядати одна й та сама потреба:

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

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

Зміни в рев’ю

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

Автор у описі pull request або на коротку усну зустріч пояснює:

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

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

Практика самостійності

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

Короткі задачі без підказок. Раз на тиждень — невелике завдання на 30–60 хвилин без ШІ: виправити дефект, дописати тест, реалізувати маленьку функцію. Мета — не перевірка, а тренування самостійного мислення.

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

Повторна реалізація. Після того як ШІ або наставник пояснили рішення, розробник закриває пояснення і реалізує його ще раз самостійно.

Навчальна вправа: обробник платежу

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

1. Пояснити повторну доставку. Платіжні сервіси можуть надіслати одну подію двічі. Що станеться з цим кодом? Чи спишеться товар двічі?
2. Пояснити перевірку суми. Де в коді порівнюється сума платежу із сумою замовлення? Що буде, якщо прийде часткова оплата?
3. Пояснити межу транзакції. Якщо статус замовлення змінився, а списання зі складу впало з помилкою, у якому стані опиниться система?
4. Написати тест на повторну подію — та сама подія надходить двічі, товар списується один раз.
5. Показати поведінку при таймауті — база не відповіла вчасно; що побачить платіжний сервіс і чи надішле подію знову.

Наставник веде просту таблицю прогресу:

Як оцінити результат

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

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

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

Підсумок і перші кроки

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

Що можна зробити вже на наступному спринті:

1. Ввести два режими роботи — навчання і доставку — і для кожної задачі джуніора явно вказувати режим.
2. Додати в шаблон pull request три поля: інваріанти, граничні випадки, причина вибору рішення.
3. Раз на тиждень давати коротку задачу без ШІ і розбирати її разом.
4. Після кожного знайденого дефекту просити автора самостійно відтворити його тестом і пояснити причину.
5. Вести таблицю наставника «зрозумів — відтворив — виправив — пояснив компроміс».
6. Через кілька тижнів порівняти дефекти після рев’ю, повторення помилок і здатність пояснити з початковою точкою — і вирішити, що змінити в правилах.

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

Часті запитання