Как писать код с нейросетью и не потерять контроль

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

Ниже — процесс, который подойдёт и человеку с одним репозиторием, и команде. Его можно использовать в редакторе с агентом, например в карточках Cursor или Claude Code, но правила не зависят от конкретного инструмента.

Сначала сформулируйте маленький результат

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

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

Вот рабочая заготовка для первого сообщения:

Опиши план изменения, прежде чем писать код. Нужно: [результат]. Файл: [путь]. В проекте используется [стек]. Нельзя менять публичный API и добавлять зависимости. Сначала перечисли затронутые файлы, крайние случаи и тесты. Команды ничего не запускай.

Фраза «команды ничего не запускай» особенно важна для агентов, у которых есть доступ к терминалу. Сначала нужен план, а не необратимое действие.

Попросите не ответ, а дифф

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

Перед применением диффа задайте себе три вопроса. Что изменилось? Почему это действительно решает задачу? Что может измениться для старых пользователей? Если на любой вопрос нельзя ответить после чтения кода, попросите модель пояснить конкретную строку или переписать решение проще. Это не формальность: красивое объяснение рядом с неверным кодом тоже возможно.

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

Проверяйте на случаях, а не на впечатлении

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

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

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

Секреты и опасные действия держите вне чата

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

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

Сделайте короткий журнал решений

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

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

Чек-лист перед слиянием

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

Проведите ревью через сценарий отказа

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

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

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

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