Год назад я проникся идеей вайбкодинга и начал разбираться, как бы организовать процесс так, чтобы на выходе получалось что-то полезное.
Сначала работал в Cursor и пытался ваншотом сделать какие-то сервисы для своих нужд. Получалось ужасно, не работало ровным счетом ничего.
Тогда я решил, что надо максимально подробно описать, как должен работать сервис, как он должен выглядеть, что должно происходить на нажатии на каждую кнопку. Написал док на 3 страницы, нарисовал простенький интерфейс в Фигме, отдал агенту — вроде что-то сделал, но с невероятным количеством багов.
Почитал, как вайбкодят более умные люди, и понял, что ваншотом никто ничего не делает. У агента не хватает ни контекстного окна, ни мозгов, чтобы с нуля написать даже маленькое рабочее расширение для Хрома. Поэтому задачи надо декомпозировать и делать по одной.
Открыл чат, объяснил что мы делаем, дал маленькую задачку. Агент сделал, я проверил, что все работает, закрыл чат. Открыл новый чат — и так далее.
Так я сделал свой первый проект — расширение для браузера, которое ищет битые ссылки на сайтах. Спустя 9 месяцев у него уже 2500 пользователей (половина из Индии), 16 хороших отзывов. Прикольно, но мало, надо что-то еще.
За последние полгода я сделал десяток небольших проектов. Некоторые для себя (например, автоматический репост из Телеграма в блог на сайте и агент-ассистент, который управляет моим календарем), некоторые для команды (агент с RAG, который отвечает на вопросы по базе знаний), парочку даже смог монетизировать (у одного бота сейчас 33к пользователей и около $1000 ежемесячной выручки).
Все это делал в Claude Code. C каждым следующим проектом я чуть лучше понимал, как вообще устроена агентная разработка, как надо общаться с агентом, чтобы он поменьше тупил и галлюцинировал. Делал новые скиллы, докручивал старые, добавлял агентов-ревьюверов, которые ищут баги и уязвимости.
В итоге собрал свой фреймворк агентной разработки и выложил его на Гитхаб. Это набор скиллов и команд для Claude Code, которые учат его уму-разуму.
За 2 месяца у него набралось 100 звезд, я получил в личку несколько хороших отзывов, что с ним действительно проще и быстрее создавать небольшие продукты. Хочу поделиться фреймворком и с вами тоже.
В чем суть фреймворка
Я не разработчик. Я учился кодить в школе и универе, но ни разу не писал код в настоящих проектах. Жизнь завела меня сначала в маркетинг, а потом в менеджмент.
Фреймворк заточен под таких же людей, как я. С техническим складом ума, но без реального опыта в настоящем программировании. Наш разработчик — это Claude Code. Он же devops, он же специалист по безопасности, он же технический писатель.
Человеку отводится роль продакта — придумывать, что делать, говорить, как оно должно себя вести в разных сценариях и edge cases, ставить задачи, понимать потребности пользователей. Ну и тестировать все это в конце, чтобы убедиться, что все работает так, как задумано.
Я подробно расписал схему работы на Гитхабе, но продублирую и здесь.
Разработка идет в несколько этапов: сначала планируем, что делать, потом формулируем задачи, потом делаем. На каждый этап у агента есть скилл с инструкций, как именно надо себя вести, и несколько субагентов-ревьюверов, которые проверяют, что работа сделана хорошо, можно переходить к следующему этапу.
User spec
Работа начинается с user-spec — это документ, где понятным человеческим языком расписано, что мы делаем, зачем, как оно должно работать. Таким языком, который могу понять я, со своим очень поверхностным знанием о разработке.

Я описываю агенту, что хочу сделать, он запускает режим интервью и задает мне несколько десятков вопросов:
— А если юзер сделает это, что должно произойти?
— А если API не будет отвечать, что тогда?
— Вот есть 2 варианта это сделать, этот проще, этот надежнее, какой хочешь?
Кроме интервью агент исследует кодовую базу, гуглит, смотрит документацию и так далее. На выходе получается подробный документ, который я могу прочитать, понять и исправить.
Tech spec
Когда user-spec готов, я прошу агента написать на его основе tech-spec — в нем мы пишем, что конкретно будем делать, какие функции писать, какие файлы менять, как все это тестировать.
Агент читает user-spec, изучает документацию проекта и код, все это расписывает, проходит несколько этапов ревью и правок. Чем больше фича, тем больше получается документ. Но в среднем это 300-400 строк.

