Инженер Контекста

Anthropic выпустила Claude Fable 5. И это, возможно, самый необычный релиз ИИ за последние годы. Не потому что модель показала рекордные цифры в бенчмарках. И не потому что она якобы приблизилась к AGI. А потому что впервые главный маркетинговый тезис звучит так:

Наша лучшая модель слишком опасна для публичного доступа.

Вместе с Fable 5 компания представила Mythos 5 — внутреннюю модель, доступ к которой ограничен из-за её возможностей в чувствительных областях вроде кибербезопасности. При этом Fable 5 построен на той же архитектуре. То есть вся презентация сводится к довольно необычной идее:

Вот наша самая мощная модель.

Но пользоваться вы будете не ей.

Если раньше AI-компании соревновались в том, кто покажет более высокий результат на очередном бенчмарке, то теперь соревнование переходит в другую плоскость. Не «насколько умна модель», а «насколько опасной мы считаем собственную модель». И это довольно интересный сдвиг. Последние два года индустрия продавала интеллект. Сначала были задачи уровня школьных олимпиад. Потом исследования. Потом агентность. Теперь в качестве конкурентного преимущества начинают продавать ограничения. Фактически Anthropic говорит рынку:

Мы сделали модель настолько сильной, что вынуждены ограничивать доступ к ней.

Для компании это почти идеальная маркетинговая позиция. Особенно забавно выглядит появление двух уровней доступа к интеллекту. Раньше различия были простыми: бесплатная версия и платная версия. Теперь появляется новая категория: — версия для всех; — версия, которой вам не доверяют пользоваться. И мне кажется, что именно это главный итог релиза. Не очередной рост качества на несколько процентов, а начало эпохи, где ИИ-компании будут конкурировать не только мощностью моделей, но и правом доступа к ним. Потому что если такой подход взлетит, через пару лет вопрос будет звучать не «какую модель ты используешь?», а «какой у тебя уровень допуска к модели?». #ai

Так я вижу Code и Codex порой.

У меня было 119 коммитов, 30 слитых пулл-реквестов, 38 104 добавленных строки и целая россыпь файлов всех сортов и расцветок — 7 новых субагентов, модуль клиентских кейсов, 11 правил редполитики, 13 скриптов-валидаторов и 10 тестов. Не то чтобы всё это было нужно на выходных. Но если уж начал докручивать систему агентов, то к делу надо подходить серьёзно.

Ну или мемов вам накидать.

Как я превращал свалку заметок в библиотеку для ИИ-агентов База растёт сама из работы над контентом. Под каждый материал агент сначала делает исследование: идёт в веб, собирает данные, цифры, источники. Конспект сразу сохраняется в research/ под конкретную статью — это страховка от потери данных, если сессия оборвётся. Важный момент: исследование сохраняется автоматически, ещё до того, как автор начал писать. Дальше срабатывает правило: перед новым ресёрчем агент обязан проверить, что уже собрано. Если по теме что-то есть, он это дополняет, а не пересобирает с нуля. А самое ценное и многоразовое из разовых исследований переезжает в постоянную базу. Так разовый сбор под одну статью со временем превращается в библиотеку, которой пользуются все агенты. Звучит красиво, но было три проблемы: — агент порой не знал, что в базе уже есть инфа, и искал заново; — мог взять устаревшую цифру, потому что никто не помечал, когда факт «протух»; — в документации написано «агент смотрит в базу», а в коде этого нет. Слои: от свалки к полкам Факты хранятся по-разному, в зависимости от роли. Большие документы разбил на атомарные карточки: — fact-card — один проверяемый факт = одна карточка. С источником, уровнем доверия и сроком годности. — case-card — один публичный кейс клиента, и что про него говорить нельзя. — objections — карточка возражения («облако дороже») с готовым безопасным ответом. — personas — карточки аудиторий: боли, KPI, запретные углы. Зачем дробить? Большой текст легко выдаёт лишнее — непубличную деталь или старую цифру. Атомарная карточка хранит ровно один факт. Просрочилась — система сама её отложит. Интеграции: появился библиотекарь Полки — это полдела. Дальше нужен тот, кто приносит нужное: — Картотека плюс ретривер в коде: даёшь тему — получаешь короткий список релевантных карточек, просроченные помечены. — Компактная коробка вместо всей базы. Агенту едет не дамп на пол-базы, а ровно: свежие факты, публичные кейсы, и список того, чего в базе нет. Просроченное — отдельной стопкой, в текст не попадёт. — У каждого типа задач своя карта. Не «загляни в базу», а «для пресс-релиза бери позиционирование и публичные кейсы, а конфиденциальные числа только после проверки». — Починил пайплайн. Шаги, которые раньше были красивым описанием, заработали: повторный фактчек сомнительных цифр реально запускается, а 19 ресёрчеров наконец получили веб-поиск, которым «просили» пользоваться. Предохранитель на финале Последний шаг любого пайплайна — редактор. Берёт только разрешённые к публикации карточки, а просроченные не пускает в текст. И всё закреплено тестами: рассинхрон «база — агент» теперь роняет сборку. Что в итоге Конечно, это не очень обязательный элемент фабрики контента. В воркфлоу записано, что надо найти, передать, написать, проверить. Всё в чистом контексте и галлюцинаций в финале не остаётся. Но каждый запрос это токены и время. И деньги. А запросы повторяются, в конце концов мы крутимся вокруг одних и тех же цифр исследований, бенчмарков, фактов. Поэтому постепенно наполнять базу знаний и оперативно обращаться к ней кажется не такой уж плохой идеей. Стоит потратить на реализацию несколько вечеров. #ai_agents

