Багато людей використовують Claude Code для написання коду, насправді залишаючись на рівні «де щось зламалося — виправляємо саме там».

Це також один із найпростіших способів зіпсувати проект, яким я останні кілька днів постійно користуюся, переймаючи досвід великих майстрів і вдосконалюючи проект.
Оскільки справжні баги у проекті зазвичай не є ізольованими маленькими дірками.
Коли ви бачите повідомлення про помилку, аномалію на сторінці, несправність кнопки — це швидше за все гострий кут, що з’явився через системну проблему.
Якщо ви просто кинете цей гострий кут AI і скажете «Допоможи виправити», він дуже ймовірно просто згладить цей гострий кут.
Зовні все виглядає добре, але внутрішня логіка залишилася незмінною.
Наступного разу, у іншому сценарії, ця сама проблема знову спалахне.
Ще раз — і знову потрібно додавати виправлення, але насправді це одна й та сама логіка помилки.
Врешті-решт у коді з’являються цілі патчі, проект все ще працює, але вже все менше і менше боїться змін.
Тому зараз я використовую Claude Code і маю дуже важливу звичку:
Не просити його одразу змінювати код, спершу — щоб він визначив, чому ця проблема виникла.
Я схиляюся до такого запитання:
Спершу — не виправляй.
Допоможи мені проаналізувати корінь цієї проблеми.
Можливо, у якійсь шарі дизайну, потоці станів, структурі даних або граничних умовах виникла помилка?
Тоді роль AI змінюється.
Він не просто «аутсорсинг для виправлення багів», а «людина, яка допомагає тобі розслідувати систему».
Ця різниця дуже велика.
Ти не повинен давати йому лише один фрагмент повідомлення про помилку, а намагатися надати максимально повний контекст: відповідні файли, ланцюжки викликів, шлях користувача, очікуваний результат, фактичний результат, що було змінено раніше.
Чим повніший контекст, тим більше шансів, що він допоможе тобі побачити справжню проблему, а не просто наклеїти патч на поверхні.