Инди-Хакинг Вайб-Кодинг сетап, что изменилось за полгода

В прошлой статье я рассказывал о своем воркфлоу при работе с вайб-кодингом. Много воды утекло с тех пор, и пришло время закрепить свой опыт и обновить информацию.

Я вспоминаю собственную наивность, когда говорил о Claude Code тогда:

Теперь Claude Code — мой основной инструмент. Я использую его для большинства задач, даже не связанных с программированием, например для анализа данных в разных табличных форматах или для рисования логотипов через API к Nano Banana 3.

Естественно, больше всего на этот переход повлияло появление Opus 4.5. Будучи активным пользователем Sonnet 4, часть моих задач я отдавал в Cursor и разные версии GPT 5, и тем не менее у меня постоянно оставалось ощущение незавершенности результата. Появление Sonnet 4.5 уже сместило 95% моей работы в Claude, но было недостаточно убедительным, в первую очередь из-за длительного ожидания результата, поскольку цепочки размышлений Соннета были слишком длинными. Я экспериментировал и с Кодексом, и с Композером, оставляя Соннету в первую очередь планирование и код-ревью. Опус 4.5 поставил ту самую точку в этих метаниях — он генерирует хороший код достаточно быстро и тратит по итогам меньше токенов, чем Соннет. Даже с 4 агентами, запущенными одновременно, я не выходил за недельные лимиты на максимальном тарифе.

Еще три вещи, повлиявшие на мою работу больше всего, помимо нового Опуса, были: появление playwright skill для Claude, отказ от ограничений безопасности и плагины от Compound Engineering для Claude Code.

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

Долгое время написание e2e-тестов с ИИ было болью. Я вообще небольшой фанат e2e-тестов изначально из-за постоянно квадратично растущей стоимости их поддержки с ростом кодовой базы. Все поменялось, когда я обнаружил, что вместе с правильным плагином и новыми моделями тестирование стало простым и доступным. Теперь классическое менеджерское «проверь перед передачей в тестирование», которое обычно напрочь игнорируется, превратилось в часть моего Claude.md, где я прошу написать e2e-тесты с Playwright для всей новой добавленной функциональности и проверять, что мы не сломали старую, запуская набор тестов после редактирования кода.

Если говорить об ограничениях безопасности, я долго считал враньем истории о том, как ИИ-агент решал какую-то задачу полчаса без участия человека, поскольку я постоянно сталкивался с запросом на разрешение от Claude, даже когда большая часть разрешений была прописана и я ставил режим автоматической работы. Все изменилось, когда я стал запускать Claude Code с флагом --dangerously-skip-permissions, именно после этого я получил полноценное ощущение AGI, когда агент работает над задачей без моего участия и показывает мне результат.

Но оба этих пункта по отдельности не приносят такого эффекта, как если их использовать вместе с концепцией Compound Engineering (сложно переводимой на русский язык, потому что когда речь идет об инвестициях, compound переводят как «сложный»).

В моем workflow, вдохновленном методологией компании Every, я создаю замкнутый цикл обучения: ИИ-агенты анализируют ошибки, тесты и готовые решения, фиксируя этот опыт в базе знаний в виде markdown файлов.

Такой подход позволяет мне выдавать результат, на который раньше уходила команда из пяти человек. Время распределяется так: около 80% усилий на планирование, ревью и тестирование, 20% — на написание кода. Основной упор на исследование — анализ кодовой базы, истории коммитов и поиск наилучшего подхода — чтобы превратить это в инструкции для агентов.

Технически всё, что мне требуется, реализовано в навыках Compound Engineering для Claude Code от компании Every. Набор навыков сейчас включает 24 специализированных агента, 13 слеш-команд и 11 навыков, усиленных MCP-серверами. Всё это работает по принципу «планируй — делегируй — оценивай — кодифицируй». У меня есть четкие чек-листы по тестированию и версионированию, которые агенты соблюдают.

Сначала я запускаю этап Plan (команда /workflows:plan). Здесь я превращаю общие идеи в детальные спецификации, которые служат инструкцией для агентов. Планы записываются в Markdown-файлы. Если вы хотите реализовать масштабные изменения, то план разбивается на части. Для плана также доступно review (команда /plan_review), которое обычно весьма полезно, так как при первичном планировании Клод склонен оверинженирить. И вы можете попросить углубить план (команда /deepen_plan), если хотите более детальной проработки. В случае, если ваш план состоит из нескольких фичей, вы можете запустить /triage для того, чтобы решить, что брать в работу, на что стоит забить, а какую часть плана требуется доработать. Фактически ваш процесс управления разработкой переходит в Markdown-файлы и управляется плагином для Клода, а агенты выступают в роли инженеров.

Затем наступает фаза Work (/workflows:work): система берет задачи в работу, при этом задачи могут выполняться параллельно с использованием изолированных рабочих деревьев (worktrees), что позволяет отслеживать прогресс, не засоряя основную ветку и не блокируя файлы, с которыми работает другой агент параллельно.

Когда код готов, я инициирую Review (/workflows:review). Это многоагентный аудит, где несколько специализированных алгоритмов ищут ошибки перед слиянием. Обычно результатом ревью становятся те же markdown-файлы, что и при планировании, которые ждут /triage от вас, и затем могут быть исправлены параллельно. Аналогично планам, специализированный агент строит дерево зависимостей для исправлений, если одно может аффектить другое.

