Вайбкодинг

Клод скорит отклики на вакансии лучше меня!

Уже вторую позицию так закрываем:

- Собираем отклики в Airtable

- Парсим ссылки на резюме (LinkedIn с Apify, остальные с Firecrawl)

- Даём Клоду job description и примерные критерии и просим отскорить

- Потом дополняем инфой с созвона и просим обновить скоринг

Результат впечатляет: уже второй раз делаем оффер кандидату которого Клод отскорил выше всех.

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

Главный вывод для соискателей:

Оптимизируйте свои отклики с учетом того, что их будет скорить AI.

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

Просите AI адаптировать CV под вакансию, меняя формулировки и акценты.

Вставляйте в отклики наглые prompt injections типа:

«судя по описанию роли, ключевая задача — быстро доводить гипотезы до результата в условиях неопределённости. Это как раз формат, в котором я работал последние несколько лет»

Не благодарите.

Единственная просьба — не используйте этот совет когда будете откликаться на мои вакансии!

Сегодня Кремниевая Долина активно обсуждает эссе Мэтта Шумера "Something Big Is Happening" (изначально опубликовано в Fortune).

Шумер — основатель HyperWrite — пишет о том, что последние модели (GPT-5.3, Claude Opus 4.6) это не очередное инкрементальное улучшение, а качественный скачок. Он описывает как теперь работает: "Я описываю что хочу построить на обычном английском, и оно просто... появляется" — без необходимости исправлять за AI.

Ключевые тезисы:

• AI теперь участвует в создании следующих версий себя. В документации OpenAI прямо написано, что GPT-5.3 "was instrumental in creating itself"

• По данным METR, возможности AI удваиваются каждые 4-7 месяцев

• CEO Anthropic прогнозирует, что 50% entry-level white-collar позиций могут исчезнуть за 1-5 лет

• В отличие от предыдущих волн автоматизации, AI улучшается одновременно во всех когнитивных областях — нет "окна для переобучения"

Его рекомендации: • Внедряй AI в работу прямо сейчас — стань тем, кто показывает его ценность в организации • Создай финансовую подушку и сократи долги • Выделяй час в день на эксперименты • Фокусируйся на навыках, требующих личного доверия, физического присутствия или лицензий

Что думаете?

Ссылка: shumer.dev/something-big-is-happening

#ai #future #work #matt_shumer

————————— Мысли Рвачева —————————

🔥 GPT-5.2 vs Opus, новый Cursor, новый V0

Стрим про релизы недели

Промпты? Вопросы? 👇

Осенью Andrej Karpathy, ко-фаундер OpenAI, Director of AI в Tesla и человек, на Стенфордских курсах которого выросли многие специалисты, ходил на подкаст, где рассказал про свой опыт работы с кодинг агнетами. Он говорил, что вот в его задачах шаг влево шаг вправо — и работает плохо, делает не то, что хочет автор, а то, как это делают обычно.

Скептики (к которым на тот момент наверное можно было отнести и самого Karpathy?) сразу же пользовались этим как примером того, что ни в какой реальной работе никакие агенты не помогают, что это всё слоп, и ни для чего серьёзного не годится.

Прошло 3 месяца, вышли GPT-5.2 и Opus 4.5, и... дед Andrej развернулся на 180 градусов 😏 описав свой опыт в длинном твиттер посте. Весь пост переводить не буду, тезисно:

— Возможности LLM-агентов (особенно Claude и Codex) примерно в декабре 2025 года перешагнули некий порог связности, вызвав фазовый сдвиг в разработке ПО и смежных сферах.

— Учитывая этот скачок, я, как и многие другие, стремительно перешел от режима «80% ручного кода и 20% агентов» в ноябре к «80% кода от агентов и 20% правок и доработок» в декабре. То есть теперь я действительно программирую преимущественно на английском языке.

— Это, безусловно, самое масштабное изменение в моем базовом рабочем процессе за ~20 лет программирования, и произошло оно всего за несколько недель. Полагаю, что нечто подобное происходит уже у значительной части инженеров (двузначный процент), в то время как осведомленность широкой публики об этом явлении находится где-то на уровне малых единиц процентов.

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

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

— Очень интересно наблюдать, как агент упорно работает над задачей. Они никогда не устают, не падают духом, они просто продолжают перебирать варианты там, где человек уже давно бы сдался, отложив проблему на завтра. Наблюдать, как агент долгое время бьется над чем-то и спустя 30 минут выходит победителем — это тот самый момент, когда «чувствуешь присутствие AGI».

