Как писать код с ИИ, чтобы потом не переписывать

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

Ничего из ниже перечисленного не замедляет работу заметно. Всё это экономит время уже через неделю.

Маленькие шаги

Самая частая ошибка — просить ассистента сделать большой кусок сразу: «добавь оплату, личный кабинет и уведомления». Он сделает. Где-то в этих сорока изменённых файлах будет решение, которое ты бы не принял, и найти его потом трудно.

Работай задачами, которые можно проверить за пару минут:

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

Git после каждого рабочего состояния

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

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

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

Читай дифф

Перед коммитом посмотри, что именно изменилось. Не нужно понимать каждую строку, но стоит заметить:

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

Если что-то непонятно, спроси ассистента, зачем это изменение. Ответ «не нужно, уберу» звучит чаще, чем хотелось бы.

Тесты как страховка от ассистента

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

Хороший признак — когда ассистент сам запускает тесты после правки и видит, что что-то упало. Плохой — когда тестов нет и о поломке ты узнаёшь от пользователя.

Файл с правилами проекта

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

- Стек: React + TypeScript, API на Node, база Postgres.
- Новые зависимости — только после вопроса.
- Доступ к базе — только через модуль db/, никаких запросов из компонентов.
- Секреты — только из переменных окружения.
- Перед коммитом: npm test и npm run lint должны проходить.
- Тесты не удалять и не отключать, чтобы они прошли.

Каждый раз, когда ассистент делает одну и ту же ошибку дважды, добавляй строку в этот файл.

Периодически наводи порядок

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

Итог

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

Если твой проект уже дошёл до стадии «страшно трогать», SUBXCAT может привести его в порядок и настроить процесс, чтобы дальше так не было.