Сегодня из каждого утюга звучит термин vibe coding — расслабленная, итеративная разработка в диалоге с ИИ, когда ты просто описываешь хотелки, а агент сам пишет, правит и деплоит. Звучит как магия, но на практике все знаем чем это почти всегда заканчивается: результатом категории «ну, вроде работает».
Одинокий разработчик (или одинокий ИИ-агент), который катит код без второго мнения — это проблема. Одна точка зрения неизбежно порождает слепые зоны. Код может проходить тесты (на бумаге), но то ли мы вообще тестируем? План выглядит отлично, но соблюдены ли KISS/DRY, или мы снова плодим спагетти?
Чтобы превратить vibe coding в прогнозируемый процесс доставки [более] качественного ПО, я адаптировал фреймворк GSD (get-shit-done). Сразу оговорюсь: GSD придумал не я, я лишь адаптировал. В качестве основного агента-исполнителя (рабочей лошадки) я использую Claude Code, но сама архитектура универсальна и легко адаптируется под любую комбинацию.
Главная фишка моего подхода против обычного GSD — автоматизированное, двухконтурное код-ревью с принципиально разными подходами.
Одна пара глаз — это ноль пар глаз
Базовый цикл GSD прекрасен: он планирует проект целиком, разбивает его на независимые задачи и гонит их автономно по циклу: research → plan → execute → verify. Субагенты делают тяжелую работу, единственный жесткий гейт — механическая проверка тестами (verify).
Но этого мало. На практике GSD (а я с ним экспериментировал еще почти год назад) оказывался тем же вайб кодингом но with extra steps, с результатами переменного качества. Я же добавил в контур двух независимых экспертов с полярными темпераментами.
Знакомьтесь:
-
Grok — живой веб-поиск, либерально-демократический Жириновский от мира ИИ. Громкий, размашистый, фонтанирующий идеями.
-
Codex — холодный экзаменатор для трезвого разбора.
Шов плана: сначала расширяй, потом сужай
Главная хореография разворачивается еще до написания первой строчки кода. Мы не натравливаем обоих ревьюеров на план одновременно — это потеря времени. Мы разделяем их по ролям.
Шаг 1: Grok идет первым (режим expand) Его задача — не оценивать, а расширять горизонты. Он приходит с доступом к живому вебу и накидывает предложения:
-
[missing-scope]— «Вы забыли про rate limiting!» -
[alt-approach]— «А давайте вообще вынесем это в очередь!» -
[external-risk]— «Я только что проверил, у этой зависимости свежая CVE!» Вердикты он не ставит. Валидные предложения мы вплетаем в ROADMAP, а настоящие развилки оформляем через FORKS и задаем вопрос пользователю.
Шаг 2: Выходит Codex (режим plan) После того как Grok раздул план, за дело берется Codex. Он судит уже усиленный, обогащенный черновик. Его вердикт безжалостен и короток: SOLID или WEAKNESSES(n) с нумерованным списком. Он ищет циклические зависимости, нарушение KISS и DRY, размытые критерии приемки и дыры в параллелизме.
Жириновский сначала наораторствовал, затем экзаменатор поставил оценки.
Шов кода: две линзы на каждый слайс задач
Когда субагент (Claude) завершает работу над очередным слайсом задач (небольшой логической порцией, на которые GSD нарезает проект), и механический verify (зеленый свет от тестов и линтеров) для этого куска пройден, мы снова зовем нашу парочку.
Важно: этот процесс происходит не один раз в самом конце огромного релиза, а итеративно, закрывая каждый конкретный слайс. На этапе ревью оба агента запускаются параллельно по диффу только что выполненной порции работы, но бьют по нему разными прожекторами:
-
Codex смотрит на корректность, возможные регрессии, архитектурную чистоту и общее качество написанного.
-
Grok свежим взглядом пробивает по вебу актуальность версий добавленных библиотек, проверяет безопасность и ищет неочевидные краевые баги.
Находки обоих ревьюеров сливаются, дедуплицируются, и Claude отправляется чинить этот слайс за один проход. Итог: либо APPROVE, либо COMMENTS(n) от каждого. Никаких отписок в стиле «пара мелких замечаний» — каждый пункт выводится в консоль с индексом важности (✗ блокер / ⚠ минор / ℹ нит) и привязкой к конкретной строке или файлу. Как только слайс полностью “зеленый”, GSD переходит к следующему.
Как это работает под капотом
Технически ревьюеры интегрированы максимально просто и прозрачно. GSD выступает оркестратором и работает с ними через CLI-интерфейс.
В системе лежат два исполняемых скрипта: grok.sh и codex.sh. Когда GSD доходит до этапа планирования или код-ревью, он проверяет наличие этих бинарников/скриптов в $PATH. Если они есть, GSD вызывает их как дочерние процессы, передавая контекст (Markdown-документ плана или git diff текущего слайса) через stdin.
Скрипты забирают контекст, формируют промпт и стучатся в свои модели. Главное требование к скриптам — возвращать строго структурированный stdout.
Например, для плана Codex должен выплюнуть в консоль либо SOLID, либо WEAKNESSES(3) и дальше три строки с описанием. GSD парсит этот вывод и автоматически заводит TODO-задачи для Claude Code на исправление. Такая архитектура CLI-плагинов позволяет легко тюнить промпты внутри .sh скриптов, подменять модели в JSON-конфигах или заворачивать их трафик через нужные прокси без вмешательства в ядро самого GSD.
Ложка дегтя: минусы подхода
Было бы нечестно сказать, что этот флоу идеален. У него есть ощутимые минусы, к которым нужно быть готовым:
-
Это долго. Прогон по полному циклу с двумя ревьюерами, параллельными проверками и доработками на каждый слайс занимает кратно больше времени, чем классический ванильный GSD, и уж тем более дольше, чем один “толстый” запрос к агенту.
-
Это дорого. Каждый чих — это отдельный вызов мощных LLM. Отдельная задача в TODO заводится до ревью и закрывается после. Токены расходуются весьма активно.
-
Это хоть и усиленный, но всё равно вайб кодинг. Не надо слепо доверять его результатам для критических задач.
Практический опыт и итог
Стоит ли оно того? Да. На личном практическом опыте могу сказать: результат реально становится лучше на порядки.
При таком подходе вы перестаете бороться с “контекстным гниением” и архитектурной лапшой, характерной для долгих сессий vibe coding. Два разных темперамента закрывают слепые зоны друг друга: смелый расширитель страхует от внешних рисков, а холодный критик отсекает нежизнеспособное. На выходе получается предсказуемый, безопасный и действительно готовый к продакшену код. Благодаря тому что всё расписывается на независимые этапы плана, выполняемые агентами с чистым контекстом — нет типичной проблемы, когда агент пытается сделать всё за один заход и срезает углы.
Посмотреть исходники, изучить механику и забрать готовые скрипты-скиллы (те самые плагины-ревьюеры) можно на GitHub: mwgg/skills.
ссылка на оригинал статьи https://habr.com/ru/articles/1060604/