Вісім задач розробника: що віддати ШІ, а що залишити людям
Які задачі розробки пасують ШІ (шаблонний код, тести, документація, SQL, налагодження), а які потребують людей (архітектура, продуктові рішення, нестандартні задачі), і як змінюється код-рев'ю.
Довгий час рутина не змінювалася. Надходить вимога, відкривається редактор, шукається документація, копіюються приклади, пишеться код. З'являються помилки, знову пошук, потім тести, потім документація, і через багато годин фіча готова.
ШІ перекроїв цей цикл. Опишіть задачу звичайною мовою, і асистент за секунди видасть код, тести, документацію, SQL-запити, регулярні вирази, ідеї для рефакторингу й підказки для налагодження. Але в суперечках про те, що «ШІ замінить розробників», зазвичай губиться одна відмінність: генерація коду — це ще не інженерія.
З одними частинами роботи ШІ справляється чудово, з іншими ненадійно. Робоче правило просте: нехай ШІ бере на себе повторюване виконання, а за рішення відповідають люди. Виходить п'ять задач, які варто віддати ШІ, і три, де головною має лишатися людина.
1. Шаблонний код
Мабуть, це найпростіше делегувати. Звичайний список: CRUD-ендпоінти, моделі бази даних, UI-компоненти та форми, API-клієнти, правила валідації, конфіги, серіалізатори, DTO і базова обробка помилок. Нічого складного тут немає. Просто одноманітно.
Візьмімо API для керування користувачами. Якщо писати вручну, доведеться вибудовувати довгий ланцюжок шарів:
User Model
↓
Schema
↓
Repository
↓
Service
↓
Controller
↓
Validation
↓
Tests
Це багато набирання. ШІ-асистенту вистачить простого опису, наприклад: ендпоінт реєстрації на FastAPI з PostgreSQL, який перевіряє email, хешує пароль, не пропускає дублікати й повертає ID нового користувача. Робоча перша чернетка з'являється майже одразу.
Але є серйозне застереження: згенерований код ніколи не приймають наосліп. Автентифікацію, авторизацію, валідацію, SQL-запити, обробку помилок, версії залежностей, безпеку, продуктивність і граничні випадки має переглянути людина. ШІ дає першу реалізацію, а за фінальну відповідає розробник.
Арифметика часу виглядає привабливо. Задача, яка вручну забирає 45 хвилин, може дати першу версію за 2 хвилини, плюс приблизно 10 хвилин на рев'ю й тести. Прискорення приємне, але головний виграш у тому, що рідше доводиться перемикатися. Нікому не треба кидати справжню задачу, щоб набрати ще 30 рядків обв'язки.
2. Юніт-тести
Тести — ідеальний приклад допомоги, яка не знімає відповідальності. Ось невелика функція:
def calculate_price(price, discount):
return price - (price * discount / 100)
Розробникові довелося б продумати звичайні знижки, нуль, 100%, від'ємні значення, некоректне введення, поведінку чисел з рухомою комою та несподівані типи. Замість того щоб писати перший набір тестів руками, попросіть асистента зробити pytest-кейси для звичайних значень, меж, некоректного введення та граничних випадків. Він може повернути щось таке:
def test_no_discount():
assert calculate_price(100, 0) == 100
def test_full_discount():
assert calculate_price(100, 100) == 0
def test_half_discount():
assert calculate_price(200, 50) == 100
Далі рев'ю, і саме тут ховається небезпека. Тести, написані ШІ, можуть вводити в оману. Набір може давати 100% покриття й усе одно бути жахливим, бо покриття — не коректність. Асистент може просто переказати, що робить поточний код, і якщо код хибний, тести бадьоро підтвердять хибну поведінку.
Тому питати треба, яку поведінку насправді має бути гарантовано. Це частина людини. ШІ пише одноманітний тестовий код, а розробник вирішує, що варто тестувати.
3. Документація
Документація важлива, а починати її з чистого аркуша боляче. Команди відкладають її з обіцянкою написати згодом, і за пів року вже ніхто не може пояснити, як працює система.
З ШІ перша чернетка дається значно легше. Дайте йому вихідний код, описи API, конфігурацію, нотатки з архітектури, наявний README та інструкції з деплою, а потім попросіть README зі встановленням, змінними оточення, локальною розробкою, налаштуванням бази, ендпоінтами, тестами й деплоєм. Повернеться структурований документ, який перевіряє людина.
Особливо це зручно для:
- README, де пояснюється, як запустити проєкт
- документації API з ендпоінтами та форматами запитів і відповідей
- коментарів до заплутаних ділянок коду
- чейнджлогів із коротким описом відмінностей між релізами
- внутрішніх документів, зібраних із чорнових технічних нотаток
- матеріалів для онбордингу, які допомагають новачкам розібратися в проєкті
4. Regex, SQL та інші задачі з серії «знаю, але забув синтаксис»
Це дрібні відволікання, які ШІ прибирає. Мета зрозуміла, нечіткий лише синтаксис. Це може бути регулярка, складний SQL-запит, shell-команда, заклинання для Git чи метод JavaScript. Замість того щоб продиратися крізь десять сторінок документації, опишіть, що потрібно, наприклад: знайти користувачів, які мають щонайменше три покупки за останні 30 днів, і повернути суму їхніх витрат.
Асистент пише запит, людина його перевіряє. ШІ відповідає за синтаксис, людина — за логіку.
Припустімо, є схема з такими таблицями:
users
orders
payments
Нехай потрібен топ-10 клієнтів за сумою платежів за останні 30 днів. Перший варіант запиту приходить швидко, але людина однаково перевіряє джойни, дублі рядків, поведінку NULL, індекси, межі дат, часові пояси, агрегацію та продуктивність. Запит, правильний на 1 000 рядків, може ледь повзти на 100 мільйонах, а асистент не знає продакшен-середовища. Згенерований SQL — це чернетка, а не автоматично готовий до продакшену код.
5. Налагодження
У налагодженні ШІ, можливо, заощаджує найбільше часу. Дорого коштують рідко глибокі баги. Часто винуватець банально дурний: не задано змінну оточення, не збігається версія пакета, одруківка в імені, гонка в часі, розходяться налаштування середовищ, випадковий null або відповідь API несподіваної форми. Найболючіше — знайти причину, і в цих пошуках ШІ добре допомагає.
Якщо вставити саму лише голу помилку на кшталт цієї, користі буде мало:
TypeError: undefined is not a function
Контекст змінює все. Вкажіть фреймворк і версію, скажіть, який компонент кидає помилку і коли (наприклад, під час надсилання форми), додайте код компонента, стек викликів і очікувану поведінку та попросіть назвати найімовірніші причини плюс мінімальне безпечне виправлення.
Типовий процес виглядає так:
Error
↓
Collect Context
↓
Ask AI for Possible Causes
↓
Rank the Causes
↓
Test the Hypothesis
↓
Apply Fix
↓
Run Tests
↓
Verify
ШІ не замінює процес налагодження. Він пришвидшує розслідування, і це значно реалістичніша картина розробки з ШІ.
Три задачі, які варто залишити людям
Якщо ШІ вміє писати код, тести, SQL і документацію, чому б не віддати йому все? Бо інженерія — це більше, ніж генерація коду. Деякі рішення потребують контексту, судження, відповідальності, розуміння бізнесу, досвіду й спілкування, і в цих сферах люди мають лишатися глибоко залученими.
6. Архітектура системи
ШІ може запропонувати архітектуру, але останнє слово не має бути за ним. Попросіть масштабований дизайн для платформи електронної комерції, і відповідь, найімовірніше, буде такою:
Frontend
↓
API Gateway
↓
Microservices
↓
Message Queue
↓
Databases
↓
Cache
↓
Monitoring
Виглядає вражаюче. Але уявіть компанію з трьома розробниками, 10 000 користувачів, скромним бюджетом, одним продуктом і помірним трафіком. Чи потрібні їй 15 мікросервісів? Навряд. Модульний моноліт міг би виявитися в рази простішим.
Архітектура — це компроміси. Мікросервіси дають незалежний деплой, ізоляцію, автономію команд і незалежне масштабування, але натомість приносять операційну складність, мережеві клопоти, витрати на спостережуваність і розподілені збої. Моноліт простий, легко деплоїться, у ньому приємно працювати локально й простіше налагоджувати, але масштабувати окремі частини важче, кодова база росте, а за поганого проєктування підкрадається зв'язність.
ШІ може все це пояснити. Чого він сам собою не знає, то це який компроміс пасує саме цій компанії. Це й є інженерне судження.
7. Продуктові рішення
ШІ може аналізувати варіанти, але володіти роадмапом не повинен. Припустімо, стартап може зробити одну з двох фіч. Перша забере два місяці й, можливо, підніме виручку. Друга забере три дні й покращить утримання. Яка переможе?
Асистент допоможе зважити трудовитрати, можливий ефект, ринкові тренди та відгуки клієнтів. Але рішення залежить від бізнесу. Можливо, найближча мета — залучити інвестиції. Можливо, головна біда — утримання. Можливо, першу фічу попросив великий клієнт або її щойно випустили конкуренти. ШІ не має цього контексту, доки його не нададуть.
Слабке питання звучить як «що нам зробити?». Сильне — «з огляду на наші цілі, клієнтів, обмеження й ресурси, що нам зробити наступним?». Другому питанню потрібен контекст, тому продуктове мислення й лишається таким цінним.
8. Нестандартне розв'язання задач
Цю сферу найважливіше залишити за людьми. Шаблони допомагають зі знайомими задачами, але деякі інженерні проблеми по-справжньому нові: наявна архітектура не працює, вимоги суперечать одна одній, продуктивність дивно погана, продукт має незвичні обмеження або очевидне виправлення породжує нову проблему. Саме тут потрібна винахідливість.
Для мозкового штурму ШІ корисний, якщо не підміняє мислення. Добра послідовність: попросити п'ять нестандартних підходів, потім слабкі місця кожного, потім припущення, на якому все тримається, а потім — що буде, якщо очевидне рішення виключити. У такій ролі ШІ — напарник для роздумів, а не той, хто ухвалює рішення.
З автора в рев'юера
Можливо, це найбільший зсув, який приносить ШІ. Раніше розробники витрачали багато часу на написання коду. Тепер код генерується значно швидше, баланс навичок зміщується, і рев'ю стає важливішим. Питання, які варто ставити:
- Це правильно? Чи розв'язує код справжню задачу?
- Це безпечно? Чи є щось, чим може скористатися зловмисник?
- Це підтримуване? Чи розбереться в цьому колега за пів року?
- Це ефективно? Чи впорається код зі справжніми продакшен-даними?
- Це протестовано? Що відбувається на межах?
- Це сумісно? Чи вписується код у решту системи?
- Це потрібно? Чи не додається складність, яка нікому не потрібна?
Майбутнє, найімовірніше, не за тим, хто генерує найбільше коду. Воно за тими, хто добре оцінює код.
Погані розробники теж пришвидшуються
ШІ може підняти продуктивність, але може й пришвидшити випуск поганого софту. Без розуміння безпеки, архітектури, баз даних, мереж, тестування й продуктивності розробник дуже швидко отримає купу правдоподібного, але кривого коду. Це небезпечно.
Уявіть людину, яка не розуміє SQL і просить у ШІ запити до бази. Результат працює — до продакшену:
100 users
↓
Works perfectly
100,000 users
↓
Slow
10,000,000 users
↓
Production incident
Прогалину в знаннях створив не ШІ. Він лише пришвидшив появу результату.
Інший набір навичок
Сучасним розробникам потрібен трохи ширший набір умінь. Самого лише програмування вже недостатньо:
Programming
Краща картина виглядає так:
Programming
+
System Design
+
AI Collaboration
+
Code Review
+
Testing
+
Security
+
Product Thinking
ШІ — ще один інструмент в інженерному арсеналі.
Реалістичний день
Звичайний робочий процес із ШІ може виглядати так:
- Спершу розберіться в задачі. Прочитайте вимогу самі й не віддавайте її одразу ШІ: спочатку задача має стати зрозумілою.
- Попросіть альтернативи. Опишіть проблему й запросіть три підходи з компромісами. Так часто спливають варіанти, про які ніхто не думав.
- Виберіть. Цей крок лишається за людиною. Враховуються складність, досвід команди, продуктивність, вартість, підтримуваність і безпека.
- Згенеруйте шаблонний код. Тепер моделі, інтерфейси, обробники API, тести, документацію та базові компоненти може зробити асистент, і тут з'являється економія часу.
- Зробіть рев'ю. Прочитайте згенерований код повністю, а не лише перші рядки.
- Протестуйте. Запустіть юніт-тести, інтеграційні тести, ручні перевірки й граничні випадки. Якщо щось падає, передайте помилку назад ШІ.
ШІ бере на себе набирання тексту, а думати лишається людям.