Вайбкод командой не так страшен, як его малюют
Вайбкодить долгосрочные проекты командой из нескольких человек не так сложно, как может показаться на первый взгляд. Из того что я вижу на соседних каналах и в обсуждениях складывается впечатление, будто кодовый агент это история для одиночки, однако, стоит посадить рядом ещё двух инженеров с агентами, как проект превратится в кашу и самоповторы.
Каша и правда заводится легко, вот только не от самого факта, что у каждого в команде свой агент, я прекрасно помню дореИИволюционные времена, когда команда из нескольких человек, без всяких агентов, превращали в этосамое красивый и архитектурно стройный проект.
И по моему скромному опыту проблемы возникают там, где команда не договорилась о правилах игры. У меня на длинных проектах командный вайбкод живёт нормально, и рецепт просто до безобразия.
Начинается всё с рулесов (правил) проекта, у Cursor это .cursor/rules/*.mdc, у Claude Code .claude/rules/*.md, у Codex через хуки читаются правила Cursor и так далее. Рулесы живут в git рядом с кодом.
Общее уходит в корневой AGENTS.md, для клода делаем линк с CLAUDE.md на него или внутри пишем @import AGENTS.md, специфика в папки конкретных агентов, а синхронизацию форматов выполняет сам агент отдельным шагом в конце задачи, все наборы уезжают одним коммитом. Если договорённость не записана в репозиторий, для агента её не существует, сказанное на созвоне не считается. И да, правки правил проходят ровно то же ревью, что и код, вредная инструкция в рулесах ломает работу всей команды разом.
Приёмка описывается тестами, а не на словах. Запрос от бизнеса или тестировщиков превращается в feature-тест в огуречном формате, edge-кейсы добираются юнитами, реализация идёт по агентному TDD (чуть отличается от классического).
Если гоняете двух-трёх агентов на одной машине, разведите их по разным рабочим деревьям через git worktree.
Ну и самое важное. Рутину автоматика сняла, финальное слово всё равно осталось за человеком. И человек в конце цепочки находится не просто так, SlopCodeBench намерил, что ни одна SotA модель не довела до конца ни одной задачи из двадцати, а код при этом пухнет и усложняется с каждой итерацией.
Это я к тому, что запустить пять агентов и уйти на обед в расчёте вернуться к готовому SaaS не выйдет, вернётесь к разбитому корыту.
Так что командный вайбкод упирается не в агентов, а в ту же инженерную дисциплину, которая и раньше отличала хороший проект, от ну такого. Правила в репозитории, тесты как граница приёмки, ревью человеком. Скучно, не хайпово, но это работает.
Вайбкодить долгосрочные проекты командой из нескольких человек не так сложно, как может показаться на первый взгляд. Из того что я вижу на соседних каналах и в обсуждениях складывается впечатление, будто кодовый агент это история для одиночки, однако, стоит посадить рядом ещё двух инженеров с агентами, как проект превратится в кашу и самоповторы.
Каша и правда заводится легко, вот только не от самого факта, что у каждого в команде свой агент, я прекрасно помню дореИИволюционные времена, когда команда из нескольких человек, без всяких агентов, превращали в этосамое красивый и архитектурно стройный проект.
И по моему скромному опыту проблемы возникают там, где команда не договорилась о правилах игры. У меня на длинных проектах командный вайбкод живёт нормально, и рецепт просто до безобразия.
Начинается всё с рулесов (правил) проекта, у Cursor это .cursor/rules/*.mdc, у Claude Code .claude/rules/*.md, у Codex через хуки читаются правила Cursor и так далее. Рулесы живут в git рядом с кодом.
Общее уходит в корневой AGENTS.md, для клода делаем линк с CLAUDE.md на него или внутри пишем @import AGENTS.md, специфика в папки конкретных агентов, а синхронизацию форматов выполняет сам агент отдельным шагом в конце задачи, все наборы уезжают одним коммитом. Если договорённость не записана в репозиторий, для агента её не существует, сказанное на созвоне не считается. И да, правки правил проходят ровно то же ревью, что и код, вредная инструкция в рулесах ломает работу всей команды разом.
Приёмка описывается тестами, а не на словах. Запрос от бизнеса или тестировщиков превращается в feature-тест в огуречном формате, edge-кейсы добираются юнитами, реализация идёт по агентному TDD (чуть отличается от классического).
Если гоняете двух-трёх агентов на одной машине, разведите их по разным рабочим деревьям через git worktree.
Ну и самое важное. Рутину автоматика сняла, финальное слово всё равно осталось за человеком. И человек в конце цепочки находится не просто так, SlopCodeBench намерил, что ни одна SotA модель не довела до конца ни одной задачи из двадцати, а код при этом пухнет и усложняется с каждой итерацией.
Это я к тому, что запустить пять агентов и уйти на обед в расчёте вернуться к готовому SaaS не выйдет, вернётесь к разбитому корыту.
Так что командный вайбкод упирается не в агентов, а в ту же инженерную дисциплину, которая и раньше отличала хороший проект, от ну такого. Правила в репозитории, тесты как граница приёмки, ревью человеком. Скучно, не хайпово, но это работает.