Когда ИИ-агент публикует «пустые» статьи: кейс с dev.to, редактором и write API
Контент-пайплайн с участием ИИ-агента довёл серию материалов до публикации на Dev.to, но часть постов оказалась в ленте с заголовком и метаданными при полностью пустом теле. В описанном сценарии финальный шаг шёл через автоматизацию веб-редактора платформы, а стабильный выход автор связывает с переходом на документированный write API и особой схемой передачи длинного markdown.
Материал пользователя saibuilder на Dev.to (публикация 21 мая 2026, 23:44 UTC) разбирает инцидент как разбор практики: от симптомов до ограничений авторизации и искажений Unicode на границах кодирования.
ИИ-пайплайн и масштаб сбоя: шесть постов, четыре с пустым телом
Описывается цепочка, в которой черновики проходят ручной просмотр, после чего срабатывает автоматическая публикация. В одной партии на Dev.to ушло шесть материалов: два выглядели нормально, четыре оказались публичными и индексируемыми, с заголовком, тегами, обложкой и каноническим URL, но без содержимого в теле при том, что исходный markdown для них существовал в пайплайне.
Такой разрыв между ожидаемым текстом агента и тем, что читатель видит на странице, бьёт по доверию к автоматизации публикаций: ошибка не на уровне «плохого промпта», а на границе инструмента доставки контента.
Публикация силами пайплайна через браузерный редактор Dev.to
Последний этап назван «publish» и описан как стандартная браузерная автоматизация встроенного редактора Dev.to: открытие формы нового поста, заполнение заголовка и поля markdown-тела, затем нажатие publish. ИИ-контент попадал на площадку не абстрактным «интеграционным слоем», а через полноценный UI-путь с DOM и типичными задержками клиентского редактора.
Для инженерного взгляда это важно: любой агент здесь упирается в те же ограничения, что и человек с копипастой, только быстрее и без усталости — включая гонки состояния редактора.
Почему markdown из пайплайна мог «исчезнуть» в rich editor без явной ошибки
В посте указано, что тексты были длинными — свыше 1500 слов markdown с code fences, иногда не ASCII, длинными тире и сопутствующей разметкой. При программной подстановке большой строки в rich editor и немедленном сохранении возникает гонка между внутренним состоянием документа и сериализацией «на save». В неудачном случае платформа не показывает ошибку, сохраняет то, что редактор считает документом в момент сохранения, — в примере это пустое тело, при этом приходят HTTP 200, рабочий опубликованный URL и отсутствие содержимого в body.
Вывод в терминах надёжности: «успешный» статус ответа не заменяет проверку того, что именно ушло в опубликованный артефакт.
Первая попытка: усложнить UI-автоматизацию под автопостинг агента
Первая линия защиты — не отказываться от UI, а усилить автоматизацию: ожидание готовности редактора, инъекция текста, повторные ожидания, опрос внутреннего значения до совпадения с отправленной строкой и только потом save. Затраты на такой слой оцениваются примерно в «пару часов» работы, итог — «лучше, но не хорошо»: для шага публикации приводится ориентир порядка ~90% надёжности и аргумент, почему этого недостаточно, если цель — предсказуемый автопостинг, а не ручной контроль каждой публикации.
Write API: PUT с body_markdown, когда агенту нужен обход браузерного редактора
Основной рабочий транспорт после отказа от «очевидного» пути — документированный write API Dev.to. Фигурирует обновление уже опубликованной записи через HTTP PUT на эндпоинт вида https://Dev.to/api/articles/{id} с заголовком api-key и JSON-телом, где передаётся markdown в поле вроде body_markdown внутри объекта article. Смысл для пайплайна с агентом простой: запрос уходит мимо DOM-редактора, исчезает класс гонок с кнопкой save в браузере.
Пример структуры тела запроса (упрощённо по описанию в источнике):
{
"article": {
"body_markdown": "…"
}
}
План восстановления четырёх повреждённых постов — для каждого известного идентификатора выполнить PUT с корректным содержимым.
API-путь агента: авторизация PUT и честная передача длинного Unicode
Два ограничения из практики автора стоит держать в голове при проектировании агентских сценариев.
Ответ 401 на server-side вызов. Первая попытка — PUT из серверного скрипта с API key в заголовке — завершилась 401. По наблюдаемому повторяемому поведению тот же запрос из уже залогиненной вкладки браузера проходил. Прямо оговаривается, что не претендуется на полный reverse engineering политики авторизации платформы.
Омоглифы при «наивной» инлайн-передаче длинного тела. При прокидывании markdown через цепочку экранирования и кодирования тело возвращалось с подменой символов на омоглифы (в том числе длинные тире, кавычки, часть букв). Рабочий обход в тексте: не инлайнить огромную строку — положить markdown в буфер обмена, в залогиненной вкладке вставить в обычный textarea, считать .value, затем отправить эту строку в PUT (в статье приводится фрагмент вроде fetch('/api/articles/${id}', …)). Там же описана посимвольная сверка всех четырёх восстановленных материалов с исходником.
Что в статье не измерено числами и что переносит в работу разработчик LLM-пайплайна
В первоисточнике нет отдельной таблицы пост-фикс метрик: ни доли пустых тел на горизонте недель, ни SLA публикации, ни мониторинга в проде сверх описанного сценария и проверки четырёх постов. В конце того же материала сформулированы обобщённые уроки уровня инженерной дисциплины — читать обратно опубликованный артефакт, а не доверять одному коду ответа; выбирать транспорт с понятными гарантиями; таймбоксить «борьбу с инструментом» порядка часа; помнить о риске искажения длинных Unicode-строк на границах кодирования. Это позиция автора, а не независимый бенчмарк.
Для команд, которые подключают LLM-агентов к публикации, связка «агент сгенерировал — человек одобрил — робот нажал publish» выглядит безопасной до первого тихого расхождения между черновиком и живой страницей. Перенос финального шага на API и аккуратная передача тела запроса там описаны как способ вернуть предсказуемость без бесконечного наращивания эвристик вокруг rich text.
Источники
- saibuilder, «My AI Agent Kept Publishing Empty Articles — So I Made It Edit Them Back via the API», dev.to — Dev.to (дата доступа: 2026-05-24, UTC). На карточке материала на dev.to указаны оценка времени чтения 7 минут и метка публикации 2026-05-21T23:44:01Z (21 мая 2026, 23:44 UTC).