Админка больше не обязательна: как я дал Codex API к сайту и получил новый интерфейс управления контентом

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

Недавно я решил проверить другой подход. В одном из своих давних проектов я сделал API для управления контентом и отдельный skill для Codex, в котором описал структуру данных, связи между сущностями, правила заполнения и требования к самому контенту. В итоге получилось не просто автоматизировать часть рутины, а фактически заменить значительную часть работы с админкой на обычные текстовые команды агенту.

Что именно я сделал

В проекте много разных типов контента: статьи, места, события, объявления и другие сущности со своими полями, связями, изображениями, локализациями и правилами заполнения. Поэтому просто дать агенту один универсальный endpoint было бы недостаточно: ему нужно понимать, что именно он редактирует и по каким правилам.

Я добавил API, через которое можно:

• получать существующие данные;

• создавать новые записи;

• обновлять записи;

• работать со связанными сущностями;

• загружать и привязывать изображения;

• проверять текущее состояние перед изменением.

Отдельно сделал skill для Codex. В нем описал не только endpoint’ы, но и предметную область: какие сущности существуют, какие поля обязательны, как они связаны, какие значения допустимы, что нужно проверять перед записью и каким должен быть сам контент.

Получилось удобное разделение: API определяет, что системе технически разрешено сделать, а skill — как с этой системой правильно работать. Именно эта связка и оказалась наиболее важной.

Вместо заполнения форм — задача на естественном языке

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

Теперь я могу написать агенту, например:

Найди три интересных места такого-то типа в этом регионе, которых еще нет на сайте. Проверь информацию по надежным источникам, подготовь данные в формате проекта и добавь записи.

После этого агент сам получает через API существующие записи, проверяет возможные дубли, ищет и сверяет информацию, приводит ее к структуре проекта, готовит текст, работает с изображениями и отправляет все через API. Затем он может перечитать созданную запись и проверить, что данные сохранились так, как ожидалось.

Для меня здесь самое интересное даже не экономия времени. Меняется сам интерфейс работы с системой: вместо последовательности действий «открыть сущность → заполнить поле → выбрать значение → сохранить» я формулирую конечный результат.

Админка — это тоже язык между человеком и системой

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

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

Теперь эту роль может выполнять LLM-агент. Он понимает задачу на естественном языке, а затем превращает ее в конкретные операции с API.

Человек
  ↓
Codex / Claude / другой агент
  ↓
Skill проекта
  ↓
Content API
  ↓
Бизнес-логика
  ↓
База данных

Именно это для меня стало главным результатом эксперимента: агент оказался не дополнением к админке, а отдельным интерфейсом управления приложением.

Ценность не в генерации текста

Самое очевидное применение LLM в CMS — попросить модель написать статью или описание. Но в реальной работе это только один этап, причем далеко не всегда самый трудоемкий.

Чтобы добавить новое место на сайт, агенту может понадобиться сначала проверить, нет ли его уже в базе, затем найти актуальную информацию, сверить факты, определить подходящую категорию, подготовить краткое и полное описание, заполнить SEO-поля, подобрать изображение и только после этого сохранить все через API. То есть агент выполняет не отдельную микрозадачу, а весь процесс целиком.

С изображениями ситуация тоже сильно изменилась. Для части материалов подходящую иллюстрацию можно сгенерировать в рамках того же процесса, но здесь особенно важны правила: сгенерированная обложка для статьи и выдуманная «фотография конкретного ресторана» — совершенно разные вещи. Такие ограничения тоже имеет смысл явно описывать в skill, а не надеяться, что модель сама всегда выберет правильный вариант.

Почему API, а не прямой доступ к базе

Технически можно было пойти самым коротким путем и дать агенту прямой доступ к базе данных. Я сознательно этого не делал, потому что API дает намного больше контроля и сохраняет бизнес-логику приложения.

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

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

Для агентов хороший API становится еще важнее

Когда системой пользуется человек через UI, странности backend’а можно долго маскировать интерфейсом. С агентом они становятся заметнее: неоднозначные методы, неожиданные побочные эффекты и плохо описанные ошибки быстро начинают мешать.

Для агентской работы особенно полезны:

• понятные и узкие операции;

• строгая валидация;

• предсказуемые ошибки;

• идемпотентность там, где она нужна;

• разделение чтения и изменения данных;

• возможность перечитать объект после записи;

• аудит действий.

Для потенциально опасных операций я бы вообще придерживался простой схемы:

прочитать состояние → подготовить план → подтвердить изменения → выполнить → перечитать результат

Такой подход полезен не только для контента. Чем больше агент получает возможностей менять реальные данные, тем важнее четко разделять чтение, подготовку и фактическое изменение состояния.

Нужны ли тогда админки вообще

Конечно нужны. Есть задачи, где обычный графический интерфейс все еще удобнее: быстро просмотреть сотни записей, отфильтровать их, отсортировать, сравнить, массово выбрать или вручную что-то поправить. Для таких сценариев таблица, фильтры и нормальный UI по-прежнему отлично работают.

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

Именно таких задач в реальной работе оказалось гораздо больше, чем я ожидал.

Это интересно не только для старых проектов

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

Обычно административную часть продукта проектируют примерно так:

backend → API → admin frontend

Теперь я бы в некоторых случаях сначала сделал хороший domain API, подключил к нему агента и некоторое время поработал через него. После этого уже можно понять, какие операции действительно требуют отдельного визуального интерфейса, а какие можно оставить агенту.

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

Что получилось в итоге

Изначально я хотел всего лишь автоматизировать рутинную работу с контентом. В результате получил другой способ управлять сайтом.

Теперь вместо длинной последовательности действий в админке я могу написать:

Добавь на сайт три новых события на следующий месяц.

Проверь эту запись и обнови устаревшую информацию.

Найди материалы без нормальных изображений и подготовь их.

Сделай версии этих записей на других языках.

Агент сам превращает такую задачу в поиск данных, проверку, подготовку контента и набор API-вызовов. Для меня это оказалось намного интереснее, чем привычный сценарий «LLM пишет текст» или «AI помогает программисту писать код».

По сути агент становится новым интерфейсом к прикладной системе. И после этого эксперимента я уже не уверен, что в следующем проекте начну проектировать управление контентом с макетов админки: скорее сначала сделаю хороший API, а потом посмотрю, какие интерфейсы действительно еще нужны человеку.

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

0%Да, с удовольствием заменил бы большую часть работы с админкой на команды агенту0

0%Да, но только если все изменения можно проверять и подтверждать перед публикацией0

0%Использовал бы гибрид: агент для рутины, админка для контроля и сложных случаев0

0%Нет, мне удобнее привычная админка0

0%Не уверен — сначала хотел бы попробовать на реальном проекте0