HTML как новый Markdown: Почему агенты переходят на визуальный язык общения

Многие до сих пор болезненно реагируют на критику Markdown, и это понятно: у него куча сильных сторон. Этот формат прост, портативен, поддерживает базовое форматирование, его легко править вручную. Но мы начинаем использовать его слишком часто. И похоже, что это мнение разделяют всё больше специалистов.

Торик из команды Claude Code недавно опубликовал материал под названием «Необоснованная эффективность HTML». А следом — «HTML — это новый Markdown». Он почти полностью перестал писать markdown-файлы и переключился на генерацию HTML через Claude Code. И это не единичный случай. Андрей Карпати тоже заявил, что подход работает отлично: просто попросите модель структурировать ответ как HTML.

Почему это происходит? Потому что агенты, как и люди, устали от бесконечных стен текста.

Почему Markdown перестал справляться?

Markdown стал доминирующим форматом общения агентов с пользователями. Но по мере того как агенты становятся умнее, мы упираемся в ограничения.

Читать markdown-файл длиннее 100 строк — то еще удовольствие. Нужны визуализации, цвет, диаграммы, возможность легко поделиться результатом. И файлы всё реже правят вручную — чаще просят модель отредактировать их. А это убивает одно из главных преимуществ Markdown: удобство ручного редактирования.

HTML решает эту боль.

Информационная плотность против чтива

Один HTML-файл может содержать таблицы, макеты, иллюстрации, SVG, интерактивные элементы, код с подсветкой и даже изображения. Да, с генерацией изображений модели до сих пор справляются отвратительно: они либо галлюцинируют base64-строки, либо выдают несуществующие URL. Но в остальном HTML выигрывает на всех фронтах.

Например, вы просите агента найти три способа реализовать debounced search. Вместо трех последовательных «стен текста» вы получаете HTML-страницу с тремя колонками: useEffect с таймаутом, кастомный хук useDebounce с плюсами и минусами и сторонняя библиотека. Внизу — рекомендация. Вы просто тыкаете в понравившийся вариант.

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

Визуальная ясность и удобство чтения

Современные модели способны писать всё более сложные спецификации и планы. Но на практике很少有人 читает markdown-файлы дольше 100 строк. И уж точно сложно заставить коллег их читать.

HTML-документы читать проще. Они могут быть структурированы визуально: вкладки, иллюстрации, ссылки. Адаптивная верстка (хотя в примерах Торика с мобилкой беда). И их легко шарить: залил на S3 — получил ссылку. Не нужно прикреплять файл к письму.

Но тут есть важный нюанс: часть текущего вау-эффекта — от новизны. Если все вокруг начнут слать HTML-ссылки вместо гигантских markdown-файлов, станет ли легче их читать? Скорее всего, да. Но не настолько, как сейчас. Новизна — значительная часть ценности.

Интерактивность и двусторонняя связь

Вот где HTML действительно силен. Модель может добавить в документ слайдеры, ручки настройки, переключатели. Вы меняете параметры — и видите, как меняется алгоритм. А потом кнопкой «скопировать изменения в промпт» отправляете всё обратно агенту.

Это уже не просто чтение — это взаимодействие.

«Код дешев»: философия одноразовых интерфейсов

Многие разработчики до сих пор не приняли тот факт, что код больше не ресурс, который надо экономить. Около 70 процентов кода, который сейчас генерируется, выполняется один раз и выбрасывается. И это нормально.

Создавать одноразовый HTML-интерфейс, чтобы поиграть с данными, принять решение и выбросить его — абсолютно оправданно. Думайте в терминах импорта и экспорта данных. Каждая CSV, JSON-блоб, даже сложный промпт — кандидат на то, чтобы обернуть его в кастомный интерфейс на HTML.

Как начать? Просто попросите

Вам не нужен специальный скилл. Начните с простого промпта: «Сделай HTML-файл» или «Сделай HTML-артефакт». Смысл не в инструменте, а в том, что вы хотите получить.

Общий принцип: сначала попросите модель сделать что-то напрямую. Посмотрите, что получается, что нет. Запомните, какие детали приходится уточнять в каждом промпте. А уже потом, если нужно, делайте скилл.

Вот стартовые сценарии:

  1. Спецификации и исследования: попросите модель сгенерировать несколько вариантов решения на одной странице сеткой. Или создать HTML-план с мокапами, потоками данных и ключевыми сниппетами.
  2. Code review: вместо стандартного GitHub-диффа попросите агента сгенерировать HTML с аннотациями, группировкой изменений по важности и подсветкой проблем. Диффы в markdown — действительно боль.
  3. Отчеты и исследования: дайте агенту доступ к Slack, Jira, git history и попросите сделать красивый HTML-отчет. Например, что сделано за неделю. Покажите на стендапе. Руководство будет в восторге.
  4. Прототипы и дизайн: даже если финальный продукт на Swift или React, набросайте дизайн в HTML.

Полезный прием: иногда стоит притвориться глупее, чем вы есть. Скажите модели: «Я не понимаю, как работает rate limiter. Прочитай код и сделай HTML-объяснялку с диаграммой token bucket, 3–4 аннотированными сниппетами и секцией “подводные камни”». Модель начнет объяснять так, как нужно вашим пользователям, а не вам.

Контраргументы и недостатки

  • Токен-эффективность: Да, Markdown компактнее. Но с контекстным окном на миллион токенов разница незаметна. А то, что HTML-отчет будет прочитан с большей вероятностью, перевешивает.
  • Version control: Вот где HTML реально проигрывает. Диффы HTML — это шумно и нечитаемо. Это главный минус.
  • Стилизация: Чтобы HTML выглядел не как типичный «агентский дизайн», нужна дизайн-система. Создайте один эталонный HTML-файл со стилями вашей компании и ссылайтесь на него.
  • Мобильная адаптация: Красиво сказать «адаптив» легко. Сделать его в сгенерированном HTML — сложнее, это требует больше токенов и часто ломается.

Мнение Карпати: будущее за визуалом

Андрей Карпати недавно написал, что в конце промпта стоит просить LLM структурировать ответ как HTML. И что визуал (картинки, анимации, видео) — предпочтительный выход для ИИ. У нас треть мозга — массивно-параллельный процессор для зрения. Текст читать тяжело. Markdown легче. HTML еще легче (и гибче). А дальше — интерактивные видео и симуляции, генерируемые нейросетями в реальном времени.

Он заходит далеко: «представьте, что каждый пиксель на экране стримится напрямую из модели. Никакого HTML, никаких layout-движков, никакого кода. Просто динамически создаваемый UI». Звучит фантастично, но тренд понятен.

Резюме

Полностью отказываться от Markdown — слишком радикальное решение. Но смотреть в сторону HTML определенно стоит. Это не просто замена формата. Это смена парадигмы взаимодействия: от текста к визуалу, от чтения к взаимодействию, от постоянного кода к одноразовым интерфейсам.

Разработчики всё еще привязаны к терминалам, и это показатель того, как далеко предстоит пройти. Но HTML — это первый серьезный шаг. Если ваш менеджер пока не дает доступ к Jira API — не проблема. Сделайте простую HTML-панель с отчетами на основе доступных данных. Эффект будет тот же.