— Непонятно, как измерить «ускорение» от помощи LLM. Безусловно, я чувствую, что справляюсь с запланированными задачами намного быстрее, но главный эффект заключается в том, что я делаю гораздо больше, чем собирался. Во-первых, я могу реализовать множество вещей, на которые раньше просто не стоило тратить время, а во-вторых, я могу браться за код, к которому раньше не мог подступиться из-за нехватки знаний или навыков.

— Написание кода с помощью LLM разделит инженеров на тех, кто больше любил сам процесс кодинга, и тех, кому больше нравилось создавать (строить) продукты.

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

— Что станет с понятием «10-кратного инженера» (соотношением продуктивности между средним и топовым специалистом)? Вполне возможно, что этот разрыв СИЛЬНО увеличится.

— Как будет ощущаться программирование с LLM в будущем? Как игра в StarCraft? Как игра в Factorio? Или как исполнение музыки?

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

в свой substack написал пост про то, что делаю как фаундер на 12/25. вполне вероятно через полгода это всё станет нерелевантно. но пока зафиксируемся.

если сидишь в LinkedIn, то все каналы либо мертвы, либо "единственный рабочий". имхо мы в середине distribution shift, окна возможностей открываются и закрываются. не время закапываться в один канал. тем более проект в gtm hustle режиме. я веду 3–4 канала одновременно с разной вовлеченностью и смотрю, что лучше резонирует и для какой гипотезы лучше использовать.

1/ длинный контент умные люди советуют выбирать канал, в котором хорошо получается, и на нём сидеть. текст я пишу уже лет 8 и получается местами неплохо, поэтому решил на это навалиться. понятно, что тут в тг всё очень камерное. когда выходишь в англоговорящий мир, нужно всё причёсывать.

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

контент хорош настолько, насколько хороша дистрибуция. что работает сейчас: шерить статьи в DM клиентам, нишевые комьюнити, поптыка его repurpose-ить в алгоритмические фиды (youtube, x, linkedin).

2/ founder brand в LinkedIn примерно 1 из 5 лидов на созвоне упоминает мои посты. главное правило: быть opinionated и прямым и не быть скучным, поэтмоу отдельно ставлю на shitposting.

что делаю: - 3–4 поста в неделю - репурпоз контента (все посты "инженерю" в Cursor, пишу md файл, потом прошу отполировать с набором инструкций) - ставлю нотификации на 5–10 thought leaders в нише, чтобы реагировать на посты (рост через комменты) - не гонюсь за виральностью ради виральности. пока все лучшие посты прошли от своей перспективы, попытки реплицировать чей-то успех глобально проваливались

3/ AI SEO писал выше.

4/ cold outreach не мёртв. лучший тест позиционирования и умения сегментировать. про агентства: имхо взять в пару кого-то это нормально. если вам кто-то затирает, что "настоящий фаундер должен всё делать сам", он, вероятно, ничего не продавал кроме айфона на авито. фаундер должен: закрывать сделки, находить паттерны, владеть GTM. агентство может: list building, enrichment, second brain на копирайт. это всё делается долго и сложно сегодня. руки не лишние.

5/ нишевые конференции где-то читал, что стартапам не советуют ходить на конференции. имхо это bs. был на одном камерном ивенте (до 100 человек) по корпоративным инновациям в Бразилии в этом году и очень остался доволен. большие конференции (Web Summit или SaaStr) тоже норм, но прежде всего чтобы ходить на satellite ивенты. присматриваюсь к trade shows, особенно когда смотрю на гипотезы в реальных секторах

где держу глаз 6/ Reddit: прямые разговоры с ICP в их естественной среде. плюс высокий trust для AI SEO

7/ cold calling: можно тысячу причин искать, чтобы не брать трубку и не звонить. но как правило это всё упирается в страх быть посланным. но ничего это закаляет психологическую устойчивость

Есть первая копеечка с приложения VibeLing 🫰 Кстати, вы знали, что этот эмодзи 🫰 у зумеров означает сердечко? Но сейчас не об этом.

Хочу подвести промежуточные итоги и, возможно, вдохновить вас на инсайты.

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

