Разработчики рано или поздно начинают работать с ИИ — вопрос лишь в том, осознанно или вслепую. Слепая работа выглядит так: скопировал задачу в чат, вставил ответ в проект, потратил вечер на отладку того, чего не писал. Этот курс — про осознанный путь: что именно должен уметь разработчик, чтобы ИИ ускорял работу, а не создавал скрытые проблемы.
Навык 1. Формулировать задачи
Модель делает ровно то, что вы описали, а не то, что имели в виду. Хороший запрос на код содержит: контекст проекта (язык, стек, ограничения), описание поведения и критерии готовности. Сравните: «напиши функцию логина» и «напиши функцию проверки пароля на Node.js с bcrypt, лимит 10 попыток, ошибки — единый формат без деталей».
Это умение прямо переносится из общего промпт-инжиниринга — здесь оно просто применяется к коду.
Навык 2. Декомпозировать
Большие задачи «сделай фичу корзины» проваливаются чаще, чем цепочка маленьких: схема данных → эндпоинт → обработка ошибок → тесты. Маленькие порции кода легче проверить, а ошибки не наслаиваются. Правило практиков: одна итерация с ИИ — один обозримый кусок работы.
Навык 3. Проверять
Сгенерированный код — это черновик от очень быстрого стажёра с отличной памятью и без чувства ответственности:
- Читать перед запуском. Непонятный код не вставляют в проект.
- Прогонять линтер и тесты. Автоматика ловит то, что глаз пропустит.
- Проверять зависимости. Модель предсказывает правдоподобные имена пакетов и методов, не проверяя их существование, — выдуманный пакет в реестре может оказаться вредоносным.
- Смотреть на безопасность. Секреты в коде, слабая валидация, инъекции — типичные слепые зоны генерации.
Навык 4. Отвечать за результат
«Это ИИ написал» не снимает ответственности: в продакшен уходит ваш коммит. Финальное решение, ревью и последствия — на разработчике, как и при работе с любым инструментом. Подробнее об этом — в материале «Ответственность за результат».
Рабочий процесс
Практичная связка выглядит так: сформулировать задачу с критериями → получить черновик → проверить (линтер, тесты, чтение) → попросить правки точечно → зафиксировать и задокументировать. ИИ вписывается в каждый этап цикла разработки — от планирования до документации — но порядок «сначала думаем, потом генерируем, потом проверяем» не меняется.
Границы и безопасность
- Не отправляйте в обычные чаты проприетарный код и секреты — для работы с чувствительным кодом существуют корпоративные тарифы с другими гарантиями.
- Лицензия сгенерированного кода — ваша зона внимания: модель обучена на открытом коде и может воспроизводить характерные фрагменты.
- Свежие версии библиотек модель может не знать — сверяйтесь с документацией.
Ключевые выводы
- ИИ-грамотность разработчика — это формулирование, декомпозиция, проверка и ответственность.
- Маленькие порции кода проверять проще, чем одну большую фичу.
- Выдуманные пакеты и методы — не сбой, а свойство модели; зависимости проверяем всегда.
- Секреты и проприетарный код в обычные чаты не отправляем.
- В продакшен уходит ваш коммит — и ваша ответственность.
Что дальше
Разберу тему глубже туториал «Как проверять ИИ-код» и материал «Ответственность за результат». Общий контекст работы с инструментами — в курсах «ИИ в цикле разработки ПО» и «Агенты: что это, как работают и когда нужны».