Поддержка: как не утонуть в своём вайбкоде

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

Энтропия: агент копирует всё, что видит

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

Команда OpenAI в статье о harness engineering описывает, как сначала убирала за агентами вручную каждую пятницу — и это не масштабировалось. Решением стали «золотые принципы», записанные в репозитории, и регулярная уборка небольшими задачами. Для проекта размером с «Переговорки» хватит еженедельной сессии:

Уборка. Прочитай AGENTS.md и docs/decisions/.
Найди в apps/ отклонения от соглашений: типы API вне packages/shared,
маршруты без Zod-схемы, ручную работу с датами, дублирующиеся хелперы,
мёртвый код, TODO старше месяца. Ничего не меняй.
Дай список, сгруппированный по типу, с оценкой размера исправления.

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

Документация, которая не врёт

Спецификация и решения полезны, только пока совпадают с кодом. Через пару месяцев правок docs/SPEC.md начинает описывать продукт, которого уже нет, а агент добросовестно следует устаревшему документу. Два приёма:

• в AGENTS.md правило «изменил поведение — обнови SPEC.md в том же коммите» (оно у нас уже есть в определении «готово»);
• периодическая сверка в отдельной сессии:

Сверь docs/SPEC.md с кодом и тестами. Для каждого правила R и сценария S:
реализовано ли так, как написано; есть ли поведение в коде, которого нет
в спецификации. Расхождения — таблицей. Ничего не исправляй.

Расхождение — это вопрос к вам: устарел документ или код делает не то. Решение принимаете вы.

Когда проект подрастёт, добавьте короткий ARCHITECTURE.md: какие модули есть, как идёт запрос от экрана до базы, где живут правила. Это карта и для агента, и для человека, который придёт после вас.

Баг из продакшена

Офис-менеджер пишет: бронь на 20:45–21:00 не создаётся, хотя по правилу R2 можно бронировать до 21:00. Порядок работы с багом:

Баг: бронь 20:45–21:00 отклоняется, по R2 она допустима.
1. Воспроизведи интеграционным тестом, покажи, что он падает.
2. Найди причину и исправь минимальным изменением.
3. Поищи в коде места с похожей ошибкой границы интервала
   (сравнения с концом рабочего дня, недели, 30 дней вперёд) и перечисли их.

Третий шаг — самый ценный. Ошибка на границе редко бывает единственной: если конец дня сравнивался через < вместо <=, то и «30 дней вперёд» скорее всего посчитано так же. Подробнее о работе с багами — в уроке «Баг: воспроизвести, починить, закрепить тестом».

Понимать свой код

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

Уиллисон в гайде Agentic Engineering Patterns описывает приём линейного разбора: попросить агента провести по коду последовательно, как по экскурсии. Делайте это для каждого модуля, который вы ни разу не читали:

Проведи меня по пути запроса POST /api/bookings: от формы в интерфейсе
до записи в базу и ответа. Для каждого шага — файл, функция, что проверяется.
Отдельно отметь места, где поведение неочевидно или может удивить.

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

Зависимости

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

Сигналы, что проект тонет

• Простые изменения ломают несвязанные места.
• На каждую задачу агенту нужно всё больше попыток.
• AGENTS.md растёт быстрее кода.
• Есть модуль, который все боятся трогать — включая агента.
• Тесты падают «иногда», и их перезапускают.

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

Автоматизировать уборку

Регулярные задачи можно запускать по расписанию в ChatGPT desktop app или в веб-версии — из CLI и IDE расписания не управляются. Документация Codex предупреждает об антипаттерне: ставить на расписание то, что ещё не работает надёжно вручную. Сначала проведите уборку руками несколько недель подряд и доведите промпт, потом автоматизируйте. Подробно — в уроке «Задачи по расписанию».