Нейросети для программиста: поручайте изменение, которое можно проверить

Начните с карты проекта

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

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

Для другой модели можно использовать совместимую среду: DeepSeek документирует API и интеграции с агентными инструментами. Выбирайте отдельно качество модели и удобство окружения. Документация DeepSeek.

Задание должно помещаться в ревью

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

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

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

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

Тест должен спорить с ошибкой

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

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

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

Секреты не являются контекстом по умолчанию

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

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

В списках Anthropic Россия не указана среди поддерживаемых регионов Claude.ai и коммерческого API. Региональные условия. Доступ и оплату DeepSeek для российского аккаунта в этой статье не проверяли; выбор рабочего сервиса должен учитывать реальные условия команды.

Принимайте результат как работу коллеги

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

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

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