Безопаснее всего учиться тому, как программировать с ИИ, на одной ограниченной задаче: дайте модели достаточно контекста, чтобы понять её, и цель проверки, которую вы сможете оценить сами. Считайте модель быстрым напарником по парному программированию, который умеет изучать код, объяснять и предлагать изменения, но не вправе сам решать, когда код правилен.

Сначала полезно освоить общий процесс работы с ИИ. В программировании красивого ответа недостаточно: нужны небольшой diff, воспроизводимые тесты и явное условие остановки.

Ключевые выводы

Задайте вход, ожидаемый результат и то, что менять нельзя.

Передавайте только необходимый контекст и удаляйте секреты.

Сначала запросите чтение и план, а уже потом разрешайте правки.

До запуска проверьте diff, зависимости, разрешения и внешние эффекты.

Тестируйте обычные, граничные и ошибочные сценарии независимо от модели.

Как программировать с ИИ и сохранять контроль?

Используйте цикл из пяти контрольных точек: определить, изучить, предложить, проверить и подтвердить. ИИ может помогать на каждом этапе, но решение о переходе к следующему остаётся за вами. GitHub предупреждает, что сгенерированный код может быть неточным или небезопасным и требует человеческой проверки и тестирования.［1］

Процесс подходит для исправления небольшой ошибки, точечного теста, локального скрипта или ограниченного рефакторинга. Он плохо подходит для неопределённого переписывания, срочного изменения в рабочей среде или задачи, ради которой пришлось бы раскрыть учётные данные и данные клиентов. Если задачу нельзя описать коротким чек-листом приёмки, сузьте её, прежде чем просить код.

Выберите изменение с наблюдаемым провалом

У удачной первой задачи есть наблюдаемый контракт. «Сделай так, чтобы parse_duration отклонял отрицательные значения, сохранив корректную обработку секунд и минут» лучше, чем «почисти парсер». Первый запрос называет поведение и границу совместимости, второй приглашает к неограниченной переделке.

Запишите четыре пункта:

Текущее поведение: что происходит сейчас, включая команду или тест, которые это показывают.
Ожидаемое поведение: что должно происходить после изменения.
Вне рамок задачи: файлы, публичные интерфейсы, зависимости или форматирование, которые менять нельзя.
Доказательство: тесты или ручные наблюдения, по которым решается, выполнена ли задача.

Храните этот список вне чата как источник истины. Если модель позже предложит более широкое изменение, сравнивайте его со списком, а не договаривайтесь по памяти.

Шаг 1: Подготовьте небольшой безопасный контекст

Не отправляйте весь репозиторий по умолчанию. Начните с падающего теста, нужной функции, ключевых вызовов, публичного контракта и правил репозитория. Добавляйте файл только тогда, когда можете объяснить, чего не хватает.

Удалите или замените:

API-ключи, пароли, cookie, закрытые ключи и файлы окружения;
имена клиентов, адреса электронной почты, переписку с поддержкой и данные запросов из рабочей среды;
внутренние имена хостов, токены в выводе команд и подписанные ссылки для скачивания;
проприетарный код, который ваша организация не разрешила передавать выбранному инструменту.

Если настоящая проблема — доступ и подключение, используйте отдельную памятку по доступности инструментов для кода. Не смешивайте разбор аккаунта или сети с генерацией кода: так контекст сложнее проверить, а передача учётных данных становится более вероятной.

Используйте тестовые данные вместо рабочих

Воспроизведите поведение на синтетических входных данных. CSV из шести строк, временная база SQLite или крошечное дерево каталогов проще проверить, чем выгрузку из рабочей среды. Тестовые данные должны быть детерминированными, чтобы другой разработчик мог выполнить ту же команду и получить тот же результат.

Для первой задачи скопируйте минимальный разрешённый пример в отдельную ветку, рабочее дерево (worktree), контейнер или одноразовый проект. Изоляция не доказывает безопасность сгенерированного кода, но ограничивает случайные записи, пока вы ещё изучаете, что может делать инструмент.

Шаг 2: Сначала запросите чтение и план

Начните с запроса только на чтение. Попросите модель найти связанные файлы, объяснить текущий поток управления, перечислить неясности и предложить минимальное изменение. Отдельно укажите, что на этом этапе нельзя редактировать файлы и запускать команды.

Практичный промпт выглядит так:

Изучи парсер и тесты. Объясни, почему принимаются отрицательные значения. Предложи минимальное исправление без изменения публичного типа и новой зависимости. Перечисли файлы, тесты и непроверенные предположения. Пока ничего не меняй и не запускай.

