Первый год изучения программирования я принципиально не пользовался ИИ - считал, что настоящий разработчик решает проблемы сам, поэтому тратил около 10 часов на баг вместо секунд с ChatGPT. Этот год выработал навыки отладки и поиска решений, которые ИИ так и не заменил. Именно поэтому сейчас я использую ИИ активно, но осторожно - следуя 4 правилам.
TL;DR
- Год отладки без ИИ дал мне базу, благодаря которой я теперь хорошо использую ИИ.
- ИИ пишет в своём архитектурном стиле - проверяйте каждое изменение перед тем, как оно попадёт в кодовую базу.
- Относитесь к ИИ как к сотруднику, которого онбордите каждый день: общие инструкции и переиспользуемые скиллы важнее разовых промптов.
Год, когда я решил, что ИИ не считается
Когда я начал учить fullstack, у всех вокруг был открыт ChatGPT во вкладке рядом. Любой баг, любой "как это сделать" - сразу в чат. Меня это бесило. Тогда я искренне считал: если ты умеешь писать код только с ИИ, ты не заслуживаешь называться разработчиком или инженером. Настоящий инженер чинит баг сам и пишет код лучше, чем это сделает ИИ.
Поэтому первый год я вообще не трогал ИИ. StackOverflow, документация, любой форум, который выдавал Google в час ночи. Некоторые баги отнимали по 10 часов. Не потому что фикс был сложным - а потому что я понятия не имел, что именно ищу, и весь смысл был в том, чтобы это выяснить.
Чему на самом деле меня научил год без ИИ?
Не тому, что избегать ИИ - правильная стратегия навсегда. Вот что он на самом деле выработал:
- Привычку нормально читать текст ошибки, а не сразу копировать её куда-то и ждать ответа.
- Привычку сначала формировать гипотезу, а потом её проверять.
- Терпение исследовать, а не гадать.
Именно эти навыки сейчас позволяют мне хорошо пользоваться ИИ - я вижу, когда его ответ неправильный, потому что знаю, как выглядит правильный. Именно это сегодня пропускает большинство новичков. Если лимит Claude Code закончился - рабочий день окончен. Не потому что работа кончилась, а потому что без ИИ, держащего ручку за тебя, делать её нечем.
И это не значит избегать ИИ. Наоборот - именно здесь он и раскрывается по-настоящему. Тесты, локализация, адаптивная вёрстка, всё повторяющееся и не завязанное на логику - теперь я отдаю это ИИ, и это реально быстрее, чем делать руками. 4 правила ниже не про то, чтобы избегать автоматизации. Они про то, какие части работы можно спокойно доверить, а какие всё ещё твои.
Правило 1: сначала чини сам, потом открывай Claude Code
Это правило, которое я нарушаю реже всего - намеренно. Прежде чем дать ИИ тронуть баг, я даю себе честную попытку:
- Читаю ошибку в терминале и стектрейс (вывод Node или tsc).
- Проверяю очевидные места.
- Формирую гипотезу.
В большинстве случаев это само по себе доводит меня на 80% пути, а ИИ просто подтверждает или добивает остаток. Почему это важнее, чем кажется: я не раз видел, как ИИ "чинит" баг и тихо ломает что-то другое в двух файлах в стороне - потому что оптимизировал под симптом, который я описал, а не под систему вокруг него. Если ты сам не построил ментальную модель этой системы, второй слом ты заметишь уже в проде.
Почему код ИИ никогда не совпадает с твоим?
У каждого разработчика есть свой почерк в коде: как называть переменные, структурировать папки, работать со стейтом, делить логику. У ИИ он тоже есть, и это не твой почерк. В зависимости от модели и версии он по умолчанию тянет к своей архитектуре, если ты жёстко его не ограничишь, и это дефолтное решение редко совпадает с кодовой базой, в которую он только что попал.
Яснее всего я вижу это, когда по работе проверяю vibe-coded сайты на SEO и видимость для ИИ - дизайн часто реально хорош, но код и поисковая видимость обычно хромают: нет семантической структуры, слабые метаданные - то, что никто не проверил, потому что никто и не проверял, просто нажимали allow. Я писал о смежной проблеме дисциплины в аудите своих коммитов - та же причина, другой симптом: никто не проверил результат до того, как он стал постоянным.
Правило 3: относись к своему ИИ как к новому напарнику, а не к поисковику
Я использую Claude и Copilot параллельно, а раньше это означало вести два отдельных набора инструкций:
- Раньше:
CLAUDE.mdиcopilot-instructions.md, дублированные - постепенно расходящиеся, стоило обновить один и забыть про другой. - Теперь: и
.claude, и.githubссылаются на одну и ту же папку со скиллами через симлинк вместо копии - один источник правды.
Единственный скилл, который я использую каждый день - это пара update-llms и create-llms. Они держат актуальным llms-контекстный файл после каждого коммита, так что когда я - или кто-то другой - подтягивает репозиторий, его ИИ уже понимает логику проекта, а не выводит её заново с нуля. Одно это заметно сокращает расход токенов на исследование, и ответы становятся ощутимо лучше, когда ИИ не гадает о контексте, который у него и так должен был быть.
Правило 4: как на самом деле проверять код, который не понимаешь?
Просишь его перефразировать самого себя. Не "объясни этот код" - в ответ обычно получаешь стену технического пересказа, которую так же сложно разобрать. Проси ИИ объяснить логику простыми словами, как будто объясняешь напарнику, который никогда не видел этот файл. Если он не может упростить собственный вывод до того, что ты реально понимаешь - это сигнал притормозить до того, как принять код, а не после того, как он уедет в прод.
Привычка маленькая, но именно она отличает "принял код" от "понял, что только что задеплоил".
Настоящий тест - не в том, пользуешься ли ты ИИ
А в том, смог бы ты обойтись без него, если бы пришлось. В следующий раз, когда собираешься принять предложение ИИ, остановись на пять секунд и спроси себя: понимаешь ли ты его достаточно, чтобы написать самому, просто медленнее? Если ответ "нет" - это не повод отклонять код.
Это повод притормозить перед тем, как взять его в прод - потому что после коммита он твой, а не ИИ.
ИИ может починить твой баг. Но не может научить тебя, почему он там появился.
Октай Искендеров
Дизайнер и фулстек-разработчик, веду klauzzdcode - студию одного человека в Баку. На фрилансе с 2023 года: выкатываю продукты от Figma до деплоя и записываю то, что переживает контакт с продакшеном.