Вайбкодинг и репозиторий: что AI-агент делает с вашим кодом и как не дать ему сломать продукт

9 мая 2026, понедельник. Открываю свой сайт vaai.ru — а там старая версия двухнедельной давности. Старое меню, старые статьи, без всех изменений, которые делались на прошлой неделе. Будто целая неделя работы куда-то делась.

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

На разбор полётов ушло два дня. История оказалась такая.

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

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

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

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

Эта общая память называется репозиторием. Дальше — как она устроена на бытовом уровне, что значат слова агента, когда он отчитывается о работе, и какие правила надо прописать у себя на проекте, чтобы такого странного понедельника не случалось.

Коротко

• Репозиторий — это не «папка для программистов». Это общая память проекта, в которой видно, кто что менял, когда и зачем. Без неё работа быстрого агента не видна ни вам, ни другим агентам, и через час уже не разобрать, что он сделал.
• Когда агент говорит «сделал коммит», «запушил», «открыл pull request» — он рассказывает, где сейчас живёт его работа: только у себя на компьютере, в общем хранилище, или уже добавлена в основную версию проекта. Эти три состояния нужно различать.
• Самая частая поломка вайбкодинга — агент работает напрямую в основной версии или не выгружает изменения в общую память. В первом случае ломается готовый продукт, во втором — работа просто пропадает.
• Если на проекте больше одного агента, между ними обязательно должен быть письменный договор — что считать правдой, куда сохранять, кто что трогает. Этот договор обычно живёт в файле с именем AGENTS.md в самом проекте, на видном месте.
• Хорошие правила работы с общей памятью — это не про чистоту кода. Это про то, чтобы вы могли вернуться к прошлому понедельнику, если в среду что-то пошло не так. Без этого AI-агент — это ускоритель хаоса, а не ускоритель работы.

Зачем вайбкодеру репозиторий

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

Агент быстрый. Очень быстрый. За один час он может тронуть двадцать файлов, что-то добавить, что-то переписать, что-то удалить — и отчитаться вам в одну строчку: «всё готово».

Если у проекта нет общей памяти, через час вы уже не сможете ответить на простые вопросы:

• что именно агент сделал?
• какой файл был изменён, какой удалён, какой добавлен?
• что было раньше? как было до его правок?
• как откатиться к тому, что работало вчера?
• если работает второй агент — что ему сейчас брать как точку отсчёта?

Без общей памяти вайбкодер быстро превращается в человека, который сидит перед чёрным ящиком и нажимает «дальше», уже не понимая, что внутри происходит. Когда что-то ломается — а оно обязательно сломается, потому что агент не идеален — откатываться приходится в режиме «верни как было руками». Это то, что случилось у меня 9 мая.

Репозиторий нужен ровно для одного:

Чтобы каждое движение агента было видно, названо и могло быть отменено.

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

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

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

Что значат слова агента, когда он отчитывается о работе

AI-агенты — Claude Code, Codex, Cursor и другие — постоянно отчитываются вам короткими сообщениями вроде:

«Создал ветку. Сделал три коммита. Запушил. Открыл pull request.»

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

Коммит — это шаг работы, который агент назвал и сохранил в историю.

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

Когда агент говорит «сделал три коммита» — у него внутри его рабочей черновой папки появились три названных точки сохранения. У вас на сайте ещё ничего не изменилось.

Ветка — это отдельная черновая копия проекта, в которой агент работает.

Представьте, что у вас есть чистовая версия документа, и вы создаёте для эксперимента отдельный черновик. Меняете в черновике что хотите — на чистовик это никак не влияет. Если эксперимент удался, можно перенести изменения в чистовик. Если нет — выбросить черновик, и чистовик останется чистым.

Когда агент говорит «создал ветку и работаю в ней» — он защищает основную версию проекта от своих экспериментов. Это хорошо. Когда агент работает «прямо в основной ветке» — он экспериментирует на живом сайте. Это плохо.

Основная ветка обычно называется main. Считается, что то, что в main — рабочее и не сломанное. Поэтому правильный путь такой: main не трогаем, новые задачи делаем в отдельных ветках.

