У нашего облака появился новый тип пользователей, и это не люди. Каждый третий запрос к документации Timeweb Cloud сегодня приходит из сетей ИИ-вендоров, а серверы всё чаще создаются не из панели управления, а запросами к API, которые пишет ассистент по просьбе человека.
Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud. Раньше я рассказывал, как мы построили систему автотестов с 5 000+ проверками и как делаем визуализацию облака. Сегодня текст другого масштаба: посмотрим не на одну систему, а на то, куда в целом движется рынок облачных услуг. Трендов там, разумеется, больше одного, но этот текст про тот из них, что я вижу ближе всего: про агентов. Покажу картину, которая складывается изнутри провайдера, подкреплю ее цифрами и расскажу, какие выводы я делаю из нее на ближайшие годы.
❯ Порог автоматизации исчез
Автоматизация в облаке была всегда: API, CLI, Terraform. Инфраструктуру как код давно описывает заметная часть клиентов, и панель нужна им разве что свериться, что всё на месте. Но у этой автоматизации был порог входа: нужно было уметь писать конфигурации и понимать, что именно ты описываешь.
С появлением агентов порог исчез. У Timeweb Cloud есть MCP-сервер, через который облаком можно управлять из Cursor, Claude Code или другого ассистента: человек пишет «подними сервер под стейдж и добавь A-запись», и ассистент сам вызывает нужные методы API. Тот же сценарий работает и без внешних инструментов, в чате TimewebGPT в панели. Никаких особых прав у ассистента при этом нет: он действует от имени пользователя панели, с его же правами за вычетом операций удаления, а изменения требуют подтверждения.

Сценарий оказался живым: за последние две недели эндпоинт принял 112 тысяч запросов, и неделя к неделе объём вырос почти в полтора раза. Но интереснее цифр то, кто эти пользователи. Раньше автоматизация была уделом тех, кто умеет писать Terraform-конфиги; теперь сервер из диалога создаёт и человек, для которого облако всегда было слишком сложным. Порог входа опустился до умения сформулировать задачу словами.
❯ Каждый третий запрос к документации
Готовя этот текст, я решил проверить ощущения цифрами и заглянул в аксесс логи: взял самый свежий срез, запросы к разделу документации timeweb.cloud/docs за две недели.
Результат оказался сильнее моих ощущений. Из 237 тысяч внешних запросов к документации 76 тысяч сделали боты ИИ-вендоров: 32%, каждый третий запрос. И это нижняя граница: ботов Anthropic, ByteDance и ещё нескольких компаний посчитать не удалось, так что реальная доля ещё выше.

Внутри этой трети самое интересное не сумма, а расклад. Классический Googlebot за две недели сделал 2 691 запрос. ChatGPT-User сделал 61 475, в двадцать три раза больше. При этом ChatGPT-User не обучающий краулер: это запросы, которые ChatGPT отправляет по просьбе живого пользователя прямо во время диалога. А обучающий GPTBot за то же время зашёл ровно 10 раз. Документацию сегодня читают не ради датасетов, а ради ответа конкретному человеку прямо сейчас.

