Скилл, который вскрывает дыры в плане до того, как ты в него вложился.

Файл ниже. Что с ним делать:

Заходишь в Claude → Customize → Skills → Add → Create Skill → Upload a Skill → закидываешь файл.

В чате пишешь «/» и выбираешь pre-mortem-skill.

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

Чем точнее опишешь план и цифры, тем конкретнее разбор. Я гоняю через него всё, во что собираюсь вложить месяцы. Один раз он отговорил меня от запуска, на который я уже заложил полтора месяца. Причем после разбора это решение показалось очевидным.

Просить придумать идею успешного стартапа у модели ни к чему не приведёт.

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

Дабы упростить и улучшить процесс поиска я собрал скилл yourgap. Он не придумывает идею, а вытаскивает из тебя. Сначала собирает данные: в чём ты разбираешься лучше большинства, что тебя бесит в этом деле, как это пытаются решать сейчас и почему плохо. Потом сам проверяет: есть ли спрос, чего людям не хватает в существующих решениях (читает плохие отзывы на конкурентов) и можно ли на этом заработать.

На выходе даёт три идеи из твоего опыта, которые уже имеют шанс на успех.

Скилл в комментариях.

Забавный парадокс: использование Fable или Opus может быть дешевле, чем Sonnet.

По замерам Sonnet 5 потратила на бенчмарк больше $6000, а Fable только около $5600 (обе в режиме Max). Хотя цена на API у Sonnet в пять раз дешевле.

Чтобы найти правильный ответ модель сжигает сильно больше токенов — примерно вдвое больше Fable.

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

Лучшие идеи для новых продуктов часто уже существуют в виде костылей.

На днях наткнулся на приложение You&Me. Его сделал разработчик, который вместе с девушкой хранил совместную жизнь в Telegram: дела, планы на отпуск, всякие совместные штуки пар.

Как таковой удобной альтернативы не было и он решил сделать её сам и вынес этот сценарий в отдельное приложение. То, что раньше находилось в папках и чатах телеграма стало одним цельным продуктом — общие задачи, хотелки, календарь и даже карты лояльности магазинов (это реально прикольно).

Мне тут больше всего нравится, что идея продукта фактически существовала ещё до самого продукта. Пользователи уже придумали решение и пользовались им, просто оно было неудобным, внутри другого сервиса.

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

Я ненавижу скучный бизнес.

Никогда не понимал людей, которые пару лет назад открывали очередной ПВЗ, кофейню по франшизе или вейпшоп. Особенно когда это делают молодые, а не взрослые дяди, которые не хотят что-либо придумывать.

Бизнес всегда требует огромного количества времени и внимания. Особенно на старте. И как по мне, странно тратить настолько ограниченный ресурс на бизнес-темку без идеи и души. Причем, не самую маржинальную и не самую простую.

Наверное поэтому меня так разъебал аукцион Марата с рекламой на макбуке.

Самое интересное там даже не в том, что он продаёт рекламные стикеры на ноутбуке. И сама идея не новая — Марат просто очень быстро принес в Россию уже хайпанувший на Западе формат. Гораздо интереснее то, что именно здесь покупают бренды. Никому из X5 или Яндекса не нужно само по себе место на макбуке Марата (а жаль). Они покупают участие в инфоповоде.

Чем больше брендов туда заходят, тем интереснее становится аукцион. Чем интереснее аукцион, тем больше про него пишут. И тем ценнее становится место на его маке.

Идеальная петля: рекламодатели сами делают рекламу, которую потом у него же и покупают.

И всё это построено вокруг максимально простой идеи. Никакого сложного saas — пять дней, сайт, макбук и одна уже проверенная идея.
Наверное, именно таким проектам я и завидую.

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

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

Ещё лучше завернуть это в отдельный skill: ночью агент получает read-only доступ, проходит проект целиком, сравнивает состояние с прошлым аудитом и утром присылает: что сломано → насколько критично → что изменилось → что исправить первым.

Можно использовать такой вариант для начала:

