ШІ вже пише код швидше за багатьох джунів. Але тімліди дедалі частіше говорять про іншу проблему: розробники починають менше думати. dev.ua поговорив з інженерами Levi9, SPD Technology, Master of Code Global та EPAM про те, чи справді AI-допомога деградує спеціалістів — і що з цим робити.
ШІ вже пише код швидше за багатьох джунів. Але тімліди дедалі частіше говорять про іншу проблему: розробники починають менше думати. dev.ua поговорив з інженерами Levi9, SPD Technology, Master of Code Global та EPAM про те, чи справді AI-допомога деградує спеціалістів — і що з цим робити.
Уявімо знайому для 2026-го сцену. Джун отримує задачу, відкриває Cursor, пише промпт і за кілька хвилин отримує готовий код. Локально все працює, тести зелені, зміни можна пушити в репозиторій. На перший погляд, усе добре. Проблема в тому, що він не завжди розуміє, чому саме це рішення працює і що з ним станеться, коли воно зламається о третій ночі в продакшні.
Ще рік тому це звучало б як перебільшення для чергової дискусії про майбутнє професії. Сьогодні це звичайна реальність для багатьох команд. І питання вже не в тому, чи вміє ШІ писати код. Вміє — і часто швидше за людину. Питання в іншому: чи не відучує він поступово думати як інженер.
Парадокс у тому, що деградація навичок майже ніколи не відчувається зсередини. Суб’єктивно розробник стає швидшим, та об’єктивно — не факт.
У SPD Technology кажуть, що зміни видно вже зараз. Senior Software Development Engineer Антон Небилиця пояснює: раніше розробник, перш ніж писати код, тримав у голові модель системи й намагався розібратися в логіці рішення. Тепер дедалі частіше він одразу звертається до асистента і бере перший варіант, який виглядає правдоподібним.
Найболючіше це б’є по навичці дебагу. За словами Небилиці, звичка перечитувати stack trace, перевіряти власні припущення й самостійно докопуватися до причини помилки поступово атрофується, якщо простіше просто вставити лог у чат і попросити пояснення.
Сам розробник цього часто навіть не помічає: суб’єктивно він рухається швидше, хоча час, який нібито зекономив на написанні, потім витрачається на рев’ю й перевірку того, що згенерувала модель.
Особливо це небезпечно для джунів. Інженерне чуття роками формувалося через простий цикл: написав, зламав, зрозумів, переписав. Якщо цей процес підміняється prompt engineering, фундамент просто не встигає сформуватися. Для сеньйорів ризик інший: не брак бази, а поступова втрата критичності. Відповідь моделі починають сприймати не як припущення, яке треба перевірити, а як готову істину.
Водночас Data & ML Engineer у Levi9 Ігор Козлов звертає увагу на неочевидний плюс: багато досвідчених розробників досі ставляться до ШІ з обережним скепсисом. І саме це часто працює їм на користь. За його словами, контрольоване використання асистента не послаблює навички, а навпаки — підсилює їх.
Усі співрозмовники dev.ua погоджуються: сама природа професії вже змінюється. Хороший інженер майбутнього — це не той, хто найшвидше набирає код руками, а той, хто найкраще розуміє, що саме згенерувала модель, де слабкі місця цього рішення і які ризики воно створює для продукту.
Козлов описує це як перехід від «писати код» до «розуміти код». За його словами, сьогодні критично важливо не просто прийняти результат від ШІ, а усвідомлювати, які частини системи він зачіпає, що покрито тестами, а де потенційно закладені проблеми. Саме тому code review стає не менш важливим, а навпаки — критично важливішим.
AI-директор EPAM Україна Вадим Власенко говорить про це без романтизації.
«Я писав багатьма мовами програмування — Java, Python, JavaScript, TypeScript, C#. Але зараз зробити щось руками не так просто. Навіть банально не зроблю це так швидко фізично», — каже він.
За словами Власенка, водночас завдяки своєму досвіду він робить дуже якісне code review. «Тож чи вбачаю я тут проблему? Скоріше ні, бо питання не в тому, хто технічно набирає код. А от перевіряти ці результати обов’язково має саме людина», — зазначає айтівець.
І тут виникає незручне питання для бізнесу. Якщо ШІ справді прискорює delivery, чи готові компанії оплачувати додатковий час на перевірку, рев’ю, тестування і переписування, без якого це прискорення дуже швидко перетвориться на технічний борг? Бо AI-generated code без інженерної дисципліни — це не оптимізація. Це просто швидше накопичення проблем.
CTO Master of Code Global Богдан Сергієнко пропонує не драматизувати, адже, за його словами, сама проблема не нова. «Жарти про Stack Overflow-програмістів існували задовго до появи Cursor чи Claude Code. Просто сучасні агенти генерують набагато складніший і переконливіший код, ніж звичайний copy-paste з форуму», — каже він.
Принципова річ не змінилася: відповідальність за кінцевий результат завжди залишається за людиною, а не за моделлю. Ризики виникають не тому, що ШІ написав код, а тоді, коли цей код не проходить достатню перевірку. Саме тому code review, тестування й архітектурне мислення сьогодні важать навіть більше, ніж кілька років тому.
Усі співрозмовники сходяться в одному: заборонами нічого не вирішити. Потрібні процеси.
У SPD діє правило AI after attempt. Перші 30–40 хвилин розробник працює самостійно. Лише після цього може звертатися до асистента. Це дозволяє спочатку побачити межу власного нерозуміння, а вже потім закривати її через ШІ.
Ще один принцип там формулюють так: AI — це pair programmer, де ти navigator, а не пасажир. Усе, що потрапляє в коміт, розробник має бути здатен пояснити на рев’ю без відкритого чату поруч.
Практикують і AI-free дні або pet-проєкти без асистентів — як тренування пам’яті після калькулятора.
У SPD працюють з Claude Code, Codex, Cursor і Copilot. Але культу конкретного інструмента немає. Важливо не чим користується розробник, а наскільки він розуміє, що саме приймає від моделі.
В EPAM застосовують інший підхід — ліміти на токени. Власенко жартує: якщо вони закінчились у середу, до п’ятниці все одно доведеться думати самостійно. За цим жартом стоїть серйозна логіка: штучний дефіцит не дає мозку повністю делегувати мислення машині.
У Levi9 нагадують ще про одну стару добру практику — сертифікації. Їх не можна «навайбкодити». Знання все одно доведеться здобувати самому.
Власенко каже прямо: термін «вайбкодинг» його дратує, бо знецінює професію. Розробка — це не про «вайби», а про серйозну інженерну роботу. Замість цього він говорить про AI-native delivery — перебудову процесів так, щоб ШІ пришвидшував delivery, але не заміняв відповідальність людини.
На думку Власенка, не може бути T-shape інженера без фундаментальної профільної навички. У будь-якому AI-assisted процесі має залишатися людина, яка здатна гарантувати якість рішення.
Усі співрозмовники формулюють результат застосування ШІ по-різному, але сенс один: кваліфікація падає не від самого факту використання ШІ, а від режиму «згенерував і запушив, не читаючи». Ризики виникають не через інструмент, а через відсутність перевірки. Робота з асистентами може бути способом навчатися — якщо підходити до цього вдумливо.
ШІ, переконані співрозмовники dev.ua, не зробить слабкого розробника сильним. Але дуже швидко покаже, де закінчується реальне розуміння і починається його імітація.
