Уявімо знайому для 2026-го сцену. Джун отримує задачу, відкриває Cursor, пише промпт і за кілька хвилин отримує готовий код. Локально все працює, тести зелені, зміни можна пушити в репозиторій. На перший погляд, усе добре. Проблема в тому, що він не завжди розуміє, чому саме це рішення працює і що з ним станеться, коли воно зламається о третій ночі в продакшні.
Читайте также: В Україні запустили платформу Lapathoniia для роботи з вітчизняними ШІ-моделями
Ще рік тому це звучало б як перебільшення для чергової дискусії про майбутнє професії. Сьогодні це звичайна реальність для багатьох команд. І питання вже не в тому, чи вміє ШІ писати код. Вміє — і часто швидше за людину. Питання в іншому: чи не відучує він поступово думати як інженер.
Найгірше в деградації — що її майже не видно
Парадокс у тому, що деградація навичок майже ніколи не відчувається зсередини. Суб’єктивно розробник стає швидшим, та об’єктивно — не факт.
У SPD Technology кажуть, що зміни видно вже зараз. Senior Software Development Engineer Антон Небилиця пояснює: раніше розробник, перш ніж писати код, тримав у голові модель системи й намагався розібратися в логіці рішення. Тепер дедалі частіше він одразу звертається до асистента і бере перший варіант, який виглядає правдоподібним.
Найболючіше це б’є по навичці дебагу. За словами Небилиці, звичка перечитувати stack trace, перевіряти власні припущення й самостійно докопуватися до причини помилки поступово атрофується, якщо простіше просто вставити лог у чат і попросити пояснення.
Особливо це небезпечно для джунів. Інженерне чуття роками формувалося через простий цикл: написав, зламав, зрозумів, переписав. Якщо цей процес підміняється prompt engineering, фундамент просто не встигає сформуватися. Для сеньйорів ризик інший: не брак бази, а поступова втрата критичності. Відповідь моделі починають сприймати не як припущення, яке треба перевірити, а як готову істину.
Водночас Data & ML Engineer у Levi9 Ігор Козлов звертає увагу на неочевидний плюс: багато досвідчених розробників досі ставляться до ШІ з обережним скепсисом. І саме це часто працює їм на користь. За його словами, контрольоване використання асистента не послаблює навички, а навпаки — підсилює їх.
Перестаємо писати код — і починаємо його перевіряти
Усі співрозмовники dev.ua погоджуються: сама природа професії вже змінюється. Хороший інженер майбутнього — це не той, хто найшвидше набирає код руками, а той, хто найкраще розуміє, що саме згенерувала модель, де слабкі місця цього рішення і які ризики воно створює для продукту.
Козлов описує це як перехід від «писати код» до «розуміти код». За його словами, сьогодні критично важливо не просто прийняти результат від ШІ, а усвідомлювати, які частини системи він зачіпає, що покрито тестами, а де потенційно закладені проблеми. Саме тому code review стає не менш важливим, а навпаки — критично важливішим.
AI-директор EPAM Україна Вадим Власенко говорить про це без романтизації.
За словами Власенка, водночас завдяки своєму досвіду він робить дуже якісне code review. «Тож чи вбачаю я тут проблему? Скоріше ні, бо питання не в тому, хто технічно набирає код. А от перевіряти ці результати обов’язково має саме людина», — зазначає айтівець.
І тут виникає незручне питання для бізнесу. Якщо ШІ справді прискорює delivery, чи готові компанії оплачувати додатковий час на перевірку, рев’ю, тестування і переписування, без якого це прискорення дуже швидко перетвориться на технічний борг? Бо AI-generated code без інженерної дисципліни — це не оптимізація. Це просто швидше накопичення проблем.
Насправді проблема стара. Просто тепер масштаби інші
CTO Master of Code Богдан Сергієнко пропонує не драматизувати, адже, за його словами, сама проблема не нова. «Жарти про 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, не зробить слабкого розробника сильним. Але дуже швидко покаже, де закінчується реальне розуміння і починається його імітація.
Читайте также: Джейсон Момоа Новая Девушка: подробности личной жизни и карьеры