🔥 OpenSpec стал еще круче!

Готовлюсь сегодня к занятию по Spec-Driven Development подходу.

В декабре на первом потоке показывал как работать с OpenSpec, и тогда рабочий процесс вызова команд в Cursor был следующий:

• /openspec:proposal
• /openspec:apply
• /openspec:archive

И когда ты выполнял команду proposal, он сразу генерил тебе 3 документа - спека, дизайн, таски.

И вот ты сидишь с тучей текста, который надо валидировать.

Недавно они выкатили обновление, и рабочий процесс изменился.

Теперь новая задача в Cursor запускается командой /opsx:new, он создает шаблон спеки под задачу.

И дальше через команду /opsx:continue ведет тебя за ручку, шаг за шагом, документ за документом. И ты каждый документ валидируешь.

Почему это круто?

• Потому что на тебя не валится сразу кучу текста.
• Потому что, если в первом документе увидишь ошибку и поправишь, то в следующих вероятность ошибок уменьшается.

Если очень интересно, но ничего не понятно, то жди запуска нового потока моего курса по вайбкодингу в марте)

Вчера прошло четвёртое занятие по вайб-кодингу, где мы плотно работали с подходом SDD.

Пока агент работал, мы успели немного порефлексировать о будущем нашей индустрии.

Выделил два ценных вопроса из Q&A сессии, которыми хочу поделиться с вами.

Q: «Некоторые оставляют Cursor крутиться в лупе: он сам что-то пишет, через терминал запускает тесты и правит ошибки. Есть ли способ сделать это более безопасно, чтобы он не жёг квоту и не требовал всех разрешений сразу?»

Я сознательно не использую полностью автономные лупы, и вот почему:

• Риск «зацикливания» на ошибке. Если агент допустит ошибку в рассуждениях, он начнет ее «мусолить». Ошибка останется в контексте, и с его ростом вероятность вернуться к ней только возрастет.

• Сложность тестирования. Когда запускаешь много агентов параллельно, они создают большое количество изменений, которые потом придется тестировать в моменте, что очень выматывает.

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

Q: «Бывает, что я теряю представление о кодовой базе: Cursor знает, что он там сделал, а я уже не понимаю. Приходится просто продолжать промптить, потому что нет выбора. Как этого избежать и не терять контроль?»

Смириться с этим, мы плавно идем в сторону того, что все чаще оперируем контекстом, и все реже синтаксисом языка.

С ростом способностей агентов учитывать архитектуру и стиль кода, мы будем всё чаще «отпускать вожжи».

В некоторых ситуациях у вас не будет выбора, например вы знаете, что ваш техлид не пропустит ваш MR.

И тогда придется снижать скорость агентной разработки, чтобы сохранять контекст не только у агента в памяти, но и у себя в голове.

Представьте начало 2025 года.

Вы - техно-блоггер и вам пишут из Anthropic со следующим предложением:

Вот вам ранний безлимитный доступ к Claude Code на месяц.

Сделайте что-нибудь крутое с помощью нашего инструмента и напишите об этом.

Вот вам 10k$ вознаграждение.

И вот у вас есть:
• технический бэкграунд
• собственная аудитория
• безграничный ресурс токенов и топовый инструмент
• 10 тысяч зеленых, которые кстати можно потратить на маркетинг

Но вам осталось жить год и у вас 5 детей.
У вас последний шанс что-то сделать и оставить им.

Что бы это было?

Помните мой сервак взломали боты?

Делюсь с вами коротким отрывком со второго потока, как с помощью агента Warp настроить базовые настройки безопасности, о которых писал в прошлом посте.

Продублирую их еще разок тут:

1️⃣ Создать нового пользователя c root правами, а root пользователя отключить.

2️⃣ Отключить вход по паролю, а использовать ssh ключи.

3️⃣ Установить fail2ban, чтобы блочить попытки подключений.

4️⃣ Настроить ufw файрволл, отключить все порты, и открыть только необходимые, обычно это 22, 80, 443.

С тех пор кстати я переехал с Coolify на Dockploy, и сегодня буду показывать студентам 2-го потока, как работать с Dockploy.

Будем настраивать dev/prod окружение, поднимать базы данных, мониторинг, бэкапы и всю ту прелесть, которая поможет вайб-кодерам спать спокойно 😁

Топ-3 способа найти идеи для SaaS

Я честно ожидал, что пост с 5 детьми сгенерит больше интересных идей.

Но раз такой кризис, давайте закину три критерия выбора ниши и три источника для вдохновения.

Если бы мне остался год и было 5 детей, я бы выбирал нишу по этим 3 критериям:
1. Есть рынок, есть конкуренты
2. Понятно, где найти первых клиентов
3. Можно сделать MVP в течение 2-3 недель

Как бы я искал идеи и оценивал рынок:
1. Deep Research анализ конкурентов
2. Взял подписку на acquire.com, чтобы посмотреть какие SaaS есть в продаже, и какие у них метрики.
3. Посмотрел бы все стартапы в которых инвестировал YCombinator