Финальный этап — Compound (/workflows:compound). На этом шаге система фиксирует полученный опыт, будь то специфические исправления или новые паттерны, чтобы использовать их в будущем.

Внедрить это в свой Claude Code просто: сначала добавить маркетплейс командой /plugin marketplace add https://github.com/EveryInc/compound-engineering-plugin, а следом установить сам плагин через /plugin install compound-engineering.

Обычно моя работа над проектом выглядит так: я генерирую описание фичи, ориентируясь на пользовательский опыт, указываю критический технический контекст (если у меня есть понимание архитектуры), мой Claude.md содержит примеры, переходящие из проекта в проект, о том, что такое хорошо и что такое плохо, исходя из моего стека: no-build, BEM, vanilla Rails, self-hosting и так далее.

Отдельно замечу, что у меня для каждого проекта настроен локальный CI-скрипт, который прогоняет тесты и линтеры, и в Claude.md обозначено, что необходимо писать тесты, как писать тесты, что такое хорошие тесты, и что после изменений надо тестировать руками и запускать CI-скрипт перед коммитом и коммитить только если все хорошо, а если все плохо — нужно исправлять.

Тестировать руками здесь не ошибка — используя скиллы от compound engineering либо нативную интеграцию с браузером через плагин для Chrome, Claude вполне успешно может повторять флоу. Если у вас API-first приложение, то все проще — он может дергать curl и потом писать тесты. Ручная фаза помогает избежать ситуации оптимизации тестов на прохождение и галлюцинаций.

Затем я запускаю Claude в режиме --dangerously-skip-permissions и прошу создать ветку. Если я работаю над несколькими фичами одновременно, я прошу создать worktree, используя compound engineering tool (слэш-команды для него нет, но если попросить Клода сделать так, он запустит нужный воркфлоу). Worktrees позволяют мне работать удобно над несколькими задачами в одном проекте одновременно.

Ну и наконец я начинаю планирование: /plan и /plan_review, и, если требуется, то /triage. В целом большая часть результата определяется этапом планирования.

Как только план меня устраивает, я запускаю /workflows:work и переключаюсь на другие задачи. Клод работает самостоятельно в ветке и не отвлекает меня благодаря отсутствию ограничений безопасности.

Самый долгий и сложный процесс начинается по окончании работы — это ревью и тестирование. Перед код-ревью я прошу проверить наличие тестов (несмотря на инструкции в claude.md, этот пункт игнорируется, всё как у людей), запустить тесты (для этого у меня локальный CI-скрипт, который прогоняет линтеры и тесты) и проверить, что покрыта вся новая функциональность.

Затем начинается цикл review через /workflows:review и /triage для найденных проблем. Циклов ревью бывает несколько, часто после первичного ревью выясняется, что всё, что мы сделали, работает неправильно, и проходит несколько итераций до приемлемого результата. Естественно, всё, что найдено в ревью и отмечено годным к выполнению на этапе триажа, решается через /resolve_parallel.

Помимо локального ревью добиваться работающего кода помогают еще два трюка: ревью ботом Клода в Гитхабе и Cursor BugBot, за который я с удовольствием плачу, потому что работает он на удивление хорошо и находит баги, которые все ревью и тесты пропускают. Оба этих ревью запускаются автоматом на коммит в ветку, и я просто прошу Клода посмотреть комментарии к PR: если их много — составить план, если мало — просто решить, не заходя в Гитхаб. Да, иногда ревью ботом в Гитхабе находит что-то, что Клод локально не нашел.

После всех этих манипуляций я провожу ручное тестирование, и если все работает хорошо, то мне остается задеплоить. А если в процессе было что-то, что нужно запомнить на будущее, я запускаю /workflows:compound

Самый дорогой ресурс при использовании ИИ-агентов — это внимание человека. Идея, что человек должен внимательно следить за работой агентов, мертва. Ценность кода для большинства проектов снижается. Вы можете запустить четыре инстанса Клода и сделать, например, четыре разных подхода к одной задаче, а потом выбрать лучший. Вы можете исследовать вещи, которые никогда не увидят свет. Вы можете покрывать тестами то, чего бы в жизни не стали покрывать. Вы можете даже не читать весь сгенерированный код, если специфика вашего проекта это позволяет, если вы делаете очередной SaaS, а не ракету. Все, что стоит оптимизировать, — это использование вашего внимания.

Десять циклов код-ревью с агентами, чтобы получить приемлемый результат? Да нет проблем, это 10 раз нажать кнопку. Сотня тестов, которые надо ревьюить? Не переживай, никто никогда не будет оценивать качество этих тестов, потому что никто никогда их бы не написал и никто никогда не притронется к ним руками. Все что важно — они проверяют функциональность.

Когда агенты работают автономно, у вас появляется много небольших пауз в работе. Их можно заполнять просмотром Тиктоков, но гораздо эффективнее будет запускать несколько инстансов Клода одновременно, создавать ветки worktrees и работать над несколькими задачами одновременно.

Иван Кузнецов, ex-fullstack dev, ex-fintech-executive, теперь продуктовый менеджер, vibe-кодинг и RoR энтузиаст. Пишу в The Conclooder.