Что не так с обычным vibe-coding
Про vibe-coding сейчас не пишет только ленивый, и в массовом восприятии это выглядит так: накидал промпт в чат, получил стену кода, скопировал в редактор, не компилируется, попросил пофиксить, получил новую стену — и так по кругу, пока не кончатся токены или терпение.
Для разовых скриптов такая схема работает. Для продукта с живыми пользователями — нет. Главная проблема не в качестве кода, а в архитектуре процесса: каждый новый промпт начинается почти с нуля, контекст теряется, изменения не проверяются системно, а накопленный технический долг растёт быстрее, чем успевает формироваться сама фича.
AI как команда, а не чат
Последние месяцы я гонял другой подход: не «чат, который пишет код», а AI-команда, которая закрывает полный цикл разработки — от формулировки задачи до выката на прод. Планирование, постановка тикетов, написание кода, код-ревью, тесты на dev-окружении и автоматический деплой — всё это делают разные саб-агенты, каждый со своей зоной ответственности.
Между этапами ничего не разваливается, потому что система устроена примерно как нормальная команда людей, только роли играют программные агенты. Передача контекста между ними формализована: каждый следующий агент получает артефакты предыдущего в структурированном виде, а не пересказ из чата.
Ключевая идея — предсказуемость. Не «модель напишет что-нибудь умное», а воспроизводимый pipeline с явными состояниями, чекпойнтами и точками, где система останавливается и ждёт подтверждения перед тем, как двигаться дальше.
Что разбирается в статье
В статье я разберу архитектуру целиком: из чего она собрана, почему именно так, и где проходят границы, за которые я агентам выходить не даю. Последнее — отдельная тема: автономность агентов удобна ровно до тех пор, пока чётко определено, что они могут делать без спроса, а что требует явного подтверждения.
Это не теоретическая схема — всё это работает на реальном проекте уже несколько месяцев. Статья описывает именно то, что сложилось на практике, включая решения, которые я пересматривал по ходу.
Тестовый полигон
В качестве подопытного — мой pet-проект: обычный Telegram-бот на Go с MongoDB в качестве хранилища и Kubernetes для оркестрации. Что именно он делает — выходит за рамки статьи; важно, что это работающий продакшен с реальными пользователями, а не изолированная песочница.
Именно наличие живых пользователей делало задачу осмысленной: ошибки деплоя и регрессии стоили дорого, поэтому предсказуемость пайплайна была не Nice-to-have, а требованием.