Ещё одна деталь: агенты и люди читают разные страницы. Человеческий топ — как привязать карту, настройка SSH, защита от брутфорса. Топ ChatGPT — создание сервера, лимиты тарифов, управление DNS-записями: страницы, которые нужны, чтобы выполнить действие, а не разобраться в вопросе.
Оговорка для точности: окно всего две недели, а запросы не равны визитам, так что это срез, а не тренд. Но для ощущения масштаба среза достаточно.
❯ Выбирать провайдера тоже будет агент
У этих цифр есть следствие поважнее самих процентов. Модель заходит в документацию в тот момент, когда человек уже попросил её что-то сделать или посоветовать: весь агентский топ страниц — подготовка к действию. Значит, рекомендация «возьми это облако и настрой вот так» рождается не из рекламы и не из поисковой выдачи, а из того, что модель знает о провайдере и насколько его документация ей понятна.
Двадцать лет индустрия оптимизировала сайты под поисковики. Теперь начинается следующий цикл: оптимизация под модели. Полнота и структура документации становятся каналом привлечения клиентов, потому что баннер агент не увидит никогда, а страницу «как создать сервер» прочитает тысячи раз. К документации мы и раньше относились серьёзно, просто теперь у неё появился второй читатель, со своими привычками и требованиями.
У этого сдвига есть и вторая половина: витриной облака перестаёт быть интерфейс. Агент не видит панель, продуманный онбординг и красивые графики — он видит API, документацию и предсказуемость поведения, и выбор всё чаще происходит по этим критериям. Признаваться в этом немного грустно: в визуальную часть панели мы вложили массу сил и продолжаем вкладывать. Панель никуда не денется, у неё остаётся своя аудитория и свои сценарии, просто теперь она не единственная дверь в облако.
❯ Труд дешевеет, ответственность — нет
Значительная часть облачных услуг исторически продавала труд. «Мы установим Postgres, настроим бэкапы и будем следить за обновлениями» переводится как «вам не придётся нанимать админа или разбираться самому». Премия за такую услугу держалась на том, что час админской работы стоит дорого, а желания тратить на это свои вечера у клиента нет.
Агенты меняют эту арифметику на глазах. Стоимость «поставить и настроить» падает почти до нуля: то, на что раньше уходил вечер с документацией, агент делает за минуты, причём в среднем аккуратнее новичка. Думаю, маржа услуг, построенных чисто на труде, будет сжиматься, и довольно быстро.
Но у managed-услуги всегда была вторая составляющая, и вот она никуда не девается: ответственность. Клиент платит провайдеру за то, что в три часа ночи проснётся чужой дежурный, а не он сам. За SLA и юрлицо, с которого можно спросить. За то, что кто-то другой отвечает за сохранность бэкапов. Агент ничего из этого дать не может: он инструмент, и когда он в пятницу вечером «оптимизирует» конфигурацию репликации и уронит базу, отвечать будет владелец агента.
Причём это история не только про энтерпрайз. Даже небольшому SaaS на два человека не хочется лично отвечать за данные своих клиентов. Поэтому линия раздела, как мне кажется, пройдёт не между крупным и мелким бизнесом, а между stateful и stateless:
Всё восстановимое — веб-слой, воркеры, CI, стейджинги — уйдёт в связку «агент плюс недорогая VM» довольно быстро: цена ошибки там измеряется минутами пересоздания.
Данные и бэкапы клиенты продолжат доверять провайдеру: цена ошибки там невосполнима, и никакая экономия её не оправдывает.
❯ Строительные блоки придётся заслужить
Следующий вопрос для меня самый интересный: что агент выберет — голую VM или управляемый сервис.
В теории управляемый сервис для агента идеален. Дёрнуть один метод «создай кластер базы данных с бэкапами» проще, чем собирать репликацию из пакетов и systemd-юнитов, а вероятность ошибки у агента растёт с каждым лишним шагом. Состояние готового сервиса машиночитаемо, самодельную инсталляцию нужно обследовать. И откатиться, если что-то пошло не так, тоже проще. Я и по своей работе это замечаю: когда прошу ассистента что-то развернуть, связка «готовый сервис плюс API» стабильно обыгрывает вариант «сейчас соберём сами из пакетов».
Но у голой VM есть свои козыри, и для агента они весомее, чем для человека. Стандартный стек агент уверенно собирает и сам: туториалов по настройке Postgres он прочитал больше, чем любой админ. VM дешевле. И она не привязывает: managed-блок у каждого провайдера свой, а docker-compose переезжает куда угодно.
Поэтому исход здесь не предрешён. Место строительного блока в агентском мире управляемым сервисам придётся заслужить: зрелостью и гибкостью, машиночитаемым состоянием, MCP из коробки, гарантиями за данные. Блок, который для агента не удобнее самосборки, агент просто пересоберёт сам.
❯ Появляется слой надзора
История индустрии подсказывает, что большие волны абстракций редко убивают предыдущий слой. Облако должно было убить сисадминов, Kubernetes должен был убить PaaS; вместо этого всякий раз появлялся новый слой сверху, и работа переезжала туда.
С агентами, похоже, происходит то же самое. Когда инфраструктурой управляет автономная система, возникает задача, которой раньше не было: независимая проверка её работы. Человек, который сам менял конфиг, хотя бы знает, что именно он менял. Агент делает десятки изменений подряд, и владельцу нужен внешний способ убедиться, что после всех этих изменений сервис вообще жив и отвечает. Проверку работы агента нельзя поручать самому агенту, точно так же как ревью кода не поручают его автору.
Из этой задачи вырастает целый слой инструментов: независимый мониторинг, журналы действий агентов, подтверждение опасных операций, лимиты на то, что агент может потратить. Первые кирпичи этого слоя видны уже сейчас — наши подтверждения изменений и отрезанные удаления в MCP как раз из этой серии. Остальное, думаю, появится в ближайшие пару лет.
❯ Каким я вижу рынок через несколько лет
Если собрать наблюдения вместе, картина у меня получается такая:
Базовый IaaS коммодитизируется ещё сильнее. Compute, сеть и диски становятся сырьём, которое агенты закупают и собирают в решения; конкуренция окончательно уходит в цену и надёжность.
Середина сжимается. Сервисы уровня «то же самое, но с панелькой и за тройную цену» теряют смысл: их ценность агент воспроизводит бесплатно.
Устойчивыми остаются две роли, и часто их совмещают одни и те же компании. Носитель ответственности: SLA, дежурства, сохранность данных, комплаенс. И поставщик строительных блоков, которые агенту действительно удобнее самосборки: чистые API, машиночитаемые статусы, MCP.
Формируется новый слой: надзор за автономными системами. Независимый мониторинг, журналы действий, подтверждения, лимиты трат. Этот слой сейчас в самом начале.
Для нас из этой картины следуют вполне практические выводы, и по ним мы уже живём: API, документация и машиночитаемость перестали быть задачами второго плана, а всё, что агент делает в облаке, должно быть наблюдаемым и обратимым. Не потому, что панель стала не нужна, а потому, что у облака теперь два равноправных типа пользователей, и второй читает только документацию.
Честности ради: прогнозы в нашей индустрии живут недолго, и через пару лет я, возможно, перечитаю этот текст с улыбкой. Но пока каждый месяц наблюдений скорее подтверждает картину, чем опровергает её.
❯ В заключении
Многое из описанного ещё может повернуться иначе. Но одно уже не отменить: каждый третий читатель нашей документации — не человек, и он пришёл не любоваться интерфейсом.
Спасибо, что дочитали до конца! Мне очень интересен ваш опыт: доверяете ли вы уже агентам реальные действия в своей инфраструктуре, и если да, то где проводите границу между «пусть делает сам» и «только с моего подтверждения»? Расскажите в комментариях.
Может быть интересно:

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩
l0ser140
Но поднятая агентом через API инфраструктура ничего общего не имеет с IaaC. Повторяемость у нее даже поменьше, чем в панели накликать.
vnoleg
если попросить агента поднимать через IaaC с сохранением манифест файлов и т.д. - то вполне себе имеет.
Или внедрить средний слой, который будет делать тоже самое: конвертировать запрос пользователя в манифест и применять его. Можно как угодно, если есть необходимость в такого рода задаче