Нейросеть для программирования: процессы, которые снижают риск

Правила безопасной помощи ИИ в коде

Лучший способ использовать ИИ для программирования, это заставить его притормаживать ровно там, где догадки опасны. ИИ умеет объяснять незнакомый код, превращать ошибки в гипотезы, набрасывать тесты, проверять диффы и предлагать рефакторинг. Он также умеет выдумывать несуществующие API, не замечать скрытые зависимости, подстраиваться только под вставленный фрагмент и выдавать патч, который выглядит чисто, но меняет поведение, которое вы хотели сохранить.

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

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

Это справедливо для всех моделей. OpenAI, Anthropic и другие поставщики публикуют документацию, где описаны разные возможности, размеры контекстного окна и способы работы с инструментами. Эти возможности полезны, но они не заменяют дисциплинированный процесс. В инженерной работе оценивайте модели по тому же стандарту, что и коллегу: просят ли они недостающий контекст, снижают ли неопределённость, уважают ли ограничения и оставляют ли след, который можно проверить?

Процесс отладки

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

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

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

Этап 3: просите минимальный патч. Скажите модели не переименовывать переменные, не переписывать окружающий код, не добавлять зависимости и не менять публичное поведение, если она не может обосновать зачем. Попросите вернуть корневую причину, план патча, затронутые файлы, тесты и риск.

Этап 4: прогоняйте тесты локально. Вывод ИИ, это не шаг проверки. Шаг проверки, это команда или пользовательский сценарий, который доказывает поведение. Если автотеста нет, попросите модель сначала создать регрессионный тест, а уже потом реализовать исправление.

Промпт для отладки:

Работай как аккуратный напарник по отладке. Пока не пиши код. Сначала перескажи воспроизведение, ожидаемое поведение, наблюдаемое поведение и три самые вероятные корневые причины. Ранжируй каждую причину по доказательствам. Затем предложи минимальный диагностический шаг. Баг: [опишите]. Команда или действие пользователя: [вставьте]. Ошибка и логи: [вставьте]. Релевантный код: [вставьте]. Ограничения: [стек, файлы, которые нельзя трогать, поведение, которое нужно сохранить].

Промпт для исправления:

Исходя из подтверждённой корневой причины, предложи минимальное безопасное исправление. Верни: корневую причину, файлы и функции для изменения, план патча, тесты, которые падают до и проходят после, краевые случаи и риск отката. Не рефактори несвязанный код. Контекст: [вставьте].

Процесс ревью кода

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

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

Область ревью	На какие вопросы должен ответить ИИ
Корректность	Действительно ли дифф выполняет требование?
Риск регрессии	Какое существующее поведение может измениться случайно?
Безопасность	Учтены ли ввод, авторизация, секреты, права доступа и риски инъекций?
Обработка ошибок	Что происходит при null, таймаутах, повторах, плохих ответах или частичном состоянии?
Тесты	Какие утверждения о поведении не покрыты?
Поддерживаемость	Следует ли изменение принятым в проекте паттернам и остаётся ли понятным?

Промпт для ревью кода:

Проверь этот дифф как строгий, но практичный мейнтейнер. Сосредоточься на корректности, риске регрессии, безопасности, краевых случаях и недостающих тестах. Игнорируй мелкий стиль, если он не создаёт реального риска для поддержки. Верни таблицу с колонками проблема, приоритет, доказательство из диффа, предлагаемое исправление и нужный тест. Задуманное поведение: [вставьте]. Дифф: [вставьте]. Существующие тесты: [вставьте].

Для рискованных изменений используйте в Whizi сравнение правок от разных моделей. Запустите один и тот же промпт для ревью на двух или трёх моделях. Если одна модель нашла возможную проблему, не принимайте её вслепую: проверьте, реальна ли эта проблема в кодовой базе. Цель не в том, чтобы собрать побольше мнений. Цель в том, чтобы расширить площадь проверки до мержа.

Процесс рефакторинга и тестов

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

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

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

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

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

Промпт для плана рефакторинга:

Составь поэтапный план рефакторинга. Цель: [цель]. Текущий код: [вставьте]. Ограничения: сохранить публичное поведение, минимизировать объём правок, следовать существующим паттернам, не добавлять зависимости, держать каждую стадию тестируемой. Верни: инварианты, карту зависимостей, стадии, затронутые файлы, тесты по стадиям, риск отката и чек-лист для ревью.

Промпт для юнит-тестов:

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

Шаблоны промптов

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

Промпт для объяснения кода:

Объясни этот код разработчику, который только приходит в проект. Раскрой назначение, входные данные, выходные данные, поток данных, зависимости, режимы отказа и тесты, которые повысили бы уверенность. Отдели факты, видимые в коде, от допущений. Код: [вставьте].

Промпт по безопасности кода:

Проверь этот код на риски безопасности. Сосредоточься на авторизации, правах доступа, инъекциях, секретах, валидации, небезопасных редиректах, работе с файлами, риске зависимостей и утечке чувствительных данных. Верни только проблемы с доказательством, влиянием, предлагаемым исправлением и тестом или ручной проверкой. Код или дифф: [вставьте].

Промпт для сравнения правок от разных моделей:

Я сравниваю модели ИИ на задаче по коду. Используй только предоставленный контекст. Верни корневую причину, минимальное безопасное исправление, тесты, риски, допущения и вопросы. Оцени уверенность от 1 до 5 и перечисли, какие доказательства изменили бы твой ответ. Задача: [вставьте]. Контекст: [вставьте].

Чек-лист проверки перед тем, как принять код от ИИ:

• Модель правильно пересказала задачу.
• Патч меньше проблемы, а не больше.
• Публичное поведение и контракты названы явно.
• Тесты напрямую покрывают баг или цель рефакторинга.
• Краевые случаи и пути отказа перечислены.
• Чувствительные к безопасности входные данные проверены.
• Дифф следует существующим паттернам проекта.
• Вы запустили нужный тест, линтер, сборку или ручное воспроизведение.
• Финальный дифф просмотрел человек.

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