Затем второй агент декомпозирует tech-spec на отдельные атомарные задачи. В каждой пишет, что надо сделать, что и в каких файлах поменять, какую документацию изучить перед работой, какие тесты написать, какие скиллы использовать, какие критерии приемки задачи.
Например, если в задаче надо написать промт для LLM, вызываемой по API, то задачу будет делать агент со скиллом prompt-master. Если надо кодить — будет делать code-writer и так далее.

Сами задачи тоже проверяются ревьюверами — на адекватность решения, уязвимости, соответствие user-spec и tech-spec.
На этом этапе я уже ничего не проверяю сам. Я согласовал user-spec, дальше вся ответственность ложится на плечи агентов.
Сама разработка
Когда задачи готовы, можно запускать агента кодить.
Вся работа идет по TDD — сначала пишем тесты, только потом код. Если делать наоборот, агент начинает подгонять тесты под уже сделанную работу, в том числе под ошибки.
Есть два режима — do-task и do-feature.
В do-task агент берет одну задачу, загружает указанные в ней скиллы, делает, проверяет сам себя по критериям приемки, прогоняет тесты, потом вызывает проверяльщиков. Обычно это ревьювер кода и секьюрити аудит. Когда все готово, я закрываю чат, открываю новый и пускаю нового агента делать следующую задачу.
do-feature — это ваншот режим. В феврале в Claude Code появились Agent Team — агент-тимлид создает кучу агентов-тиммейтов и координирует их работу. Вот это оно.
Тимлид смотрит, какие задачи из спека еще не выполнены, запускает на каждую отдельного агента-разработчика. Когда они отчитались, что все сделали, запускает агентов-ревьюверов. В конце запускает QA всей фичи.
Для простых задач работает нормально, можно действительно запустить банду агентов и уйти по своим делам. Один раз они у меня 8 часов самостоятельно кодили — и на выходе все даже заработало. Но когда задачи сложные, особенно на проектах с живыми пользователями и монетизацией, я предпочитаю делать задачки по одной и сам вручную проверять, что ничего не сломалось.
Документация проекта
Чтобы агенты не тупили после создания нового чата, я веду (ну вернее они ведут) project knowledge по каждому проекту. Там написано, что мы делаем, зачем, какой у нас техстек, какая архитектура проекта, как его деплоить и так далее.
В новом проекте мы собираем первую версию документации на основе интервью. А дальше после каждой сделанной фичи я пишу команду /done — и агент проходится по всем коммитам и логам, которые пишут агенты-разработчики по ходу работы и обновляет документацию.
Если надо сделать что-то быстрое, без спеков и интервью, я просто открываю новый чат, прошу агента изучить документацию — и после этого можно с ним нормально общаться.
Скиллы по созданию скиллов
Все эти скиллы и агентов я делаю с помощью двух скиллов — skill-master и skill-tester.
Первый — это инструкция, как писать нормальные рабочие скиллы и субагентов-ревьюверов к ним.
Второй берет готовый скилл, придумывает для него тестовые задачи, прогоняет по ним агента и фиксирует, как он справляется. Фидбек я отдаю skill-master — и он правит инструкции.
А потом уже и сам руками тестирую на настоящих задачах.
Как установить
Самый простой способ — дать ссылку на Гитхаб своему Claude Code и попросить установить. Обычно все так и делают.
Но если хотите руками — просто скопируйте все в папку ~.claude. Если у вас нет скиллов и субагентов с такими же названиями, как у меня, все нормально скопируется. Если есть, то придется что-то переименовать
Спасибо, что прочитали статью, надеюсь, мои наработки вам пригодятся. Мне будет приятно, если этими выстраданными за полгода скиллами будут пользоваться другие люди
У меня есть тележка, где я рассказываю про свой опыт в бизнесе и менеджменте, AI-assisted разработке, запуске и продвижении мини-проектов. Если вам такое интересно, заходите в гости.
Комментарии (21)

vvibov
10.04.2026 17:24Делаю примерно то же самое, только через CLAUDE.md и shared.md с инструкциями агенту — туда идут соглашения по коду, контекст проекта, правила приёмки задач. Это позволяет не объяснять одно и то же в каждом чате.

molyanov Автор
10.04.2026 17:24Я claude.md почти пустым держу, все инструкции в скиллах и project-knowledge. Так проще контекстное окно контролировать. Например, субагенту, который делает ревью секьюрити, не надо знать, как деплоить проект и как там тексты писать. Поэтому он получает только нужный ему файл из папки project-knowledge. Чем меньше у него лишней инфы в контексте, тем меньше он косячит

aborouhin
10.04.2026 17:24В чём различия с конкурирующими решениями и преимущества перед ними? GitHub Spec-Kit, BMAD Method, GSD, OpenSpec, Agent OS, superpowers?.. (на самом деле их столько и развиваются так быстро, что актуальный неделю назад список уже может устареть :)

