Я використовую AI-інструменти щодня. Я веду курси з розробки з ними. Я не з тих, хто каже, що це хайп. Але за два роки спостережень за інженерами — включно з собою — я можу назвати ситуації, в яких AI стабільно робить роботу гіршою.
Якщо цього року ви прочитаєте одну контр-статтю про AI у розробці — нехай це буде ця. Ціна зловживання реальна і здебільшого невидима до моменту, коли стає дорогою.
Правило 1: не вчіть фундамент через AI
Це те, що я б написав на білборді.
Коли ви junior або беретеся за нову мову, спокуса непереборна. Питаєте Claude або Copilot, отримуєте робочу відповідь за 10 секунд, вставляєте, релізите. Баг виправлено. Далі.
Чого ви не зробили: не прочитали доку, не тримали структуру даних у голові, не боролися із системою типів, не побудували ментальну модель. Через пів року ви не можете дебажити свій код без AI. Не впізнаєте патерни. Ваші code review поверхневі, бо без AI не бачите, що не так.
Я спостерігав це у кількох junior-інженерів, яких менторив. Вони шиплять більше за перші три місяці, ніж junior’и раніше. До дев’ятого місяця — плато, з якого важко відновитися, бо фундаментальних повторень не було.
Евристика: якщо ви не можете написати код без AI — ви не знаєте тему. AI ок для другого разу, не для першого.
Правило 2: не використовуйте AI для імен, дизайну API та абстракцій
Це те, що найбільше дивує інженерів, коли я кажу це вголос.
LLM продукують технічно коректні імена та API. Вони майже ніколи не продукують хороших. Різниця — у смаку: знати, що processData() — це запах, що метод із 7 параметрами проситься в клас, що ця абстракція передчасна, а та запізніла. Смак будується роками підтримки чужого коду, особливо власного минулого.
Я перестав делегувати агенту:
- Імена функцій і методів
- Межі класів і зони відповідальності
- Дизайн API (які аргументи, яка форма повернення, які помилки)
- Коли виділяти абстракцію
- Коли не виділяти
Агент дасть захищувану відповідь на все це. Рідко правильну. Ціна спливає за місяці, коли ніхто вже не може прочитати код.
Правило 3: не дебажте production через AI без observability
Ця пастка частіше ловить senior’ів, ніж junior’ів.
Баг у проді. Ви вставляєте стектрейс у Claude. Він правдоподібно вгадує. Ви впроваджуєте фікс. Помилка перестає з’являтися в тестовому середовищі. Шипите. За два тижні помилка повертається.
Що сталося: стектрейс був симптомом, не причиною. Агент вгадав причину за симптомом — без ваших distributed traces, метрик, історії деплоїв і чотирьох пов’язаних помилок у ту саму годину. Він зробив фікс, що адресував щось, але не проблему.
Дебаг production вимагає:
- Відтворити або точно охарактеризувати збій
- Ізолювати, яка зміна його внесла
- Побудувати гіпотезу з реальних сигналів (логи, traces, метрики)
- Перевірити, що фікс реально адресував root cause
AI корисний на кроках 3 і 4 — але тільки після того, як ви зробили 1 і 2. Пропустите — і застосовуєте правдоподібні пластирі вічно.
Правило 4: не робіть через AI того, що не можете оцінити
Якщо не можете відрізнити хорошу відповідь від поганої — у вас немає підстав питати AI.
Звучить очевидно. Але це не так. Де це кусає:
- Пишете мовою, яку погано знаєте. Агент пише Rust, що компілюється і працює, але неідіоматичний. Шипите. Реальний Rust-інженер потім рев’юїть репо — і там початківські антипатерни.
- Архітектурні рішення поза вашим досвідом. «Kafka чи RabbitMQ?» — не питання з однією відповіддю; залежить від operational concerns, яких агент не бачить.
- Security-чутливий код. Агент дасть код, що виглядає безпечним. Дізнатися, чи реально — лише якщо розумієте threat model самі.
В усіх випадках AI не замінює експертизу. Він відмиває невігластво в output, який ви шипите, не розуміючи, що не розумієте.
Правило 5: не використовуйте AI для однорядкових правок
Це дрібниця, але реальна. Інженери тягнуться до AI, щоб вставити один рядок або перейменувати змінну. Чекають 4 секунди. Рев’юять результат. Приймають.
Та сама правка займає 1 секунду руками, якби просто зробили. Сукупний час очікування агента на тривіальних правках, за моїми вимірами, більший за час, який він економить на середніх.
Евристика: якщо пальці знають, що набирати — набирайте. Агент — для випадків, коли робота в тому, щоб вирішити, що набирати.
Правило 6: не використовуйте AI для того, що має бути в пам’яті
Те, що має жити в голові — домовленість з іншою командою, обмеження, якого немає в коді, політично тонкий компроміс, що пояснює дивацтва коду — це не можна делегувати агенту. У агента немає пам’яті цього між сесіями. Він відрефакторить дивний код, що існує з причини, яку ніхто не задокументував.
Документуйте чому. У коментарях коду де доречно, у CLAUDE.md якщо агенту треба знати, у design docs. «Чому» — частина інженерії, що не передається AI, і найцінніша.
Правило 7: не використовуйте AI, щоб пропустити code review
Ви написали код. (Навіть якщо набирав агент — ви написали, ви відповідаєте.) Прочитайте. Рядок за рядком. Вголос, якщо допомагає.
Інженери, які пропускають цей крок, бо «агент уже валідував», копичуть невидимий борг до моменту, коли він стає переважним. Валідація агента — статистична: цей код схожий на код, який працює. Це не те ж, що валідація вдумливої людини: цей код коректний для цієї системи, у цьому контексті, для того, чого я хочу досягти.
За два роки це патерн, що найбільше корелює з інженерами, чиї кар’єри буксують: вони ставляться до AI як до gate’у якості. Це не воно.
Що я роблю натомість
Для кожного випадку — що я реально роблю:
| Ситуація | Що я роблю |
|---|---|
| Вчу нову тему | Спочатку будую ментальну модель. AI — для другого проєкту, не першого. |
| Імена | Пишу три варіанти руками. Обираю кращий. Іноді прошу AI критику. |
| Production-дебаг | Підтягую логи, traces, метрики. Формую гіпотезу. Потім AI допомагає з фіксом. |
| Код поза моєю експертизою | Парю з людиною-експертом, коли ставка виправдовує. AI — не заміна. |
| Тривіальні правки | Набираю. Швидше, без перемикання контексту. |
| Важливий контекст | Документую. У коді, у CLAUDE.md, у design doc. |
| Code review | Читаю кожен рядок, кожного разу. AI — junior-колаборатор, не senior. |
Глибше
Фрейм, який я б запропонував кожному інженеру задавати перед тим, як тягнутися до AI:
Який навик я будую — і AI робить мене сильнішим чи слабшим у ньому?
Для механічної роботи AI робить сильнішим, звільняючи час для важливої роботи.
Для роботи судження AI робить слабшим, дозволяючи аутсорсити повторення, що будують судження.
Інженери, які процвітатимуть наступне десятиліття — ті, хто бачить різницю. Не ті, хто використовує AI агресивніше, і не ті, хто його відкидає. Ті, хто точно знає, коли відкласти.
Якщо хочете структурований шлях до роботи з AI як реальним інженерним інструментом — з чесним розбором tradeoffs — почніть з Prompt Engineering і автоматизації AI-воркфлоу. Глибше в production AI-системи — курси Розробка на Claude API та Claude Code Mastery підхоплюють там, де стаття закінчується.