На выходных нашёл статью про то, что давно крутилось в голове. Про петли обратной связи в агентах Под «петлёй» имеется в виду контур обратной связи — замкнутый цикл, где результат работы агента кто-то или что-то измеряет, и это измерение возвращается обратно и меняет поведение системы. Не «модель стала умнее», а «вокруг модели крутится цикл: сделал → измерили → подправили → снова сделал». В пост сюда объёмом не уложился, так что опубликовал на Хабре. #ai_agents #habr

Звёздная гонка ИИ-агентов в мае 2026 Наткнулся на свежий разбор от Rost Glukhov, он 21 мая выгрузил через API число звёзд у 20 самых популярных опенсорсных фреймворков для агентов. Что по цифрам: → OpenClaw — 373 тыс. звёзд. В апреле обогнал React и стал самым «звёздным» репозиторием в истории GitHub. Тот самый агент Штайнбергера, который живёт на твоём железе и общается через мессенджеры. Ритм — 62 релиза за месяц, по одному каждые 12 часов. → Hermes Agent от Nous Research — 160 тыс. за 12 недель. Растёт быстрее в неделю, чем OpenClaw в том же возрасте. Держит память между сессиями и сам пишет файлы навыков из успешных задач. → Середина таблицы спрессована между 26 и 43 тыс. — там позиции тасуются за сутки от одного поста на HN: Nanobot (Python, ~4 тыс. строк кода, от лаборатории HKU), AstrBot (самый активный по релизам), PicoClaw (Go, под встраиваемые устройства от Sipeed), AionUi (TypeScript, агентный UI) и ZeroClaw на Rust. Что мне было интересно из выводов автора: Во-первых, релизы и звёзды почти не коррелируют. OpenClaw выкатывает 62 релиза в месяц, а пара проектов с десятками тысяч звёзд — ноль. Во-вторых — и это главное — звёзды измеряют любопытство, а не использование. Что люди реально запускают, показывают токены на OpenRouter, загрузки npm/PyPI и история CVE, а не счётчик в углу репозитория. Звезда стоит один клик; она не значит, что софт хоть раз запустили в проде. Полезное напоминание перед тем, как в следующий раз выбирать стек по «самому популярному на гитхабе». Оригинал и полный датасет: glukhov.org #ai_agents

Так себя и ощущаю