molyanov Автор
10.04.2026 17:24Если честно, то хз
Мне как-то проще и интереснее самому процесс продумывать, чем в чужих разбираться
Я иногда смотрю на чужие системы и какие-то идеи у них подворовываю, но на живых проектах ни разу чужое не тестил. Только свое, только хардкор

Triton5
10.04.2026 17:24Хочу высказаться, не в упрёк автору, он молодец, а про ситуацию в целом.
В целом это балаган. Корпорации, пылесосящие в себя не только миллиарды, а уже триллионы долларов, не то, что делают работающие и логичные решения ожидаемого энтерпрайз уровня, а выпускают продукцию с какими-то ограничениями, делают задержки в генерации, запрещают использование в других оболочках, в общем, полный набор абсолютно токсичного поведения. Продуманной системы работы - нет! Просто нет, трахайтесь как хотите, господа юзеры, пилите свои велосипеды. И бабло в эти корпорации другими корпорациями заливается бесконечно, несмотря ни на что.
Надеюсь, их всё-таки обгонят китайцы или кто там ещё, потому что эта ситуация крайне нездоровая.
Всё, слез с табуретки:)
molyanov Автор
10.04.2026 17:24Я здесь с обратной стороны
баррикадтабуретки. Возможность во время поездки в такси наговорить несколько голосовых сообщений в телеграм и получить на выходе работающее приложение — вызывает у меня лютый восторг. А то, что надо немного подумать, как все организовать, чтобы это получалось — это мелочи уже
Tzimie
10.04.2026 17:24А какого типа приложение получается? Просто интересно. Если каждый может создать приложение, то будет как с литературой. Пиши не хочу, читать никто не будет кроме автора

Triton5
10.04.2026 17:24Так ведь приложение не нужно читать. Его надо использовать:) Если автор будет его использовать, то и хорошо:)

molyanov Автор
10.04.2026 17:24Ну из того, что сделал я:
Два сайта с блогами, один свой личный, один для проекта
Бот, который берет посты из тг-канала, чуть сеошит и публикует в блог на сайте
Свой аналог openlaw: агент на базе claude code, с которым общаюсь через телеграм. Выполняет всякие ассистентские задачи: ведет мой календарь, базу знаний в обсидиане, crm, ищет инфу, каждую ночь разгребает инбокс
Бот, через который можно общаться с Claude Code из телеграма. Можно с телефона голосовыми по этому сасому фреймворку и работать
Бот, который делает эмодзики в телеге — вот у него 33к юзеров и 1000$ выручки в месяц
Расширение для Хрома которое ищет битые ссылки на сайтах
Бот, который строит RAG по базе знаний и отвечает на вопросы в чате
Небольшое автоматизированное медиа, типа «дневника трат» в ТЖ. Люди заполняют анкеты, рассказывают о своей работе — бот проверяет, что это не спам, оформляет пост, публикует в канале
Сервис, который мне из сырых данных строит дашборд по бизнеса, считает все, что мне надо
Сервис, который делает около 500 запросов по API в разные LLM в духе «посоветуй кафе в Москве» и составляет отчет по видимости компании в выдаче нейронок. Такая, примитивная geo-аналитика
Ну что-то такое, в общем

exsoko
10.04.2026 17:24Вот здесь https://habr.com/ru/articles/1021474/ предложена методология разработки в виде стандарта SENAR. Там же фреймворк построенный на этой методологии.
Gafar87
Привет. А как решаешь конфликты, когда два агента параллельно правят один и тот же файл?
molyanov Автор
Привет! А они не правят один и тот же файл никогда
Ревьюверы пишут фидбек и отдают основному агенту, дальше он все сам исправляет
А в do-feature на этапе планирования задач они разбиваются на волны, исходя из зависимостей. В одну волну попадают задачи, в которых надо править разные файлы, чтобы не было конфликтов. В следующую — такие же задачи, но для которых надо, чтобы было сделано что-то из первой волны. И так далее
FRAGnat
Есть два способа решить эту проблему:
1) Научить агентов при работе с любым файлом создавать мьютекс, если по простому, то он создает .lock файл в котором пишет, этот файл заблокирован мной, когда я закончу можете редактировать
2) Каждую сессию агентов заставлять работать в изолированном worktree(я именно так и работаю), сабагенты в рамках одной сессии друг-друга не перезатирают, а вот агенты из разных могут, поэтому если меняет код проекта, то, каждый работает в своей изолированной среде, а конфликты решаются уже через pull request веток.
Для любого из этих способов помимо промптов и правил, стоит также реализовать это на уровне хуков. Тогда агент не может игнорировать эти правила