В порядке бреда — продолжением этого будет content sec ops. Что-то про безопасность производимого контента.
prproIT | Про технологии, софт, блокчейн, веб-сервисы и интернет
CategoryOtherLanguageRUFirst seenJul 06, 2026QualityVerified
Subscribers854
Avg views123
ERR14.4%
Price-- RUB
Price / subscriber--
Price / view--
Metrics updated: Jul 07, 2026
Recent posts
Про новый Content Ops и почему через полгода хвастаться «фабрикой контента» станет стыдно «Мы автоматизировали продакшн», «агенты сами пишут релизы», «редактор нажимает одну кнопку». Пол-ленты про это. Прогноз от меня простой. Через полгода это будет гигиена, а не достижение. Генерить объём научатся все, а значит, объём окончательно перестанет что-либо стоить. Дальше все повернутся к content ops. Термин content ops придумали не вчера. В оборот он вошёл в конце 2010-х и собран по прямой аналогии с DevOps. По сути это маркетинговая дисциплина. Люди, процессы, технологии, чтобы эффективно производить контент. Воркфлоу, CMS, согласования, календарь. Старый content ops оптимизировал производство. Но это больше не узкое место. И тут стоит сказать, что content ops назван по аналогии с devops, сами механики devops — версии, CI, откаты, мониторинг — к контенту по-настоящему не прикладывались. Не к чему было. Текст — не код. Теперь — код. Скилл агента это буквально код: он дрейфует, деградирует, ломается на регрессиях. Вчера писал в голосе, сегодня сползает в канцелярит. Факты галлюцинируют, модель уверенно ставит цифру, которой нет. Нужен слой проверки, как CI, только для фактуры. И появляется полноценный content ops с позицией инженера content ops — опыт редактора плюс владение пайплайном. Почему будущее там, а не в промпт-инженерах Промпт-инженер — это про «как попросить модель». Навык. Он встроится в редактора за квартал и перестанет быть профессией. Сейчас учить людей правильным промптам уже кажется устаревшим навыком. Content ops в новом смысле — это про «как держать систему из моделей, людей и стандартов, чтобы она не разваливалась и ей можно было доверять». Слово есть. Но курсов под эту новую задачу нет. Консенсуса, что это вообще другая работа, тоже пока нет. Ровно поэтому туда и стоит смотреть. Все смотрят на генерацию, а на эксплуатацию не смотрит почти никто. А выигрывает всегда эксплуатация. Что изменится внутри самой редакции Напишу так: мне кажется, что уходить в контентпосера не должны все редакторы и контент-менеджеры. Это отдельная позиция, в которую будет расти кто-то внутри или на которую будут брать человека. Если редактор перестанет править тексты и начнёт править систему, то он потеряет в эффективности. Поправить абзац руками быстро, но завтра агент сделает так же снова. Поправить скилл — инвестиция: чинишь причину, а не симптом. То есть в моём понимание над редакцией должен появиться человек, который наблюдает за процессами и чинит ошибки. Более того, у контента появится техдолг. Зоопарк агентов и скиллов от различных команд и коллег копится, они начинают противоречить друг другу. Никто уже не помнит, зачем это правило и можно ли его снять. Редакции впервые получат то, что раньше было головной болью только разработчиков. И эту проблему нужно закрывать уже сейчас, должна быть единая функция и точка входа и выхода. Вот такой прогноз. Что скажете, коллеги? #ai
Про контроль качества контента с помощью скриптов на GitHub Или как контентщику использовать инструменты разрабов. Вводные: агенты у меня сейчас живут в GitHub и запускаются из Code или Codex (в работе их миграция в различные окружения, но пока так). Качество генерируемых текстов я контролировал через промпты и агенты проверки: правила в контексте, отдельный субагент-фактчекер, редакторская вычитка. Я им доверял и, в общем, не зря, они ловят многое. Но у этого доверия есть слепое пятно. Всё это живёт внутри сессии. Проверка случается, если агент про неё "вспомнил", если правило доехало в контекст. А когда что-то из этого не сработало, то ты узнаёшь об осечке уже когда сам садишься вычитывать. Когда я начал работать над качеством, то первым порывом было докрутить сами промпты в агентах — прописать проверки жёстче. Я сделал и поймал проблему раздувания контекстного окна, но про это в другой раз. Однако, такое решение было лишь дополнением в уже существующий слой: заостряешь проверку и надеешься, что все правила доедут. Стало ясно, что нужен контроль снаружи процесса, а не внутри него. Так появился слой на GitHub Actions. Устроено просто: на каждый сгенерированный материал запускается единая команда make check , за ней — цепочка проверок: тесты, валидация структуры, десятки детекторов на отдельных скриптах. Каждый отвечает за свой сюжет: один считает плотность тире и ищет следы машинного текста, другой сверяет цифры в документации, третий ловит устаревшие данные и битые ссылки, ещё один проверяет, что стадии пайплайна реально шли в изоляции, а не слиплись. Часть проверок работает точечно только по тому, что изменилось. Результат не тонет в логах. Робот оставляет один аккуратный комментарий прямо в задаче и обновляет его на месте, а не плодит новые. Почти все проверки я сделал мягкими: они советуют, но не блокируют, финальное слово за мной. Жёстко останавливает только то, что реально ломает сборку. Логика простая: агентам я по-прежнему доверяю, GitHub не заменил их, а стал вторым контуром. В итоге я перестал держать в голове тревогу «а точно ли всё проверилось». Теперь на это отвечает не моя вера в процесс, а сам процесс. #ai_agents #github
Надо собраться с силами и рассказать, что я там понаписал по агентам
Кратко про процессы