Claude

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

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

- Собираем отклики в 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

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

Осенью 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? Или как исполнение музыки?

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

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

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

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

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

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

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

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

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

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

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

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

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

[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, даунгрейднуюсь в первый день

Небольшой лайфак как повысить эффективность кодинга у 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

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

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

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

Вы удивитесь, насколько хорошие предложения он даст. Часть из них (или все) стоит попросить его сразу внести в скилл.

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

#ai #claude #productivity

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

Вышло новое интервью с CEO Anthropic Dario Amodei у Dwarkesh Patel.

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

https://youtu.be/n1E9IZfvGMA?si=kRnFSJx4G7WYGolt

Интересно наблюдать, как CEO Anthropic уверенно говорит, что AGI уже практически за углом (2-3 года), в то время как Dwarkesh ставит это под сомнение. Аргументы с обеих сторон — стоит послушать.

Но ещё интереснее — исследование, на которое они ссылаются:

https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

Разработчики были уверены, что AI увеличивает их продуктивность на ~24%. После эксперимента они по-прежнему считали, что AI помог им на ~20%.

Реальность: продуктивность снизилась на 19%.

Парадокс знакомый. Я тоже уверен, что делаю больше с AI. Но за компьютером сижу не меньше, а больше — как наркоман. Возможности делать что-то быстрее превращаются в возможности делать больше, а не работать меньше.

#ai #anthropic #productivity

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

🤗Claude Opus 4.5

Вайбкодинг-стрим через 20 минут

https://youtube.com/live/mSzIeF8rr3c

👇 По традиции, промпты и вопросы в комментарии

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

Некий Сэмми скучал дома и решил в качестве эксперимента подключить контроллер от PS5 к своему роботу-пылесосу DJI Romo. Как любой уважающий себя современный инженер, разбираться с подключением он не стал и поручил это Клоду. Клод попыхтел-попыхтел и отчитался, что работа выполнена — Сэмми теперь может управлять своим пылесосом.

Своим и ещё примерно семью тысячами чужих.

В процессе выяснилось, что подключение к облаку DJI устроено так, что один валидный токен от своего устройства мог давать доступ к чужим: управлению, карте дома, телеметрии и видео/аудио с камер и микрофонов. По заявлению DJI, это была ошибка проверки прав в MQTT-коммуникации между устройством и сервером (видимо, сервер проверял только наличие валидного токена, а не то, для какого устройства этот токен выдан). Так что история, скорее, не про хакерские способности Клода, а про уровень надёжности всех этих ваших умных домов.

Сэмми оперативно сообщил об этом в DJI (а заодно и паре журналистов) — дыру, как утверждают, сразу закрыли.

Сэмми-то молодец и уязвимостью во вред не воспользовался, но интересно, сколько таких случаев будет в ближайшие месяцы и годы, когда “повезёт” людям менее обременённым моралью. Вспоминается цитата из “Дозоров” Лукьяненко: — Если все люди станут магами… Сегодня тебе в трамвае нахамят, а завтра — испепелят на месте. Сегодня неприятному соседу дверь гвоздиком поцарапают или анонимку в налоговую напишут, а завтра порчу напустят или кровь высосут.

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

Люблю периодически у Claude Code запрашивать фидбек о наших сессиях через команду /insights. Кстати, это очень крутая фича, которая позволяет качественно улучшить процесс вайб-кодинга.

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

мне надоело платить 200$/мес за gpt pro и я построил своего агента для deep research (делюсь с вами кодом)

gpt pro даёт мощную глубину — модель реально копает тему заходами по 30 минут. но ты не контролируешь сам рисёрч: откуда она берёт данные, как фильтрует источники, почему решила что этот сайт достоверный. она постоянно тащит SEO-мусор и AI-слоп, но на это трудно повлиять

стандартная история — это репорты, где он пишет про «самые актуальные модели — sonnet 3.5 и gpt-4o», хотя к тому моменту модели сменились раз 5. в современном мире это непозволительно. я собрал вместо этого свой дип рисерч над claude code

мой пайплайн — 5 шагов: — декомпозиция темы на ~8 аспектов через разные призмы (who, what, so what, avoid) — параллельный рисёрч каждого аспекта агентами — синтез находок — red team — а что если всё это буллшит? проверка предположений с обратной стороны — упаковка финальный отчёт

оркестрацией шагов занимается мой фреймворк — claude-pipe. плюс у меня есть мой личный slop-checker skill, который фильтрует источники по критериям.

каждый шаг — отдельный агент со своими инструкциями. не один промпт на всё, а конвейер где каждый этап проверяет предыдущий. одно исследование обходится в ~$1 через exa. значительно шире и глубже, чем gpt pro

выложил на гитхаб, просто дайте ссылку на него своему claude code / openclaw: github.com/bluzir/claude-pipe/tree/master/examples/research-pipeline

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