Как бы я работал над продуктом:
1. Взял только 1 киллер-фичу и сигментировался на определенную аудиторию
2. Писал бы в запрещенные метовские соцсети о процессе работы над проектом
3. Сокращал путь пользователя, количество кликов, Time To Value продукта.

Есть кстати альтернативный путь - импортозамещение в РФ 😄 Хочу как-нибудь тоже попробовать)

Коротко, о том, что я использую в вайб-кодинге 😂

ОПЫТ И МОЗГИ! 🧠

Хочу в эту пятницу 27 февраля в 19:00 провести эфир в формате интервью с Денисом, про которого недавно писал.

Когда ему предложили 600 000 рублей за сервис, который он завайбкодил в одного, я подумал - случайность.

Но, когда он сделал бота и собрал почти 600 подписок по 790 рублей, я понял, что пора провести с ним эфир, и выведать секреты, как он это делает.

🔥 Ставьте огонечки, если тоже хотите узнать все секреты.

Скилы и AGENTS.md в кодинге мало эффективны. Теперь официально!

Недавно вышли два исследования, которые меня очень порадовали.

И вот почему.

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

Казалось, что как автор паблика про вайб-кодинг, я должен был «держать марку» и всем говорить: MCP, Skills, Subagents, Hooks, SDD, TDD, итд.

Но теперь этого точно не нужно делать, потому что вышли два исследования, которые эмпирическим путем выяснили, что самогенерируемые скилы и инструкции мало эффективны в кодинге.

Помните, я снимал коротенький видосик про использование skills в Antigravity? Так вот, я тогда заметил, что качество дизайна со скилом и без скила, ну не сильно таки лучше.

Я сначала недоумевал: «то ли я дурак, то ли лыжи не едут». Оказалось лыжи не едут.

Вышел SkillsBench - исследование и бенчмарк, который тестирует скилы, как самостоятельный артефакт.

Авторы 15+ топовых универов, взяли 84 задачи из 11 доменов и проверили 3 условия: без скилов, с готовыми скилами и с самостоятельно сгенерированными.

Итого 7308 тректорий тестирования. Итак, какие были результаты?

Готовые скилы в среднем поднимают pass rate на 16,2%, НО! Только там где модели плохо покрыты обучением, например: медицина, промышленность. В разработке ПО, собственно, где мы с вами его чаще всего используем, всего на 4,5%. Что я интуитивно всегда ощущал.

Что интересного заметили в исследовании: самогенерируемые скилы не работают. Моделям предлагали писать гайды, а потом решать задачу, результат упал на 1,3%, по сравнению с работой вообще без скилов.

Нужно перестать использовать скилы? Нет, просто понимать где и когда они дают лучше результаты, а когда лишь тратят наш контекст и сжигают токены.

Следом вышло второе исследование про AGENTS.md

Авторы берут задачи по разработке в открытых репозиториях и смотрят, как кодинг-агенты справляются с ними:
- без AGENTS.md
- с самогенерируемым AGENTS.md
- и написанным разработчиком репозитория.

Вот что выяснилось в ходе исследования:

Сгенерированные контекст‑файлы чаще вредят, чем помогают.

В среднем они немного снижают успех решения задач на 2–3%, при этом повышают стоимость более чем на 20%.

Человеческие контекст‑файлы дают только небольшой плюс.

Прирост качества примерно на +4%, но к стоимости добавляют до 19%.

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

Значит ли это, что у себя на курсе я больше не буду давать эти инструменты? Нет, буду, но с оговоркой, когда и сколько буста они дают.

Умение вайб-кодить и умение зарабатывать — это два разных навыка.

Тоже самое касается традиционной разработки, даже если вы сами будете писать код.

Только в случае с вайб-кодингом у вас больше шансов. Так как сможете делать больше итераций попыток в момент времени.

Со временем количество перерастает в качество.

Но чтобы это качество дало денежный результат, есть два варианта:

• пишите публично о том, что делаете
• платите за рекламу

Лучше конечно совмещать оба варианта.

Вариант, когда вы сделали, опубликовали, и ждете — не работает.

В эту пятницу в 19:00 проведем эфир-интервью с Денисом, который собрал 500 подписок по 790 рублей, и отказался продавать свой сервис за 600 000 рублей.

🔥 Ставьте огонечки, если собираетесь прийти на эфир и узнать, как можно заработать на вайб-кодинге.

Напоминаю, сегодня в 19:00 пройдет эфир интервью с Денисом.

Денис поделиться реальным опытом, как не только завайбкодить, а еще и монетизировать этот навык.

Это эфир не про единорогов с миллионными MRR, и инвесторов.

Это история про простого парнишу, который без технического опыта и связей смог заработать на технологическом продукте.

На эфире разберем:
- какой опыт и сколько времени достаточно, чтобы сделать свой продукт
- какие инструменты, модели и практики использует Денис
- как найти тех, кто будет платить за твой продукт

Запись будет, но если не прийдете, то на записи не будет ваших вопросов)

Или будут, пишите кстати в комментах, что хотели бы узнать в Дениса, я задам ваши вопросы на интервью.