Многие используют Claude Code для написания кода, на самом деле всё ещё оставаясь на этапе «где сломалось — там и починим».

Это один из самых легких способов испортить проект, я в последние дни тоже постоянно совершенствовал проект, черпая идеи у гуру.
Потому что реальные баги в проекте обычно не представляют собой изолированные маленькие дыры.
Когда вы видите ошибку, сбой страницы или неработающую кнопку, скорее всего, это лишь острый угол, возникший из-за системной проблемы.
Если вы просто бросите этот острый угол ИИ и скажете «помоги исправить», он скорее всего просто сгладит этот острый угол.
На поверхности всё будет хорошо, а внутренняя логика останется без изменений.
В следующий раз, при смене ситуации, та же проблема снова взорвётся.
И ещё раз, добавляя исправления, — всё равно это одна и та же ошибка.
В итоге в коде будут сплошные патчи, проект всё ещё работает, но всё меньше хочется его трогать.
Поэтому сейчас я использую Claude Code и выработал важную привычку:
Не просить его сразу менять код, сначала пусть он определит, почему возникла проблема.
Я предпочитаю спрашивать так:
«Пока не исправляй.
Помоги проанализировать коренную причину этой проблемы.
Может, проблема в каком-то уровне проектирования, управлении состоянием, структуре данных или граничных условиях?»
В этот момент роль ИИ меняется.
Он уже не «аутсорс по исправлению багов», а «помощник в системном анализе».
Эта разница очень велика.
И в качестве входных данных ему не стоит давать только сообщение об ошибке, а стараться предоставить полный контекст:
связанные файлы, цепочку вызовов, путь пользовательских действий, ожидаемый результат, фактический результат, что было изменено ранее.
Чем полнее контекст, тем больше шансов, что он поможет вам увидеть истинную проблему, а не просто наклеить патч на поверхность.