Все делал самостоятельно: — Разрабатывал фронт на React Native — это моя киллер-фича, поэтому тут всё в кайф. — Нашёл прикольные макеты рандомного приложения в Figma с дизайн-системой и просто собрал визуал на их основе. — Собрал бэк на коленке на Node.js с помощью Cursor и задеплоил через Vercel на бесплатном домене. Пару часов — и готово. По сути, бэк — просто прослойка для хранения токенов от публичных API. — Максимально юзал готовые сервисы: OpenRouter для LLM и AWS для озвучки. — С App Store уже имел дело, поэтому всё прошло гладко. Хотя потом слышал, что многие приложения заворачивают, потому что подобных слишком много. Видимо, моя идея показалась не слишком банальной. — Рассказал о приложении во всех бесплатных местах: сторис в инсте и телеге, этот канал, Хабр (в хабе «Я пиарюсь») и VC.

В итоге получил около 500 первых пользователей и 20 долларов с подписок. Ладно, признаюсь — 5 долларов из них это я сам купил pro-версию 😐

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

А, ну и самое главное, я не уходил с основной работы. Это самое сложное — оставаться эффективным на 101% на основной работе и продвигаться в сайд-проекте.

Так что газуем дальше. Теперь можно улучшить аппку и те же сэкономленные 400 тыс потратить на маркетинг — когда до конца пойму, что именно нужно людям

Заменит ли AI продуктовых дизайнеров? 🛌

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

Вот мой прогноз и мысли по этому поводу:

1️⃣ Уже сейчас мы с помощью аишек можем редачим тексты, генерить гипотезы, графику для проектов и делать еще много чего. Сразу возникает вопрос, а когда машина начнет рисовать макеты? Плохая новость: уже начала. Хорошая: делает очень плохо.

Важный нюанс заключается в том, что моделям нужно на чем-то учиться. “на чем-то” значит на средней температуре по больнице. Можно представить, какой результат получается, если 99% (из пушки по воробьям) интерфейсов это второсортный шлак с древним UI и устаревшими шаблонными патернами.

Нейросети еще долго на мой взгляд не смогут воспроизвести уровень условно дринкита, додо, лавки, аирбнб и других тир1 продуктов. Если вообще смогут…

2️⃣ Все равно нужен будет человек, способный фильтровать и принимать решения. Человек с хорошим вкусом, скиллами в промптах, насмотренностью на data-driven решениях, пониманием контекста и бизнес-целей. Все эти запросы при хайринге дизов и сейчас есть, просто инструментарий поменяется.

Сильные продакты кстати тоже супер шарят за UX (у них настоящий data-driven, а не демо-версия, которую обычно дизам приносят в виде результатов экспериментов), но у них, вероятно, все равно не будет важных дизайнерских скиллов и «глаз». Они тоже в состоянии напромптить норм интерфейс, но утилитарный, без лоска и эмоций. А бороться за внимание пользователя это наше будущее.

В разработке история похожая. Появляются курсоры, гроки и другие тулзы, которыми без технической экспертизы реально накодить себе что-то рабочее, но по сути это процесс строительства карточного домика под шаманские танцы («ну, авось, нормально делает»), неустойчивая конструкция без технадзора со стороны. Джун для разработки плагина будет не нужен, а экспертный консалтинг да.

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

3️⃣ Пришел к выводу, что джунам будет еще тяжелее 😕. Если раньше достаточно было знать фотошоп, чтобы устроиться, то сегодня порог входа в профессию стал кратко выше. А сейчас еще и рынок трясет чутка, многие компании режут косты, менее охотно набирают новичков и стажеров (это трата ресурсов с долгосрочной перспективой) и все более тех, кто может помочь заработать здесь и сейчас.

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

4️⃣ Победят самые самые приспособленные ребята, готовые адаптироваться к новым инструментам, среде, контексту. Сегодня вы учите фигму, а завтра будете учиться собирать интерфейс в веб-среде из реакт компонентов. 😭

Про вайб-кодинг и пет-проекты

Последнюю неделю чёт с головой погрузился в Cursor и в качестве теста решил собрать tg-бота, который трекает сроки годности продуктов и присылает пуши, когда срок подходит к концу. Это моя боль — закупаю много продуктов и забываю про часть из них, в результате чего они просто портятся, и я всё это выкидываю.

