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

Проверка, которую агент не может пропустить Готовил доклад про контроль качества в своей фабрике агентов и поймал себя на мысли: самый недооценённый слой в ней — хуки. Про промпты пишут все, про хуки почти никто. Проблема, из которой они выросли. Долго все мои проверки жили в промптах: правила в контексте, субагент-фактчекер, редакторская вычитка. Они работают, но у этого доверия есть слепое пятно: проверка случается, если агент про неё «вспомнил», если правило доехало до контекста. А когда не сработало, узнаёшь уже на вычитке. Хук устроен иначе. Это скрипт, который среда запускает сама на событие. Агент его не вызывает, а значит не может забыть, пропустить или уговорить себя, что в этот раз можно без проверки. Что у меня стоит на хуках: → Записал файл — запустился линтер. Невидимые Unicode-символы, самоидентификация модели в тексте: запись возвращается агенту с текстом ошибки, и он сам переписывает файл. Человека в этом цикле нет вообще. → Завершение хода: анонсировал — приложи. Модель любит написать «запускаю фактчекера» и не запустить: слова есть, работы нет. Хук проверяет, что за словами стоит реальный вызов. → Перед веб-поиском хук сверяется с кэшем исследований. Если то же самое уже искали, агент в сеть не идёт. Это уже не про качество, а про деньги, но механика та же. И одно правило, без которого всё это умирает: при собственном сбое хук обязан пропустить работу дальше и ничего не блокировать. Главное отличие от проверок в промптах сформулирую так: промпт — это просьба, хук — это физика. Раньше на вопрос «а точно ли всё проверилось» отвечала моя вера в процесс. Теперь отвечает сам процесс. #ai_agents #contentops

Дело не в гуманитариях, а в конфигурации задачи. Или размышления о том, как внедрять ИИ в редакциях. Давайте не про агенты, а про процессы. На митапе для редакторов в IT от YADRO я очень коротко рассказывал про то, как улучшить качество материалов, которые мы получаем от ИИ. И сам в процессе понял, что тема интересна даже не механиками, а психологией. Ведь я долго объяснял сопротивление ИИ у редакторов складом ума. Технари любят новое, гуманитарии, коих среди коллег большинство, держатся за ремесло. Удобная рамка, все кивают. Рамка неверная. Я видел, как в её тени принимаются решения: «наймём тех, кто помоложе», «проведём воркшоп, они привыкнут». Не привыкают. Потому что сопротивление растёт не из склада ума, а из конфигурации задачи. Условий три, и у редакторов совпадают все три сразу. Первое. Задача выглядит субъективной Текст — это вкусовщина. Так его видит редактор, и не без оснований: он не может объяснить, почему эта фраза плохая, он её слышит. Там, где нет проверяемого критерия, доверять алгоритму не за что. Нечем поверить его выход. Тут ловушка в слове «выглядит». Внутри редактуры полно вполне объективных кусков: факт сходится с источником или нет, термин единообразен или нет, структура соблюдена или нет. Но они не отделены, поэтому весь процесс окрашивается субъективным. Мы сами склеили проверяемое с непроверяемым и потом удивляемся, что доверие не выдаётся частями. Второе. У человека есть экспертиза именно здесь Десять лет практики, свёрнутые в интуицию. Это капитал, и он работает: редактор правит быстро и точно, не проговаривая ни одного правила. Он же главное препятствие. Эксперт вообще плохо принимает советы, любые, не только машинные. Попробуйте предложить сильному редактору правку от другого сильного редактора И увидите ту же реакцию, что и на нейросеть. Просто человеку мы такое прощаем, а модели нет. Третье. Модель спорит с твоим суждением, а не с чужим Вот это самое недооценённое. Разница между «вот вариант коллеги, сравни со своим» и «вот

«Что сейчас самое лучшее?» — неправильный вопрос Давайте сегодня не про технину и агентов опять. Я начал со сложного и пропустил самое начало, а спрашивают как раз про него. С чего начать, что сейчас на острие, какая модель лучше, пора ли переезжать. Отвечу сначала как спросили. Потом объясню, почему спросили не то. По существу вопроса: берите то, что подходит вам, а не то, что вышло вчера. Инструмент, в котором вы работаете каждый день, окупается не характеристиками, а наработанностью. Вы знаете, где он врёт. Знаете, какая формулировка даёт результат. У вас накопились заготовки, шаблоны, контекст. Это капитал, и переносится он плохо: на новом инструменте вы снова новичок, только теперь с завышенными ожиданиями. Три месяца притирки ради пятнадцати процентов на бенчмарке — плохая сделка. А переезжают именно ради процентов на бенчмарке. Хотя бенчмарк меряет не вашу работу. Модель, которая решает олимпиадную математику, не обязательно держит ваш тон голоса. Победитель агентных задач не обязательно аккуратнее с фактами. Единственный честный тест — десять ваших типовых задач через оба варианта. Вечер работы. А теперь забудьте всё, что я написал выше. Не потому что неправда. Потому что не туда пошли изначально. За вопросом «какую модель взять» почти всегда стоит надежда, что правильный выбор всё решит. Но я пока не видел ни одного случая, когда это срабатывает. Упираются не в модель. Упираются в то, что стандарт не сформулирован: он живёт в голове главреда и достаётся оттуда в режиме «мне не нравится». В то, что источники не описаны и каждый берёт цифры откуда придётся. В то, что никто не знает, где текст проверяется и кем, потому что проверяет его тот, у кого сегодня есть время. Более сильная модель не чинит ни одну из этих вещей. Она делает ровно одно: быстрее производит то, что вы всё равно не умеете принять. Вы получаете больше текста, который некому оценить по критерию, которого нет. Поэтому мой ответ на «с чего начать» звучит скучно. Возьмите то, что уже