ИИ не заменил менеджеров. Он сделал их узким местом Картинка из моей работы. Облачная конференция, сессии наших спикеров на других ивентах, лендинги, статьи в СМИ и блог, Хабр. При производстве практически каждой единицы контента используется ИИ — целая фабрика агентов. Но между ИИ и готовым результатом есть человек, в данном случая я. Человек смотрит, проверяет, принимает решение. И этот ресурс ничем не масштабируется. И это не то, чтобы только у меня подгорает. На прошлой неделе в HBR вышел материал Managers Are Struggling to Keep Up with the AI Productivity Boom. Открывается цитатой менеджера: "каждые тридцать минут кто-то создаёт что-то, что я должен посмотреть". CIO в свежей колонке формулирует ещё жёстче: исполнение перестаёт быть ограничением, дефицитным ресурсом становится суждение. Производство чего либо-ускорилось в разы. Но при этом никто не перестраивает поток работы под ИИ, практически всегда остаются те же цепочки согласований, что были до. Опять вернусь к своему опыту. Когда ревьюишь черновик от человека, то ловишь опечатки и логику. Когда ревьюишь то, что выдала модель — проверяешь каждый факт, каждую формулировку, каждую цифру. Ошибки модели уверенные, гладкие, правдоподобные, их не отловить, читая по-диагонали. ИИ снимает нагрузку с генерации и нагружает верификацию. Инженеры в опросах напрямую отвечают: проверять AI-код тяжелее, чем писать с нуля. Короче, производство ускорили на порядок, а пропускную способность решений — процентов на двадцать. Разница оседает у тебя на столе. И, надо признать, в этом нет ничьего злого умысла. Просто индустрия выкатила инструмент, который сжимает один этап цепи, и почему-то решила, что от этого ускорилась вся цепь. Не ускорилась. Узкое место мигрировало. Сейчас оно сидит на менеджерском стуле и проверяет то, что выдала модель. 💡Что могу посоветовать. «Делегируйте больше», «фокусируйтесь на главном», «приоритизируйте» — это всё сработает только, если у вас есть большая команда. Первое — перенести принятие решений из своей головы в артефакты. Если ты ревьюишь каждый текст как индивидуальный кейс, ты держишь критерии в рабочей памяти и тратишь её на каждой итерации заново. Если эти же критерии оформлены как явный чек-лист, гайдлайн, или, в случае Claude Code, как скилл — половина решений принимается до того, как текст дошёл до тебя. Второе — поменять метрику собственной нагрузки. Для контент-менеджера, например, это значит перестать мерить себя «количеством опубликованного» и начать мерить «сколько решений приняли за день» и «сколько из них пришлось переоткрывать». Это звучит абстрактно, но это единственная метрика, которая показывает, упёрся ли ты в производство (масштабируется ИИ) или в суждение (не масштабируется). Третье — называть проблему вслух перед руководством. Не как жалобу, а как операционную диагностику: «У нас не дефицит производства, у нас дефицит пропускной способности решений. Можем обсудить, как её расширить — либо новый сотрудник с делегированной зоной ответственности, либо перенос части решений в политику агента». Четвёртое — признать, что часть решений можно не принимать. Самое тяжёлое — это решения о пограничных кейсах, которые на самом деле не пограничные, а просто непривычные. Например, для контента: есть устоявшаяся редполитика и агент с явными правилами может выкатывать большую часть текстов в публикацию практически без ревью. А человек будет проверять только то, что реально спорно. Это страшно, кажется, что качество упадёт. Но на практике у команд, которые так сделали, качество не падает, потому что вариативность снижается. А время освобождается. Но страшно и есть риски для бренда. #ai

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

Звериный оскал ИИ Кажется таких чудных вакансий (Юля, спасибо за наводку) ближайшее время нас ждет все больше. В ней прекрасно примерно все: - паши один, весь комплекс маркетинга и пиар делай в одиночку в обнимку с ИИ (без подключения ИТ), но с KPI по продажам. - в прямом подченении коммерческому (правда его мы тоже ищем) и доступом к акционеру - нам 30 лет, маркетинга и пиар у нас все это время не было как класс, но мы хотим мидла из ит или финтеха, который сделает нам data-driven и AI-native систему - скока денег платить хотим не скажем Такое ощущение, что собственник сходил на все конфы по ии, послушал маркетинговых обещаний AI-бигтеха, записал умные слова и запихнул это все в вакансию. Но проблема даже не в этом. Вполне вероятно, что они найдут какого-нить молодого амбициозного мидла, который возможно даже что-то построит. Есть другая сторона, о которой такой бизнес не думает - безопасность 1️⃣ Чтобы ИИ-инструменты работали на нужном уровне за них надо платить. Причем, чтобы бы информацмя была во внутреннем контуре - платить дорого. И еще не известно, что обойдется дешевли - люди или ИИ. 2️⃣ Зависимость от технологий. Любой сбой полностью останавливает работу целой функции компании. А заодно и смежных. 3️⃣ Зависимость от 1 человека. Даже если все аккаунты в ии-инстнументах будут куплены на фирму (что вообще не факт, многое официально не купить) и не уйдут вместе с человеком, то процесс все равно встанет, т.к. носитель знаний ушел. Т.е в попытке сэкономить бизнес ставится в неустойчивое положение и весьма вероятно без сокращения расходов. Вот такие пироги

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

Предупреждать надо

DOOM жив! Субботнее залипалово про одну из самых важных и страшних в моей жизни игр. Помню как мы мелкими сидели на табуретках перед монитором и адски боялись... такого накала была игра. DOOM: изучил код и историю - помер от зависти

Недавно рассказывал про компакцию контекста и порог в 85% и получил вопрос: "а как это применять в обычном чат-боте, не в Claude Code?" Сначала теория:

Компакция — это механизм управления контекстным окном когда оно заполняется. Модель не может держать бесконечную историю разговора, у неё есть лимит токенов. Когда этот лимит приближается, система автоматически сжимает старые части разговора: заменяет подробную историю переписки кратким резюме, убирает промежуточные шаги, оставляет только суть. Цель — освободить место для новых сообщений не теряя общего контекста задачи. Проблема в том что алгоритм компакции не знает что для тебя важно: он удаляет «старое» — а вместе с ним могут уйти ключевые решения, согласованный голос, верифицированные источники. Поэтому важно либо управлять этим вручную, либо явно указывать что должно выжить при сжатии.

Так вот: автоматики в обычном чате нет, как нет настроек порога, нет хуков, нет офлоада. Но проблема та же: контекст заполняется, модель начинает «забывать» что было в начале разговора. Особенно заметно, когда работаешь с длинными редакционными сессиями, разбираешь большие тексты или итерируешь статью в несколько заходов. Решение — делать компакцию контента ручками: Каждые 15-20 сообщений просишь модель сделать конспект: что решили, какой голос выбран, какие источники использованы, что осталось. Копируешь. Открываешь новый чат. Первое сообщение — этот конспект. Контекст свежий, все договорённости сохранены.

Сделай конспект нашего разговора для продолжения в новой сессии.
Включи: задачу, согласованные решения, использованные источники,
текущий статус, следующий шаг.
Не включай историю переписки и отклонённые варианты.
До 300 слов, сплошным текстом.

Не вставлять большие тексты целиком. Нужно разобрать длинный материал, давай резюме и говори «полный текст у меня есть, спроси конкретную часть когда нужно». Это ручная реализация того же принципа: в контексте только то что нужно прямо сейчас. Системный промпт с якорями. Если работаешь через API или Projects — добавь в системный промпт что критично удерживать: голос, редполитику, запрещённые слова. Это не компакция, но снижает риск что важное потеряется при длинном разговоре. #ai_prompts #ai

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

⚡️ Вести с полей ЦИПРа Сегодня, когда обсуждали влияние ИИ на бизнес, всплыла такая тема: нужно ли вводить в штатное расписание новую роль — ИИ-директора. Потому что ИИ — это уже не ИТ-задача. Это вопрос стратегии, процессов, экономики и организационной модели компании. Компаниям нужен тот, кто свяжет бизнес, данные, инфраструктуру и реальные бизнес-метрики. Эдакий переводчик между бизнесом и ИТ-отделом. Тот, кто будет отвечать не за эксперименты, а за масштабирование эффекта. Или не нужен? И уметь использовать ИИ должны абсолютно все сотрудники на любых уровнях? Вот как считает Дмитрий Лазаренко, руководитель направления облачных сервисов VK Tech.👇

А нужен ли отдельный директор по ИИ?

И пишите коммиты правильно!

О пользе логов В моей системе агентов после генерации практически каждого материала остаётся отчёт: какие факты переделывались, какие источники подтянулись и тд. И вот в ожидании своего рейса обратно в Калининград в пятницу вечером я сел изучать эти отчёты и вносить изменения. В первой части (будет и вторая про изменения в воркфлоу) расскажу про галлюцинации и как я стараюсь их сократить ещё на этапе написания, а не проверки. Например, обнаружилось, что 5 из 6 явных выдуманных фактов были в темах кибербезопасности. Покопавшись в отчётах, понял — субагент-автор охотно берёт цифры из агрегаторов и кладёт в текст без проверки первоисточника. Для кибербеза такое, конечно, совсем моветон. Что изменил для всех агентов: Атрибуция источников. Полная атрибуция теперь = первоисточник + год + ФИО/должность/компания + URL. Чёрный список вводных: «по данным экспертов», «исследования показывают», «по оценкам аналитиков» — без конкретики не принимается. Запрет на цифры из агрегаторов без раскрытия первоисточника. Проверка текущей должности спикера (а не прошлогодней). Доменное правило для ИБ — белый список и чёрный список агрегаторов. Правило подключается по триггерам (атака, ransomware, утечка, CVE, 152-ФЗ). Чек-лист фактчекера на статус ransomware-групп и актуальность регуляторики. Свежесть данных по типам. Жёсткие лимиты: рынок — 12 месяцев, MAU — 6, GitHub stars — 3, статус ransomware-группы — 6. Обязательная пометка года для цифр старше года. Запрос WebSearch с явным указанием года в строке. Через месяц-два повторю ревью и посмотрю, изменилась ли частота неверной атрибуции. Если правила за месяц не упоминаются ни в одном отчёте — значит, не срабатывают на этапе написания текста, переформулирую, доработаю. #ai_agents