Пуш (от английского push — «толкнуть») — это когда агент отправляет свою работу из рабочей черновой папки на своём компьютере в общее хранилище проекта в интернете.

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

В моём случае 9 мая первый агент именно этого не сделал. Закончил работу — не запушил. Поэтому второй агент работал так, будто этой работы вообще не было.

Pull request (часто сокращают до PR, читается «пул-реквест») — это просьба «возьмите мою черновую ветку и добавьте её содержимое в основную версию проекта».

То есть: «я закончил, посмотрите, что я сделал. Если всё ок — присоединяйте к main». Это пауза перед тем, как изменения попадут в основную версию. На этой паузе вы или другой агент успеваете глазами проверить, что именно меняется, не сломалось ли что-то очевидное, не забыл ли агент важное.

Открытый PR — это работа агента, готовая, но ещё не добавленная в основную версию. Принятый и слитый (по-английски merged) PR — это работа, которая уже стала частью основной версии проекта.

Четыре слова, четыре места жизни:

Коммит       → шаг агента в его черновой папке
Пуш          → шаг отправлен в общее хранилище в интернете
Pull request → шаг ждёт проверки перед добавлением в main
Merge        → шаг добавлен в основную версию

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

Где у вайбкодеров репозиторий ломается

За последний год я наблюдал четыре типичных сценария поломки. Все четыре — не про код. Все четыре — про правила работы.

Поломка 1. Агент работает напрямую в main.

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

Откатываться приходится в режиме «верни как было». А «как было» уже размылось — агент успел сделать ещё пять правок поверх.

Правильно: любая новая задача — в отдельной ветке. Основная ветка остаётся рабочей всегда.

Поломка 2. Агент сделал работу, но не запушил.

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

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

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

Поломка 3. Несколько агентов работают параллельно без письменных правил.

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

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

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

Поломка 4. Обновление сайта мимо общей памяти.

Это самый болезненный случай — мой случай 9 мая. Агент закончил работу, не положил её в общее хранилище, но при этом сам обновил живой сайт. На сайте теперь — новая версия. В общем хранилище — старая. Дальше любая попытка обновить сайт из общего хранилища (а это нормальный путь) затрёт новую версию на сайте старой. И никто не поймёт, почему.

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

Как ставить задачи агенту, чтобы он не сломал продукт

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

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

Перед началом задачи:

Сначала забери свежую версию проекта из общего хранилища. Потом создай отдельную ветку под эту задачу — с понятным именем, по смыслу. В основной ветке main ничего не трогай. Если ветка уже создана — убедись, что её также видно в общем хранилище, не только у меня локально.

Во время работы:

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

После работы:

Отправь ветку в общее хранилище. Открой pull request и в его описании напиши: что сделано, зачем, что изменилось, как проверить. Сам в основную ветку ничего не вливай — я проверю и приму решение. Если вижу проблему, скажу — поправишь в той же ветке.

Отдельным правилом — никогда:

Не обновляй боевой сайт сам. Не заливай ничего на сервер из своей локальной папки. Не делай force push. Если кажется, что нужно что-то удалить из истории — сначала спроси у меня.

Эти четыре блока можно записать один раз и потом просто прикладывать к любой задаче. Через пару задач агент привыкнет и начнёт делать это сам — но привычка появится только если вы первое время повторяете.

Ещё проще — положить эти правила в файл прямо в проект, чтобы агент читал их в начале каждой сессии. Дальше — про этот файл.

Файл AGENTS.md: письменный договор с агентами

AGENTS.md — это обычный текстовый файл, который вы кладёте в общую папку проекта. Имя файла важно: современные AI-агенты (Claude Code, Codex, Cursor и другие) при начале работы с проектом смотрят, нет ли в нём такого файла. Если есть — читают и принимают как обязательную инструкцию.

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

Минимальный AGENTS.md для вайбкодера — это семь пунктов:

# AGENTS.md

