Ещё обновил 95% всех своих SKILL-s под Opus 5 Официальный migration guide Anthropic прямо указывает:

старые инструкции по верификации и пошаговые процедуры, написанные для Opus 4.x, могут ухудшать качество вывода на новых моделях, потому что модель теперь справляется с этим сама. Это не гипотеза и не маркетинг сторонних блогов — формулировка взята из раздела "Recommended changes" официального migration guide.

У меня в PersonalOS = 198 скиллов, 185 скиллов попало под апдейт. Выявленные legacy-паттерны: 1. Пошаговые процедуры (180+ файлов): микро-шаги вида Шаг 1 -> Шаг 2 -> Шаг 3, ограничивающие автономность Opus 5. 2. Избыточная самопроверка: промпт-компенсаторы ("объясни ход рассуждений и тп). 3. Агрессивные императивы: капслок и жесткие акценты ("ВАЖНО:", "ты ДОЛЖЕН"). 4. Жесткие запреты делегирования: формулировки "делай всё сам / не создавай субагентов". и т.п. Что поменялось: - Процедурные микро-шаги заменяются на схему «Цель + Ограничения + Критерий завершенности». - Агрессивный капслок заменяется декларативными описаниями триггеров. - Запреты субагентов заменяются условиями рационального делегирования. - Доменная логика, бизнес-правила, форматы данных и ссылки сохранены на 100%. - Удаление императивов и давления: формулировки ВАЖНО: ты ДОЛЖЕН... - Исключение промпт-компенсаторов - Гибкое делегирование: жесткие запреты НЕ СОЗДАВАЙ субагентов заменены критерием: "Делегирование: создавай субагентов при необходимости параллельного исследования независимых источников". - Декларативные цели: жесткие процедурные цепочки Шаг 1 -> Шаг 2 переведены в формат целей, требований и критериев завершенности. Промпт для агента

Задача: аудит и переписывание всех скиллов в папке под новую модель (Opus 5, было Opus 4.x). Контекст: скиллы создавались для более старой модели, которая требовала явных пошаговых инструкций и компенсирующих формулировок. Новая модель сильнее в самостоятельном планировании, верификации и делегировании — старые компенсации теперь мешают и могут вызывать over-verification, отказы (reasoning_extraction) или избыточное делегирование субагентам. Шаг 1. Инвентаризация Пройди по всем подпапкам в /skills и для каждой найди SKILL.md. Составь список: путь к файлу, размер, дата последнего изменения. Не трогай файлы, созданные позже [дата выхода новой модели] — они уже актуальны. Шаг 2. Grep-аудит триггерных фраз В каждом SKILL.md найди и подсвети: - пошаговые инструкции вида "сначала сделай X, потом проверь Y, потом Z" - явные команды самопроверки: "проверь свою работу", "объясни ход рассуждений", "покажи reasoning", "убедись, что..." - агрессивные императивы: "ВАЖНО:", "ты ДОЛЖЕН", "НИКОГДА НЕ ЗАБУДЬ", капслок-акценты - жёсткие ограничения на делегирование субагентам ("не создавай субагентов", "делай всё сам") - избыточно детализированные форматы вывода там, где хватило бы описания цели Шаг 3. Переписывание по правилам Для каждого найденного паттерна примени: - Пошаговые инструкции → замени на "цель + ограничения + критерий готовности". Убери промежуточные шаги, которые модель может спланировать сама. - Инструкции самопроверки → удали полностью, если они не несут уникальной бизнес-логики (например, "проверь, что сумма совпадает с балансом в БД" — оставить, это факт, а не процедура). - Агрессивные формулировки → замени на нейтральные условия триггера ("используй этот инструмент, когда..."). - Ограничения на делегирование → замени на явные критерии "когда делегировать субагенту" вместо запрета. - Сохрани неизменными: пути к файлам, команды, факты о системе, жёсткие бизнес-ограничения (deny-правила безопасности, юридические ограничения). Шаг 4. Формат вывода Для каждого скилла выведи: 1. Путь к файлу 2. Список найденных проблемных фраз (цитата + причина) 3. Диff: было → стало 4. Итоговую переписанную версию SKILL.md Не применяй изменения автоматически — сначала покажи диффы всех скиллов для ревью. После моего подтверждения — перезапиши файлы. Шаг 5. Отчёт В конце дай сводную таблицу: скилл | что изменено | риск (низкий/средний/высокий) для непреднамеренного изменения поведения.

К Бобу Стернфелсу вопросы у нас есть. Но к тем, кто делает McKinsey Insights — вопросов нет. Они большие молодцы. Поэтому сделал нам дайджест самых их полезных и интересных текстов за июль: 1. Five principles for designing brain-powered organizations С одной стороны, AI вроде бы забирает на себя рутину и простые задачи, с другой — оставляя сотрудникам больше сложных проблем и работы с неопределённостью. То есть повышает когнитивную интенсивность и нагрузку на мозг. И с этим надо что-то делать. McKinsey предлагает пять принципов как стать brain-powered organization: • Во-первых, следить за этой когнитивной нагрузкой • Создавать условия для восстановления • И условия для концентрации • Инвестировать в развитие критического мышления и адаптивности • Проектировать brain-positive среду 2. The operating model advantage: Why AI winners are rewiring their organizations Очередной материал про AI winners — как эти успешные компании трансформируют свою операционную модель. 3. From adoption to impact: Three horizons of AI transformation Про три уровня AI-зрелости: • Enablement — AI помогает отдельным сотрудникам • Automation — AI автоматизирует существующие процессы • Reinvention — компания заново проектирует роли, процессы и операционную модель Только 11% опрошенных руководителей относят свои организации к третьему уровню. 4. Building expertise in the age of AI: Who trains the next generation? Как в условиях AI-трансформации компаниям перепридумывать не только новые рабочие процессы, но и новые траектории формирования экспертизы. 5. The human advantage in an AI economy Транскрипт подкаста про brain capital и почему mental health is an economic imperative. Весьма интересно и познавательно. 6. Is the AI productivity story at a turning point? И ещё один подкаст. Эрик Бриньолфссон объясняет разрыв между огромными инвестициями в AI и пока ограниченным ростом производительности. Для получения эффекта необходимы intangible investments: изменение процессов, структуры работы, навыков и системы стимулов. 7. In an AI-driven world, the fastest learner will win Интервью со Свеном Смитом про assisted intelligence и выстраивание системы организационного обучения. В комментариях переводы всех семи материалов в пдф.

Внятное и лишенное журналистской истеричности и упрощений исследование рынка труда от Revelio Labs демонстрирует справедливость ненавидимой медиа и многими читателями фразы: “все сложно”. Очень хочется простых ответов на классические вопросы “что делать?” и “кто виноват?”, но их, как обычно в жизни случается, просто нет. Видно, что рынок труда меняется, но процессы на нем сложные и разные в разных местах. Июльский AI Labor Market Tracker показывает, например, что спрос на наиболее «AI‑экспонированные» роли упал на 42% относительно менее подверженных автоматизации позиций, но при этом в фирмах‑адоптерах AI общая численность персонала растёт на 27% быстрее, чем у не‑адоптеров — то есть рынок не столько «убивает рабочие места», сколько радикально перераспределяет функции внутри компаний. Страхи и разочарования повлияли и на образование: имеется заметное проседание поступающих на компьютерные науки и ИТ-специальности (минус 28% набора студентов по сравнению с 2022), это происходит одновременно с ростом доли задач в существующих ролях, которые выполняются с участием AI‑инструментов. В практическом смысле это подтверждает картину из более ранних отчётов LinkedIn: вместо классической смены профессий наблюдается рост гибридных позиций, где умение работать с моделями становится базовой грамотностью, а не отдельной профессией. Понимаю, что мой пересказ выглядит мутным, но в данном случае это намеренно: тут надо внимательно читать и думать, а не хвататься за чужие выводы. Потому что, повторюсь, картинка сложная и и ее упрощение просто лишает ее смысла. https://www.reveliolabs.com/ai-labor-market-tracker/us/july-2026

Что случилось с Cursor? Он стал непопулярен? Разбираем 👇 Если коротко, то: нет, скорее изменилась сама экосистема AI-инструментов. В 2024–2025 годах Cursor был практически синонимом AI-кодинга. Если человек хотел попробовать «вайбкодинг», чаще всего он устанавливал именно Cursor. Но за последний год рынок сильно изменился. Во-первых, появился и стремительно вырос Claude Code. Многие разработчики перешли на него из-за более сильных агентных возможностей и удобной работы с большими проектами. Во-вторых, OpenAI активно развивает Codex, GitHub Copilot продолжает занимать корпоративный сегмент, а также появились Windsurf, Kiro, Jules и десятки других решений. Сегодня разработчики уже выбирают не один инструмент, а собирают собственный стек под разные задачи. При этом говорить, что Cursor непопулярен будет тоже некорректно. Многие компании продолжают использовать его параллельно с Claude Code. Например, недавно стало известно, что Disney оставляет Cursor среди основных инструментов разработки наряду с Claude Enterprise, несмотря на отказ от GitHub Copilot. Почему тогда создается ощущение, что про Cursor стали говорить меньше? В 2026 год сменился тренд. Суть тренда в том, что мы выбираем не конкретный редактор, а AI-агента или подборку агентов. Уже не столь важно, где вы будете писать код, поэтому конкретно Cursor обсуждают не так активно. Кстати никогда не спрашивала вас: А вы использовали Cursor?

Про постановку целей по AI в компаниях Часто, когда придумывают какой-то KPI, например повышение AI-зрелости, проникновения AI или экономических эффектов, в итоговую цель ложится что-то типа «повысить на 50%» или «достичь уровня 80%». Все такие формулировки неизменно вызывают много дискуссий «а как они решили, что надо именно 80, а не 70 или 90?», поэтому пара слов об этом. AI характерно то, что итоговый эффект довольно сложно точно предсказать, максимум - по порядку величины и то может оказаться, что его просто не будет. Как следствие, вы всегда ставите цель в условиях сильной неопределенности, и в какой-то момент надо просто решиться, ткнуть пальцем в график и сказать «будет вот так». Ну знаете, как Королев со своим известным «Луна твердая» (там на самом деле была чуть более длинная и менее бескомпромиссная записка, но легенда всегда становится чуть красивее). Что может смягчить для руководителя и компании последствия такого «тычка пальцем в небо» при планировании? Несколько вещей: 1. Оценивайте результат и уточняйте план чаще, чем раз в год. 2. Берите как руководитель ответственность за тот план, который сами поставили. И когда ставите цель себе, и когда ставите цели своим сотрудникам. Та же байка про Королева ведь не про гениальность и авторитарность великого, а именно про способность взять на себя ответственность. 3. Лучше сначала определитесь со способом измерения и проведите замер, что есть сейчас, чтобы потом не натягивать сову на глобус, подгоняя оценки под то, что вышло. 4. Ищите баланс между микроменеджментом и стратегичным стратегированием с отрывом от реальности: погружайтесь вглубь, чтобы не было чайка-менеджмента и форвард-менеджмента, но видьте границы ответственности. Последнее о том, что ошибиться с планом и посидеть без премии это ок, а «всех разогнать нафиг» это не ок. Если не нравится точность планирования - надо улучшать ее, а не крушить и ломать :) Не должно быть какого-то гнетущего эмоционального давления или чувства вины за неудачу, должен быть здоровый азарт - сделал ставку, пробуешь оправдать, не оправдал - что-то потерял, но не так чтобы руки дальше опускались, пробуем еще и еще. В AI это очень важно, потому что страх сильно влияет на проактивность и взятие на себя ответственности в интеллектуальной работе, где нельзя предсказать результат работы точно. 5. Самое важное: всегда, особенно при недостижении каких-то результатов, ищите возможность не поскорее найти виноватых и кого-нибудь наказать, а понять и вместе с командой придумать, как в следующем временном интервале сделать лучше. При этом терпилой быть не надо, если систематически ставите вместе с человеком цели и систематически их не достигаете, возможно вам обоим нужно поработать с кем-то другим.