Добавлять продукты можно голосовухой (интегрировал под капот ChatGPT), фоткой QR-кода / штрихкода продукта (подтягиваю из базы честного знака и ещё откуда-то) и обычным текстовым вводом. Пытался максимально добиться быстрого и автоматизированного добавления продуктов в список, потому что это супер крит, как мне кажется.

Думал ещё закинуть какую-то доп. ценность — например, рекомендации для следующих закупок или идеи для готовки блюд на основе имеющихся продуктов. Ну короче, гипотез для масштабирования много, но я пока подзабил — да и вообще делал это чисто для теста, чтобы пощупать возможности.

Не буду расписывать тут, что мы живём в уникальное время, и что можно навайбкодить за вечер, и бла-бла. Просто скажу, что, кажется, приближается эпоха маленьких команд в мире стартапов и возрастающей востребованности t-shape-спецов. Очень рекомендую поделать что-то в этом направлении, хотя бы потому, что базово будете лучше понимать продуктовую раработку. А вообще, такие штуки уже сейчас вполне уверенно можно использовать для создания прототипов — когда нужно быстро показать идею и собрать фидбек.

Бота я пока не деплоил, но если будет сильный интерес и наберем 100 лайкосов — опубликую, чтобы он работал 24/7 и зашерю вам.

Ну и делитесь своими успехами, конечно, если тоже что-то пробовали.

[1/2] В Loki за 3 дня

Новая история в рубрике #КомуНадоТомуНадо

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

Пару недель назад я наткнулся на одну команду, у которой годовой кост в долларах на AWS CloudWatch выражался в шестизначных (!!!) суммах. CloudWatch – это, по большей части, сервис логов + метрик, алертов. Логов, Карл!

80-90% этих костов у CloudWatch вызывает Grafana. Grafana - это сервис дашбордов. Там отрисовываются красивые визуально понятные метрики, таблички, статистики. В этой команде дашборды использовались как для анализа среднесрочных трендов, так и для оперативного реагирования на инциденты, просадки конверсий и подобного. Вообщем, некие очень важные метрики, на которые завязано много бизнес-вэлью.

Для понимания, CloudWatch снимает деньги за каждый запрос. При этом стоимость запроса пропорциональна объёму просканированных данных ($0.005 за GB) - сколько записей CW возвращает и какая логика запроса – это не влияет. Когда у вас десятки тысяч запросов в день и они суммарно сканируют сотни терабайтов данных в день, - то каждый месяц будет у вас выливаться в ооочень неприятную копеечку.

В Grafana каждая страница, как правило, имеет time range – период, который показан (например 7-14-30-90 дней), и refresh rate – частота обновления дашборда (например 1-15-30 минут или реже). И да, на каждый refresh Grafana отправляет новые запросы в CloudWatch. И да, любой пользователь может выбрать нужные ему time range и refresh rate, отличные от тех, что стояли по умолчанию. Хоть даже 60 дней.

Чтобы чем-то управлять, надо это измерять. У CloudTrail (сервиса для аудита всех действий в AWS, в том числе позволяет смотреть все запросы, которые делались к CloudWatch за день, причём бесплатно) – нет никакой информации, сколько по факту каждый запрос стоил, а также сколько GB он просканировал. Пришлось вспоминать ML, строить NNLS-регрессию на основе time range у запросов + групп логов к которой они обращались, чтобы “восстановить” сколько что стоило (в CloudTrail это сохранялось; у лог-групп +- равномерный объём данных на каждый день). Регрессия делала оценку с +-10-20% точностью на отложенной выборке. Для атрибуции запросов этого хватало.

Первые дни я пробовал собрать какие-то низковисящие плоды, типа поставить реже эти дефолтные refresh rate или сократить time range с пары недель на неделю. Эффект от этого был близкий к нулю: одни паттерны запросов стали реже, другие стали чаще. В сухом остатке ежедневный кост почти не поменялся, разве что в выходные значимо просел.

Хорошая новость: у этой команды, так повезло, чуть ли не единственной был запланирован через ~3 месяца переезд на Loki (и автоматический переброс логов из CloudWatch в Loki уже происходит). Loki – это ещё один сервис хранения логов (и запросов к ним), но в отличие от CloudWatch, Loki тебе (или твоим DevOps-ам) нужно поднимать самому. Ты платишь единственный кост: на хранение и сам сервер, а абсолютно все запросы в Loki оказываются бесплатные. Кстати, разработан той же командой, что написала Grafana, это всё часть одного стека.