Зашли с вопросом про стратегию или концепцию AI-first в контент. Но спросили с пониманием, что это когда в любом процессе буквально сначала ИИ. Сгенерили, потом посмотрели, что вышло. Можно со мной тут поспорить, конечно, но «first» в таких терминах никогда не значило «сначала». Mobile-first — не про то, что мобильную версию рисуют раньше десктопной, а про то, что мобильный экран учитывается в каждом решении. Так же и здесь: AI-first — не порядок шагов, а то, что ИИ встроен во весь процесс, а не стоит отдельным этапом в начале или посередине. Когда ИИ отдельный этап, вы, например, ускоряете написание черновика втрое, но материал упирается в проверку. Текстов стало больше, проверять чужое дороже, чем писать своё, редактор тонет. Локальное ускорение, глобальное замедление — знакомая история же? Когда ИИ встроен, вы смотрите на весь маршрут материала: от идеи до разбора после публикации, и на каждом отрезке спрашиваете, что здесь меняется теперь, когда есть модель. На планировании раньше спорили, какую тему взять: производство стоило дорого, ошибиться было больно. Теперь дешевле накидать три черновика и посмотреть, какой живой, чем неделю обсуждать один. На брифе выясняется, что модель не читает мысли. Приходится проговаривать вслух: что на входе, что на выходе, что считается браком. Побочный эффект: люди тоже начинают понимать задачу с первого раза. По той же причине из головы главреда наконец переезжает в файл редстандарт. Больно, зато у команды появляется общий критерий вместо «мне не нравится». На проверке — главное. Сверить факт с источником, поймать разнобой в терминах, прогнать текст по стандарту: всё это машина делает лучше и дешевле, чем пишет. Но ставят её обычно на написание, потому что генерация эффектнее. И на разборе после публикации: что зашло, что нет, почему. Раньше на это просто не хватало рук. Проверить себя просто: спросите, что у вас изменилось, кроме того, что тексты теперь пишет модель. Если ничего — это не AI-first, а новый инструмент н

Пятничное, отпускное, написанное с телефона. Смотрите: — 1 сентября Anthropic выпускает Claude Fable 5.1 — 2 сентября Google свою очередную Gemini 3.8 Flash, кстати, очень дешевую. — 3 сентября вышла Muse Spark 1.3. Ждем буквально на днях ещё релиз новой модели OpenAI ASTRA и новый Grok 4.7. Конкуренция растет, токены дешевеют. Кажется выиграет сейчас тот, будет быстрее внедрять нужную модель на нужном шаге. Ну и как анонс: сел писать, что я делал в своей системе агентов два месяца. Спойлер: ничего до двух последних дней.

Не давай модели подбирать слова. Заметка для редакторов про метод Птачека Томас Птачек, человек из мира безопасности, написал заметку о том, как он пишет тексты с ИИ. Метод сводится к двум запретам и одному разрешению. Правило первое: ни одного слова, предложенного моделью Обоснование у него любопытное. Модели сверхъестественно хороши в подборе приятных оборотов — это, собственно, их главный навык. Проблема тонкая: модель как будто застряла в режиме, где всё, что она пишет, — заголовок для журнала. Заголовки хороши, но человек, написавший статью из нескольких десятков заголовков, вызывает вопросы. И дальше он предлагает относиться к правилу как к средству индивидуальной защиты: любой конкретный оборот, предложенный моделью, — вне игры, даже если он вам нравится и даже если вы уверены, что он лучше вашего. Логика в том, что вы не сможете надёжно отлавливать все способы, которыми модель превращает текст в нейрослоп. Поэтому запрет тотальный, без исключений на «ну вот тут же правда удачно». Правило второе: никакой похвалы Это он называет более тонкой проблемой — влиянием, а не подстановкой слов. Отдаёте черновик, модель отвечает, что это золото. А в первом черновике большинство абзацев плохи, логика скачет и есть лишних слов семьсот пятьдесят. Модель одобряет структуру, потом абзацы и переходы, потом выбор слов, метафоры, отсылки. В результате вы укрепляетесь во всех импульсах первого черновика, хотя обычно поступили бы иначе: переписали бы, передумали, заменили абзацы. Именно эти передумывания — основа для вашего голоса. Читатель не поймёт, что не так, но почувствует искусственный привкус. Обходной приём у него был такой: пару лет он открывал каждый промпт враньём. Помогает, но модель обычно начинает подгонять свои выводы под «цели». Так что нынешний совет проще: запретить похвалу прямым текстом и оставаться начеку. Что модели разрешено Тут всё про усталость. Ошибки можно ловить и вручную, но это утомительная работа, а модель не устаёт. Отсюда список: пере