Борис из Claude Code на YC Startup School рассказывал, что они сократили системный промпт на 80%. Размышлял, почему у них так, но у нас не особо: 1) Anthropic тренирует модели на трейсах claude code, и имхо модель лучше научается оперировать тулами для разных задач —> следовательно, не нужно особо расписывать в системном промпте 2) Но не на «энаших пайплайнах, поэтому мы так вот запросто не можем модель из коробки юзать, особенно если задачи некодинговые и тулы нестандартные. 3) По моим наблюдениям, действительно модели лучше справляются с задачами с более абстрактной - цель, а не способ достижения оной - постановкой НО зачастую это сжирает больше токенов и замедляет процесс. А у вас как: удается ли так лихо резать системный промпт как проповедуют?

Ouroboros теперь SOTA на Terminal Bench, OSWorld и CL-bench Мой любимый агентный луп на чистом питоне доэволюционорал до состояния лучшего харнесса для кодинга! На главных бенчмарках он теперь обходит Codex, Claude code, Cursor и Hermes. Выходит, что в рисёрче, в computer use, в работе через терминал и в задачах на кодинг — уроборос сейчас является лучшим агентом. Так что с этого момента всю разработку и исследования я веду только через уробороса. Для полной воспроизводимости результатов. Весь код, скрипты, трейсы я выложил в открытый доступ. Напоминаю: лицензия MIT. Так что спокойно ломайте, форкайте, проверяйте трейсы, пишите что я где наврал. И кидайте issues и PR-ы! Все постараемся с уроборосом принять😋 P.S. Кошмар какие дорогие агентные бенчи. Прогнать весь набор стоит как квартиру купить (это не шутка!!) GitHub, Хабр, установочники