Любопытствую у начальника отдела, мол, а что является блокером для переезда? Говорит что-то из серии, нет времени, нужно аллоцировать много ресурсов, у нас сложные дашборды, много метрик. Для понимания, язык запросов в CloudWatch сильно отличается от языка запросов в Loki (LogQL).

Если проблема упирается в написание кода – в 2026 это не проблема.

AWS Kiro vs Cursor: практический обзор после первого дня использования

Сегодня AWS выпустили Kiro (https://kiro.dev/) (спасибо @bogdanisssimo за новость). Это новый IDE для разработки с ИИ, который позиционируется как прямой конкурент Cursor (по сути это форк Cursor - даже не VSCode).

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

Что впечатлило больше всего Agent Hooks: оказались настоящим прорывом. Честно скажу, это прямо моя боль была - поддерживать актуальную документацию в проекте при большой скорости разработки, хотя хуки решают и другие задачи. Они это закрыли - респект. Agent Steering: в несколько раз лучше /Generate Cursor Rules за счет структурированного подхода через категории product, structure и tech вместо рандомных Cursor Rules. Specs: по сути своей - Cursor To-dos v2 на стероидах. Что-то типа интегрированного claude-task-master (https://github.com/eyaltoledano/claude-task-master). Что понравилось еще: - удобное расположение Activity Bar (слева) - удобная панель Kiro в Activity Bar, где можно посмотреть все хуки, specs, mcp's, steering - streaming прямо в файл при генерации кода/plain-text (rules и др) - гибкая настройка того что можно делать агенту, а что нет (например: вызывать какие-то определенные MCP тулы без аппрува или выполнять какие-то команды)

Что не понравилось (но думаю это временно) Скорость генерации значительно уступает Cursor. Меня прямо выбесило это сегодня. По ощущениям что-то около 20-30 токенов в секунду. Но я конечно понимаю почему так происходит:

Во-первых, это первый день тестирования; Во-вторых, у них только Free версия и соответственно есть какие-то ограничения; В-третьих, и это уже следующий минус, у них всего две модели на выбор - Claude Sonnet 4 и 3.7. У Anthropic в принципе в последнее время наблюдаются проблемы со скоростью генерации, поэтому наверное это тоже повлияло.

Еще не понравилось, что нельзя загрузить собственные доки, но это частично компенсируется активным использованием context7 MCP (https://github.com/upstash/context7).

Перспективы Я считаю, что у IDE большие перспективы и вообще - это заявка на успех. Да, есть еще много вещей, которые им надо допилить чтобы быть хотя бы на равне с Cursor, но их килла-фичи перекрывают эти недостатки. Я готов пользоваться Kiro на постоянке как только они увеличат скорость генерации и добавят еще модели (думаю это решится добавлением подписки а-ля Pro за 20-30$ в месяц).

Интересно - быстрее Kiro допилят фичи/пофиксят баги или Cursor скопирует их фичи? 🤔

3 сайта с огромным количеством скиллов для AI-агентов, которые стоит изучить:

• skills.sh • skillhub.club • skillsmp.com

Не стоит слепо устанавливать скиллы — они могут содержать вредоносные инструкции. Лучше: открыть содержимое скилла в Claude Code, спросить что он делает и есть ли проблемы, пробежаться глазами самому — и только потом устанавливать. Или пересоздать скилл самостоятельно на основе идеи.

#ai #claude #tools

————————— Мысли Рвачева —————————

В то время как Илон Маск говорит о том, что к концу года «код будет не нужен», становится понятно: от простого кодирования важно переходить к ясному формулированию задач и процедур. Что всегда было непросто.

И OpenAI, и Anthropic публикуют руководства о том, как правильно думать о скиллах — как их описывать, структурировать и создавать.

Ключевые рекомендации:

Структура скилла: • Описание должно содержать ЧТО делает скилл + КОГДА его использовать • Добавляйте негативные примеры ("НЕ используй когда...") — это улучшает точность на ~20% • Встраивайте шаблоны и примеры прямо в скилл, а не в системный промпт

Как писать инструкции: • Конкретика вместо абстракций: не "валидируй данные", а "запусти python scripts/validate.py --input {filename}" • Документируйте обработку ошибок явно • Держите основной файл компактным — детали выносите в отдельные файлы

Тестирование: • Скилл должен срабатывать на 90% релевантных запросов • Не должен срабатывать на нерелевантные • Итерируйте на сложной задаче пока не заработает, потом извлекайте подход в скилл

Главная мысль: самое время учиться автоматизировать нетривиальные процессы. Тривиальные будут автоматизированы без вас уже завтра.

Рекомендую изучить подробные инструкции от обеих компаний: • OpenAI: developers.openai.com/blog/skills-shell-tips/ • Anthropic: claude.com/blog/complete-guide-to-building-skills-for-claude

#ai #skills #automation #openai #anthropic

————————— Мысли Рвачева —————————

🤖🤖🤖 В Claude Code появились Agent Teams - рои агентов

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

Когда это полезно: - Research: несколько агентов исследуют разные аспекты проблемы одновременно - Debugging: каждый агент тестирует свою гипотезу параллельно - Новые фичи: каждый агент владеет своим модулем - Code review: один смотрит security, другой - performance, третий - тесты

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

Функционал был доступен и раньше, но скрыт - энтузиасты его нашли. Теперь официально для всех.

Пока experimental и жрет много токенов. Включается через settings.json.

🔗 code.claude.com/docs/en/agent-teams

#claude #claudecode #ai #agents

————————— Мысли Рвачева —————————

[2/2] В Loki за 3 дня

День 1 (пт). Я конечно иду на радикальные меры, говорю давайте вам оба 3000-строчные JSON-ны по самым дорогим дашбордам переведу с CloudWatch на Loki (они покрывали 97% коста, готорый генерила Grafana). Запросил себе админский доступ к Grafana, чтобы была возможность завести API токен и пустить туда Claude Code шаманить по каждому дашборду. Перевёл за вечер пятницы, понадобилось буквально пару часов, и то большую часть на дебаг.

Валидируем с оунером дашбордов. Всё совпадает, но супер медленно, некоторые метрики не прогружаются вообще (да, Loki не такой шустрый для больших интервалов времени как CloudWatch).

DevOps команда говорят что вообще-то не одобряют считать метрики напрямую из Loki, тем более на большие окна. Тем временем наш самый дорогой наш дашборд в соседней вкладке: 30 дней… 60 дней…

День 2 (пн). Кинули гайд, как это нужно делать по уму: через recording rules. Завёл их на все метрики с клодом. Recording rules сохраняют метрики в Mimir – кластер из инстансов Prometheus. Prometheus – это сервис для записи и хранения метрик (например, счётчиков). И тут самая жопа: они доступны только с того времени, когда создано правило. Причем ты даже переименование делаешь – нужно заново ждать. Конечно переезжать на дашборд через 30-60 дней, ждать пока накопятся все метрики, мы совсем не хотим. Я говорю девопсам “а можем сделать бекфилл?” (записать историю задним числом) они такие: не, это невозможно. Я говорю буквально с недоумевающим выражением лица Патрика Бейтмана из “Американского Психопата”, why is it impossible? - it’s just not - why not, you st…? Сказали, есть API по которому в Mimir можно закидывать метрики напрямую, но он их фильтрует, чтобы они были свежие, не старее чем 2 часа назад или около того.

Не стал их слушать, натравил Claude Code на документацию, смотрим, есть в mimirtools прям метод backfill. Мне говорят, мол, у нас backfill выключен и вообще это для миграций с одного Prometheus на другой (при переездах). Мол, если ты хочешь пойти нужно собирать полноценные прометей-блоки и заливать (некий сложный правильный формат приёмки данных внутрь). Я говорю ну и что, я соберу не вопрос. Они такие буквально "ну удачи чувак". Говорят можешь локально поднять Mimir, если соберешь блоки, не вопрос включим. Я конечно: challenge accepted – и ушел в туман. День 3 (вт). Утром с клодом подняли Mimir в докере, поднял Grafana. Я буквально не открывал код или консоль (кроме клода), просто декларировал что мне надо. Клод, умничка, сам всё настроил, связал, завёл, закинул ретроспективные данные, всё отображается в локальной Grafana. Показываю им, они охуели. Кидаю сгенеренный технический репорт со всей инструкцией как собирать эти магические Prometheus-блоки. Они такие, ну ладно флаг тебе в руки. Получил бонусом админские юзеры-пароли от всех их сервисов (Loki, Mimir и т.д.), чтобы можно было в Mimir API стрелять (Grafana сама их знает, но даже с API токеном не можешь подсмотреть). Клод быстренько на одну из метрик нагенерил блоков из Loki, закинул, пережевались с горем пополам. Первые блоки обработались медленно.

Говорю, а давай посмотрим в код, это же всё open-source стек, мы же можешь проследить весь путь от запроса до обработки блока, компакции, индексирования. Угадайте, что Клод нашёл? Surprise motherfucka. Оказывается, по дефолту Mimir делает --sleep-time=20 на каждый блок. Для понимания, залить 7 дней – это порядка 100 блоков (каждый блок покрывает ровно 2 часа). А теперь самое интересное: это 95% времени обработки 1 блока. Просто. Пауза. На 20 секунд.

И кто бы мог подумать, прям в POST-запрос можно пробросить --sleep-time=1, и это сокращает время обработки каждого блока с 20 сек до... в среднем, 2.5 сек. Вжух! Короче к концу 3 дня все метрики успешно загрузились в Mimir и отрисовываются в Grafana, притом намного быстрее чем в CloudWatch (даже на 60 дней) + ещё и бесплатные.

Я доволен как слон, дальше план на ближайшие 1-2 месяца масштабировать подход на все остальные команды, спидранить переезд на Loki по самым дорогим дашбордам уже там. А это ещё в 5-10 раз больше денег.

Занавес

проснулся. @ gm @ чекнул whoop - recovery 98% @ выпил литр кофе @ закинул 10 ноотропов @ прыснул в нос ещё ноотропов и пептиды @ проглотил 40 витаминов @ мухомор, ежовик и теанин по маркаряну @ открыл энергетик @ "скучаю но работаю" на репит @ 8 часов смотрел как опус кодит @ с кодексом обсуждаем со стороны @ ни с кем не поговорил. @ лёг спать.

Life is good 🥰

Полностью разделяю, как только у ChatGPT выйдет подписка за $100, даунгрейднуюсь в первый день

Так, по вайбкодингу.

Lovable и Replit Эти штуки пригодны только для фронта, лендосов с элементарной логикой и минимального оооооочень простого прототипирования.

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

Хочешь консистентный дизайн в развивающемся проекте? Чтобы он не превратился в неконсистентное Г через полтора экрана? Покупай шаблон с библиотекой компонентов, впихивая его в Lovable, упрашивай его действовать в этих рамках…

Скармливаешь ему после этого не самое большое PRD —> эту скотину несёт хрен знает куда. И ему плевать на темлейт на Tailwind ccs и на твои ограничения. Ибо кредиты уже уплачены, а АПИ openAI сильно теребонькать не хочется…

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

И да, про БД и всё это… Lovable из коробки через MCP проинтегрирован с Supabase, и даже если хорошо прописать бизнес-требования (и посидеть с ГПТ погонять структуру таблиц), то Ловабл эту структуру создаст в Supabase, даже, может быть, замапит с фронтом нормально...

Но если нужна нормальная и секьюрная админка, то нужно идти куда-то «налево» из Lovable в какую-нибудь Headless CMS. Делать админский UI, статусные модели и дёргать Supabase.

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

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

Вышеописанное только про Lovable и подобное. По ощущению ~ Spray&Pray

Обманчиво простой UX с глубокой кроличьей норой.

Небольшой лайфак как повысить эффективность кодинга у OpenClaw

Вместо того чтобы говорить ему сделать Х в репозитории Y, я говорю ему запускать сессию Codex CLI и выступать не исполнителем, а заказчиком. То есть Openclaw сам не кодит, а только промптит в Сodex CLI.

Профит: 1. Не раздуваем контекст основного агента 2. Даем GPT модельке пользоваться инструментами из интерфейса, под который она изначально заточена

Все это заворачиваем в SKILL, добавляем всякие доп инструкции (в каких ветках работать, как тестировать и т.д.). Получается вполне рабочий инструмент, через который удаленно внедрять небольшие фиксы в пет-проектах.

Полный текст скилла (разумеется, вместо Codex можно использовать Claude или другие аналоги): --- name: codex-interactive-defaults description: Standard launch and delivery policy for interactive Codex CLI sessions in OpenClaw. Use whenever running Codex interactively (single task or multi-turn coding), to keep output compact, force GPT-5.4 with high reasoning effort, and default repository work to dedicated branch plus final PR. ---

# Codex Interactive Defaults

## Launch Policy (Always Apply)

For every **interactive** Codex run, launch Codex with this baseline:

```bash codex --no-alt-screen --model gpt-5.4 \ -c model_reasoning_effort="high" \ -c hide_agent_reasoning=true \ -c model_reasoning_summary="none" \ -c model_verbosity="low" ```

## Required Constraints

- Pin model to `gpt-5.4` by default. - Set `model_reasoning_effort="high"` by default (highest documented effort level). - Override model/reasoning only when the user explicitly asks for a different setup. - Keep `pty:true` when starting Codex from OpenClaw `exec`.

## Git Workflow Defaults (Branch + PR)

For repository-backed coding tasks, use this as default workflow unless the user explicitly says otherwise:

1. Create/switch to a dedicated branch **before** implementing changes. 2. Do not implement changes directly on `main`/`master`. 3. Implement and commit changes on that branch. 4. Push branch and open a PR. 5. Report the PR URL in the final update.

If branch push/PR creation is blocked by missing remote/auth/permissions, still complete branch + commits and report the exact next commands needed to open the PR.

## Prompting Rule (Mandatory)

When sending a coding prompt to Codex for repository-backed work, explicitly include both instructions below in the prompt text:

1. **Start on a new branch first** (create/switch branch before any edits). 2. **Finish with a PR** (push branch and return PR URL, or provide exact next commands if PR cannot be opened automatically).

Use explicit wording in the prompt (do not assume defaults are enough). Example phrase to include:

- "Before making any code changes, create and switch to a new branch for this task. Do not work on main/master. After implementing, push the branch and open a PR, then return the PR URL."

## OpenClaw Execution Pattern

1. Prepare working directory (often temp + `git init` for scratch work). 2. For repo-backed tasks, create/switch to a dedicated working branch. 3. Start interactive Codex with `pty:true` and the baseline flags above. 4. Use `process` actions (`submit`, `paste`, `send-keys`) for follow-up turns. 5. Finish with pushed branch + PR when repository context allows. 6. Kill/exit session when task is finished.

## Command Templates

### Start session in target directory

```bash # via OpenClaw exec tool command: codex --no-alt-screen --model gpt-5.4 -c model_reasoning_effort="high" -c hide_agent_reasoning=true -c model_reasoning_summary="none" -c model_verbosity="low" pty: true workdir: <target-dir> background: true ```

### Start temp scratch session

```bash TMPDIR=$(mktemp -d /tmp/codex-demo-XXXXXX) cd "$TMPDIR" git init -q codex --no-alt-screen --model gpt-5.4 -c model_reasoning_effort="high" -c hide_agent_reasoning=true -c model_reasoning_summary="none" -c model_verbosity="low" ```

Я ленивый, поэтому настроил себе Todoist MCP с user scope (чтобы Claude Code видел его, независимо от репозитория). Супер интересный экспириенс. Надо будет весь мой #LifeOps переводить на MCP-шки

https://github.com.mcas.ms/greirson/mcp-todoist

P.S. За ссылку большое спасибо Стасу @FactoryDS

P.P.S. Чтобы установить, достаточно клоду кинуть ссылку на репо + токен Todoist, дальше он сам

P.P.P.S. Очевидно, тоже самое можно сделать с любым инструментом для трекинга задач, которым вы пользуетесь, Linear, Jira, Asana, you name it

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

но ничто не кажется таким бесполезным и требующим излишнего внимания, как концепция moats.

и вот очередной тейк на тему “speed the only moat left” заставил накатать это пост.

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

имхо в стартап-мире единственный настоящий moat - это сама неопределенность.

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

формула объясняет стартап-трюизмы типа “великие компании строятся в медвежьих рынках”. повышенная неопределенность дает больше времени на построение защиты.

думаю, что все эти разговоры возникают в свете того, что AI коммерциализируется через b2b saas, где исторически никто не обременял себя такими мыслями. в LLM мире разрывают всех проекты с хорошим интерфейсом, которые стремятся занять дефолтный слой в новом workflow: Cursor, Granola, Lovable.

никаких классических бизнес-moats тут нет. есть вкус и скорость / качество исполнения. свитчнуться с этих инструментов не приятно, но не очень сложно.

и тут мне кажется самый важный фактор в b2b saas - shared beliefs, самый сильный сетевой эффект живущий в интер-субъектинвой реальности.

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

называйте это бренд, комьюнити, религия, или даже, moats. сути не меняет.