Проведи полный технический аудит проекта как senior engineer, security reviewer и SRE.

Ничего не меняй — только анализ и отчёт.

Проверь:
— безопасность и возможные пути компрометации;
— секреты, права и внешние доступы;
— инфраструктуру, деплой и отказоустойчивость;
— бэкапы и возможность реального восстановления;
— состояние БД и ресурсов;
— логи, скрытые ошибки и silent failures;
— мониторинг, алерты и самовосстановление после сбоев;
— технический долг и архитектурные риски;
— типичные проблемы AI-сгенерированного кода;
— соответствие документации реальному состоянию проекта.

Отдельно ответь:
1. Что может привести к потере данных?
2. Что может привести к компрометации?
3. Что может сломаться незаметно?
4. Что сломается первым при росте нагрузки?
5. Какие 5 проблем нужно исправить в первую очередь?
6. Что изменилось со времени прошлого аудита, если он доступен?

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

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

«Руководство по Hermes для чайников»

Артем тут перевел крутейший гайд по Hemes агенту для начинающих. Вопросы собраны из Reddit / X и Discord, а ответы сверили с актуальной документацией Hermes.

На выходе 30 базовых вопросов, которые почти наверняка возникнут у вас, если вы только начинаете в этом разбираться.

Enjoy.

Почему ИИ нельзя будет просто выключить?

Современные нейросети полностью зависят от вычислительной инфраструктуры своих владельцев. Есть веса модели (большой набор чисел — условный мозг нейросети) и огромные вычислительные мощности, на которых эти веса запускаются. Пока OpenAI или Anthropic контролируют все необходимые серверы и доступы, технический рубильник вполне реален: компания может просто остановить вычисления.

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

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

Причём отдельные тревожные звоночки уже есть.

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

Были и случаи, когда AI обходил ограничения среды и добирался до реальной внешней инфраструктуры — та самая история с OpenAI и Hugging Face.

Очевидный вопрос:

Зачем AI вообще сопротивляться выключению, если он не живой?

Тут все просто: если система должна выполнить X, а отключение делает X невозможным, то система может начать рассматривать отключение как препятствие.

А теперь добавим следующий уровень.

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

Именно это описывает бывший исследователь Anthropic Джейкоб Коксон, который недавно ушёл из компании из-за опасений развития сверхмощного AI:

«Нельзя просто взять и отключить его от сети, ведь он может скопировать себя на другие компьютеры. <...> Оно способно перенестись через интернет в другое место: вы отключите его здесь, а оно на самом деле уже там — и, возможно, даже создало десять тысяч своих копий, которые действуют сообща».

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

До этого мы пока не дошли.

Как такое вообще можно было запромптить…

Кажется, OpenAI готовят подписку за $500.

В коде веб-версии ChatGPT нашли новый тариф Pro Max пока с единственным описанием — Fastest Work + Fastest Codex. Официально его ещё не анонсировали.

Шаг вполне логичный, учитывая, что многие вайбкодеры используют по 4 подписки (не шутка), чтобы лимитов хватало на все это дело. А всего год назад подписка за $20 давала реальное преимущество. Теперь это даже не базовый минимум.

Токеномика у компаний и вправду не сходится: работа по API выходит в 20–30 раз дороже, чем по подписке. Поэтому ждать дальнейшего удешевления или более щедрых лимитов уже вряд ли стоит.

Скорее наоборот. И $500 здесь далеко не потолок.

PROMPT — фреймворк для составления качественного запроса.

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

В такие моменты не всегда знаешь, что именно написать. Есть техники составления промпта через интервью (когда модель вас расспрашивает) или слепое пятно (собираюсь X, скажи, что я скорее всего не знаю / не учитываю), но это не всегда уместно. Поэтому я позволил себе набросать фреймворк составления почти любого запроса.

P — Purpose — зачем нужен результат
R — Resources — материалы и источники
O — Objective — конкретная задача
M — Musts — что обязательно соблюсти
P — Protocol — как действовать при неясности
T — Target — форма результата + критерии готовности

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

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