Ответ должен быть проверяемым. Список файлов можно сравнить с репозиторием, утверждение о потоке управления — проверить по вызывающему коду, а неясность — разрешить до первой правки. Общий абзац об «улучшении валидации» проверять не по чему.

Интерфейс и разрешения конкретного терминального агента разобраны в руководстве по Claude Code. Здесь важна граница действия, а не название продукта.

Шаг 3: Запросите минимальный патч

Когда план соответствует чек-листу приёмки, разрешите только нужную правку. Повторите в запросе исключения: без обновления зависимостей, без изменения публичного API, без форматирования за пределами затронутых строк и без попутной уборки. Попросите модель остановиться, если окажется, что одно из ограничений соблюсти нельзя.

Предпочитайте патч, который легко откатить. Одно изменение поведения и один регрессионный тест понять проще, чем многофайловую абстракцию «для гибкости в будущем». Если ради ошибки в одной строке модель хочет переименовать файлы, перестроить модули и обновить конфигурацию, вернитесь к плану и спросите, какое изменение действительно необходимо.

Это контролируемый пример с синтетическим парсером. Здесь нет рабочего репозитория, аккаунта, данных клиентов или секретов, и пример не утверждает, что сгенерированный патч прошёл проверку.

Проверяйте команды отдельно от объяснений

Не позволяйте полезному объяснению скрыть рискованную команду. Выписывайте каждую предложенную команду в список для проверки и классифицируйте её до выполнения:

Класс	Примеры	Действие по умолчанию
Только чтение	поиск по файлам, вывод теста, просмотр diff	Обычно безопасно в одобренной рабочей области
Локальная сборка	компиляция, точечный тест, создание кэша	Сначала проверить расход ресурсов и побочные эффекты скриптов
Изменяющие	установка зависимостей, перезапись снимков, миграции	Требовать явную причину и проверку
Внешние	вызов API, выгрузка кода, push, развёртывание, отправка сообщения	Остановиться, пока не ясны полномочия и адресат
Разрушительные	удаление данных, сброс состояния, перезапись релизов	Не выполнять как исследовательский шаг

OpenAI описывает песочницу и политики одобрения как взаимодополняющие меры: песочница задаёт техническую границу, а одобрения решают, когда действие может её пересечь.［2］ Просьба «быть осторожным» не заменяет ограничения файлов, сети, идентичности и команд.

Шаг 4: Проверьте весь diff до запуска

Читайте патч в том порядке, в котором его «увидит» компьютер: конфигурация и зависимости, публичные интерфейсы, преобразования данных, внешние эффекты и тесты. Если изменение затрагивает аутентификацию, хранилище, дочерние процессы, сетевые вызовы или миграции, используйте чек-лист проверки кода ИИ до запуска.

Задайте себе вопросы:

Относится ли каждый изменённый файл к одобренной задаче?
Не изменил ли патч lock-файл, источник зависимостей, хук сборки или сгенерированный артефакт?
Может ли недоверенный ввод попасть в оболочку, запрос, шаблон, путь, URL или десериализатор?
Не изменились ли права доступа, значения по умолчанию, обработка ошибок или логика повторных попыток?
Доказывает ли новый тест требование или просто повторяет реализацию?
Что произойдёт, если ввод пустой, некорректный, слишком большой, повторяющийся или прерванный?

Читайте итоговый код, а не только резюме модели: резюме может умолчать об изменённом значении по умолчанию или лишнем файле. Если вы не понимаете строку, попросите объяснение и сверьте его с документацией языка или фреймворка до запуска.

Шаг 5: Проверьте обычный, граничный и ошибочный путь

Запустите минимальную надёжную команду, которая доказывает изменённое поведение. Начните с нового регрессионного теста, затем — ближайшая группа существующих тестов. Более широкие проверки — линтер, проверку типов, сборку и интеграционные тесты — запускайте только после того, как точечный тест дал полезный сигнал.

Используйте три класса доказательств:

Путь	Пример для парсера длительности	Что доказывает
Обычный	`15s` и `2m` по-прежнему разбираются	Корректное совместимое поведение сохранено
Граничный	`0s`, максимальное допустимое значение, пробелы	Граничные случаи соответствуют документированному контракту
Ошибочный	`-1s`, пустой ввод, неподдерживаемая единица	Некорректный ввод отклоняется ожидаемым образом

Не просите ту же модель объявить собственный патч правильным. Пусть она предлагает недостающие случаи, но независимыми доказательствами служат тесты репозитория, компиляторы, линтеры, статический анализ и проверка человеком. NIST Secure Software Development Framework рассматривает ревью и анализ кода как часть более широкой практики безопасной разработки, а не считает результат одного инструмента доказательством готовности к выпуску.［3］