## 1. Что считать правдой
Единственная правда о проекте — это ветка main в общем
хранилище на GitHub: ССЫЛКА. Не локальная папка, не боевой
сервер, не личная ветка.

## 2. Как создавать ветки
Любая ветка сразу должна быть выложена в общее хранилище.
Если ветка живёт только локально — её не существует.

Имена веток: feature/имя-задачи, fix/имя-задачи,
content/имя-материала.

## 3. Работа с основной веткой
В main напрямую ничего не делаем. Любая задача — в
отдельной ветке, потом pull request.

## 4. Коммиты
Один коммит = один осмысленный шаг. Названия по-человечески.
Никаких «fix», «update», «final».

## 5. Завершение работы
После задачи: пуш в общее хранилище → pull request с
описанием → ждать проверки. Самостоятельно вливать в main
нельзя.

## 6. Обновление боевого сайта
Боевой сайт обновляется только из общего хранилища
автоматическим путём. Никаких ручных загрузок с локальной
машины.

## 7. Секреты
В проект нельзя класть пароли, ключи доступа, токены, личные
данные клиентов. Если нужно — спроси, куда положить.

Этот файл — стартовый. Со временем туда добавляются правила вашего проекта: какие папки трогать можно, какие нельзя, как называются ваши вещи, где живёт боевой сайт. У VAAI этот файл сейчас на 240 строк — там вся история граблей, на которые мы наступили. Каждые новые грабли = новый пункт. Живой пример — AGENTS.md vaai-site на GitHub.

Где это всё-таки опасно

Даже с правильно настроенным репозиторием и хорошим AGENTS.md есть несколько действий, которые агенту лучше не отдавать никогда — или отдавать только с подтверждением вживую.

• Принудительная перезапись истории (по-английски force push) в основную ветку. Это операция, после которой история проекта переписывается, и часть прошлой работы может исчезнуть без следа. Откатиться обратно — почти невозможно.
• Удаление веток. Иногда там лежит чужая незаконченная работа, и вы об этом не знаете.
• Загрузка секретов — паролей, ключей доступа к платёжным системам, банкам, базам данных. Если попало в общее хранилище — считайте, утекло. Особенно если хранилище публичное.
• Прямой доступ агента к боевой базе данных. Запросы вроде «удали всех неактивных клиентов» агент исполнит буквально. Без подтверждения, без бэкапа.
• Автоматическое обновление боевого сайта без проверки человеком. Контур, в котором ни одна пара глаз не успевает посмотреть, что сейчас выкатится, рано или поздно выкатит что-то плохое.

Этим вещам в AGENTS.md место в разделе «никогда без меня». Подробнее про разграничение полномочий между владельцем и агентом я разбираю в статье «ИИ-агент для бизнеса: где он помогает, а где опасен».

Что сделать на этой неделе

Если вы уже вайбкодите и читаете это, узнавая себя в одной из поломок:

1. Зайдите на GitHub своего проекта. Откройте список последних коммитов и посмотрите глазами — понимаете ли вы, что в них сделано. Если в названиях коммитов «fix», «update», «final» — это первый сигнал, что агент работает без правил.
2. Положите в корень проекта файл AGENTS.md. Можно начать с семи пунктов из шаблона выше. Сохраните, запушьте, дайте агенту в следующей задаче прочитать.
3. Проверьте, что у вас одно общее хранилище. Если на разных машинах живут разные «правды» — выберите одну (обычно это GitHub), и пусть все агенты ходят туда.
4. Договоритесь о правиле: одна задача = одна ветка + один pull request. Не позволяйте агенту работать в main напрямую, даже «по-быстрому».
5. Закройте прямой путь к боевому сайту. Если у агента есть возможность одной командой выкатить что-то на сервер мимо общего хранилища — уберите её. У меня после 9 мая на этой команде стоит проверка: если локальная версия не совпадает с GitHub — команда отказывается работать.

Главное

Репозиторий — это не инструмент для программистов. Это инструмент для того, у кого работает кто-то быстрее его самого. В первую очередь — для вайбкодера, у которого работает AI-агент.

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

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

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