Если тест падает, сохраните вывод ошибки и перейдите к отладке с ИИ на основе доказательств. Не разрешайте сразу очередное масштабное переписывание.

Запишите непроверенное

Успешный локальный тест не доказывает правильность конфигурации рабочей среды, поведения операционной системы, состояния внешних сервисов или успеха развёртывания. Составьте короткую записку для передачи работы:

изменённые файлы и ожидаемое поведение;
выполненные команды и их точная область действия;
тесты, которые не запускались, и причина;
допущения, которые ещё зависят от другой среды;
путь отката или отмены изменения;
проверяющий, который нужен для решений о безопасности, данных или архитектуре.

Такая записка — часть результата. Она не даёт фразе «ИИ сказал, что всё работает» стать единственной записью о том, что произошло.

Когда нужно остановиться?

Остановитесь, если задача пересекает границу, которую вы не разрешали, модели нужны чувствительные данные, патч не удаётся сохранить небольшим или ожидаемое поведение оспаривается. Остановитесь и тогда, когда тот же сбой повторяется без новых доказательств: при неясных критериях приёмки дополнительные итерации не помогут.

Передайте задачу ответственному человеку, если она связана с учётными данными рабочей среды, необратимыми миграциями, юридическими или лицензионными вопросами, авторизацией с серьёзными последствиями, реагированием на инцидент или системой, которую нельзя безопасно протестировать. Часто продуктивнее вернуть сфокусированное исследование, чем навязывать патч.

Если логи или код всё же нужно передать внешнему сервису, сначала примените правила минимизации данных для ИИ. Обезличивание и минимальные привилегии нужны до загрузки, а не после неожиданного ответа.

Итоги

Определите одно наблюдаемое поведение и исключения.
Передавайте минимальный обезличенный контекст, по возможности построенный на синтетических тестовых данных.
Сначала запросите изучение кода и план, затем правки.
До выполнения проверьте полный diff и каждую предложенную команду.
Подтвердите обычные, граничные и ошибочные случаи надёжными инструментами репозитория.
Записывайте непроверенные среды и возвращайте задачу, если риск или неясность выходят за пределы ваших полномочий.

Часто задаваемые вопросы (FAQ)

Может ли новичок писать код с ИИ?

Да, если задача достаточно мала, чтобы её проверить, и новичок может выполнить независимую проверку. Начинайте с объяснений, тестов и ограниченных изменений, а не с целого приложения.

Нужно ли отправлять весь репозиторий?

Нет. Передавайте минимальный одобренный набор файлов, объясняющий задачу, и удаляйте секреты и персональные данные. Прежде чем пользоваться внешним сервисом, следуйте политике организации по работе с кодом.

Можно ли сразу запускать код ИИ?

Не по умолчанию. Проверьте diff, зависимости, права доступа, внешние эффекты и команды, а затем запускайте код в надлежащим образом ограниченной среде с соответствующими тестами.

Можно ли разрешить автоматическую установку зависимостей?

Только после того, как вы проверите, зачем нужна зависимость, откуда она берётся, что меняется в lock-файле и нельзя ли решить задачу уже имеющейся зависимостью. Установка — это изменяющее действие в цепочке поставок ПО, а не безобидный шаг объяснения.

Что делать, если я не понимаю код?

Не запускайте его и не сливайте в основную ветку. Попросите построчное объяснение, сверьте поведение с официальной документацией и привлеките проверяющего, который знает язык и затронутую систему.

Насколько большой должна быть первая задача?

Одно поведение, небольшой участок кода и одно ясное доказательство. Если изменение требует новой архитектуры, нескольких миграций или неясного доступа к рабочей среде, разделите его, прежде чем подключать ИИ.

Прошедший тест доказывает правильность?

Нет. Тест доказывает только тот сценарий, который он выполняет в данной среде. Сочетайте тесты с проверкой diff, статическим анализом, нужными интеграционными доказательствами и явными заметками о том, что осталось непроверенным.

Отказ от ответственности: статья содержит общие технические рекомендации. Прежде чем передавать код или запускать сгенерированные изменения, выполните требования вашей организации к безопасности, приватности, лицензированию и управлению изменениями.

Источники:

GitHub Docs — Responsible use of GitHub Copilot Chat in GitHub — https://docs.github.com/copilot/responsible-use/chat-in-github
OpenAI — Running Codex safely at OpenAI — https://openai.com/index/running-codex-safely/
NIST — Secure Software Development Framework — https://csrc.nist.gov/projects/ssdf

Sources checked 24 августа 2026 г.

Рекомендуемые статьи:

Как программировать с ИИ: безопасный процесс для новичка