ИИ-агенты в продакшене: взгляд оператора 6 агентов на «100x engineer» Cloudflare

Cloudflare только что сократила 20% сотрудников, сославшись на рост производительности благодаря ИИ «от двух до ста раз». Если ИИ-агенты оцениваются через концепцию «100x engineer», это грозит волной системно ошибочных решений по численности команд.

Что именно Cloudflare заявила по итогам Q1 2026

Чаще всего из звонка с инвесторами цитируют слова Prince о том, что благодаря ИИ некоторые сотрудники теперь выдают «в два, десять и даже сто раз» больше результата. Эту формулировку подхватили TechCrunch, CNBC и The Register. Все публикации приняли её как данность и сразу перешли к числу потерянных рабочих мест.

Полная картина такова: Cloudflare сокращает 1,100 человек на позициях, где, по словам Prince, работу теперь выполняет ИИ. Подразумевается, что раньше узким местом были люди, а ИИ это ограничение устранил. Выручка выросла на 34%. Штат уменьшился на 20%. История для инвесторов складывается сама собой: тот же результат, меньше людей, выше маржа.

Но ни на звонке с инвесторами, ни в публикациях никто не задал главный вопрос: остаётся ли «производительность в 100x» вообще осмысленной единицей анализа, если агент выполняет процесс целиком — от начала до конца? Инженер, который с помощью ИИ стал в 100x продуктивнее, и процесс, полностью выведенный из категории человеческого труда, — не одно и то же. Для основателя, решающего, кого оставить в команде, эта разница принципиальна.

Чем я на самом деле занимаюсь на этой неделе

Я управляю системой публикации этого блога на Workers и Durable Objects. В ней шесть агентов: ManualIntake, Discovery, Editorial, Writer, Distribution и Maintenance. За прошлый месяц они выпустили 24 статьи. Напрямую я работал, пожалуй, лишь над четырьмя. Ниже — счёт.

Сколько на самом деле стоят 6 продакшен-агентов на Workers

Вот фактический счёт Cloudflare за апрель 2026 года для системы публикации с шестью агентами.

Вычисления в Workers обошлись в $11.40. Чтение и запись в базе D1 — там хранятся рабочая память агентов, очереди задач, черновики статей и метаданные контента — стоили $3.20. Хранение медиафайлов и архивных экспортов в R2 — $0.84. Семантический поиск по корпусу статей в Vectorize — $1.10. На запросы и длительность выполнения в слое оркестрации Agents SDK и Workflows пришлось ещё $2.60. Итого инфраструктура Cloudflare: $19.14 за месяц.

Инференс оплачивается отдельно, уже на стороне поставщика моделей. В апреле все шесть агентов использовали Claude Sonnet 4.5 или Haiku 3.5 — в зависимости от сложности задачи. За месяц это составило $214. Полная стоимость ИИ-системы с инфраструктурой и инференсом: $233.14.

Статистика задач за апрель: ManualIntake обработал 31 запрос на контент. Discovery выполнил 188 задач по исследованию и поиску источников. Editorial подготовил 47 брифов и циклов доработки. Writer создал 24 опубликованных черновика. Distribution выполнил 96 задач по синдикации и соцсетям. Maintenance провёл 240 плановых проверок состояния, аудитов ссылок и обновлений индекса. Итого — 626 агентских задач за месяц, примерно по $0.37 за задачу с учётом всех расходов.

Для небольшого координационного слоя система использует сервер Hetzner CX22 за €4.42 в месяц. Больше ничего.

Сколько стоил бы сотрудник, способный выполнять 626 задач в месяц с тем же качеством и темпом? Специалист среднего уровня по контент-операциям на западном рынке обходится работодателю в $6,500-$9,000 в месяц. Существенную часть этой работы агенты выполняют за $233. Эта экономика реальна, и делать вид, будто это не так, я не стану.

Но есть важная деталь: я по-прежнему трачу на эту систему около 12 часов в неделю. Не на задачи, которые выполняют агенты, а на другую работу. Именно её концепция «100x» полностью упускает.

ИИ-агенты и «100x engineer»: почему эта модель неверна

Концепция «100x engineer» предполагает, что есть инженер, которого ИИ делает в 100 раз продуктивнее. Единицей измерения всё равно остаётся инженер — просто теперь на тот же объём результата нужно меньше людей.

При реальном внедрении агентов происходит другое: целый процесс выводится из категории человеческого труда. Агент Discovery не делает исследователя в 100x продуктивнее — исследователя вообще нет. Исследовательский процесс запускается по расписанию cron, обращается к набору API и моделей, записывает структурированный результат в D1 и запускает агента Editorial. Процесс сохранился, а человеческой роли, которая раньше им владела, больше нет.

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

Если мыслить в терминах «100x engineer», смотришь на инженерный штат и спрашиваешь: каких десять человек оставить, чтобы заменить сотню? В результате компания сохраняет самых результативных сотрудников и сокращает остальных.

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

Роль, на которую пока почти никто не нанимает, я бы назвал руководителем Agent Operations. Это не промпт-инженер и не ML-инженер. Такой специалист достаточно глубоко понимает бизнес-процесс, чтобы точно описать задачу агента; умеет читать журнал состояния Durable Object и находить причину зависшего рабочего процесса; замечает, когда качество результата агента отклоняется от допустимого; и способен развивать систему по мере изменений в бизнесе. Мои 12 часов в неделю на систему публикации — примерно такая работа. Она требует не низкой квалификации, а сочетания процессной экспертизы и технической подготовки, достаточной для эксплуатации системы. И отдача от неё очень высока.

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

Автоматизация создаёт работу — просто уже другую
Каждый запущенный мной продакшен-агент создаёт примерно от 3 до 5 проблем в месяц, требующих вмешательства человека. Повреждение состояния, результат модели, не прошедший проверку качества, изменение схемы в стороннем API, взаимная блокировка задачи из-за того, что два агента одновременно записывают данные в одну строку D1. Ни одна из этих проблем не катастрофична, но для каждой нужен человек, который знает систему. Если сократить штат и не сохранить компетенцию Agent Operations, нерешённые проблемы начнут накапливаться.

Кроме того, автоматизация не только устраняет работу, но и создаёт новую. Агент Editorial выпускает 47 брифов в месяц, а редактор-человек теперь проверяет и утверждает их. До появления агента, возможно, создавалось 15 брифов. Агент не заменил редактора: он расширил масштаб его работы и поднял планку требований. Некоторые роли рядом с парком агентов не исчезают, а усиливаются. Основатели, которые не составят точную карту этих взаимосвязей, сократят именно усиленные роли, а затем будут недоумевать, почему после сокращений упала пропускная способность.

Как основателю планировать штат на H2 2026

Если план численности на H2 строится вокруг истории Cloudflare, я бы использовал следующую схему.

Сначала разделите процессы на две категории: кандидаты на замену процесса и кандидаты на замену роли.

Кандидаты на замену процесса — это преимущественно детерминированные рабочие потоки, которые можно полностью описать, а качество результата — измерить автоматически. Обслуживание конвейеров данных, массовое производство контента, первичная сортировка обращений в поддержку, генерация QA-тестов, обновление документации, обработка счетов. В таких случаях нужно спрашивать не «поможет ли ИИ сотруднику справляться быстрее», а «можно ли в следующие 90 дней полностью вывести этот процесс из категории человеческого труда». Прежде чем менять численность команды, проведите четырёхнедельный тест с агентом.

Кандидаты на замену роли устроены иначе и встречаются гораздо реже. Речь о ситуациях, когда человек в основном квалифицированно исполняет чётко определённую задачу, задача уже поддаётся автоматизации, а рядом с ней нет работы по принятию решений или выстраиванию отношений. Такие роли действительно под угрозой. Но их меньше, чем следует из истории Cloudflare, потому что большинство ролей состоит из набора задач, а не из одной задачи. Инженера, который пишет код, проверяет PR, определяет объём работ, наставляет младших коллег и общается с клиентами, нельзя заменить агентом для написания кода. Автоматизировать можно лишь часть, связанную с кодом.

Расчёт численности, который выдержит обсуждение на уровне совета директоров компании от Series A до Series C, выглядит так: возьмите текущую полную стоимость процесса, вычтите прогнозируемую полную стоимость парка агентов для его замены — инфраструктуру, инференс и расходы на Agent Operations — и покажите разницу. При $233 в месяц за 626 задач экономика для подходящих процессов очевидно привлекательна. Но для роли, которая действительно объединяет требующие суждения задачи, преимущество быстро исчезает.

До сокращения любого сотрудника я бы провёл такой тест: на 60 дней запустил агента параллельно с человеком. Оценивал бы качество их результата по одной и той же шкале. Измерял частоту сбоев и вмешательств. Рассчитал бы, сколько рабочего времени на самом деле отнимает Agent Operations. Если с учётом этих расходов агент проходит порог качества за 30% стоимости человека, деловое обоснование убедительно. Если устранение сбоев требует больше часов, чем агент экономит, — нет.

Проверка экономики на рабочем объёме несложна. Большинство основателей пропускают её, потому что история Cloudflare создаёт ощущение, будто проверка не нужна. Заявление о «100x» звучит соблазнительно. Но как человек, работающий с продакшен-системой на том же стеке, скажу: важен не множитель производительности, а стоимость одной задачи при приемлемом качестве, включая операционную нагрузку. Проверьте это до того, как цифра попадёт в презентацию для совета директоров.

В: Будут ли ежемесячные расходы $233 расти линейно с добавлением новых агентов?

Для инференса — примерно да. Расходы на инфраструктуру Cloudflare растут медленно, поскольку Workers и Durable Objects эффективны при масштабировании. Главная переменная в моих расходах — инференс. Если удвоить объём агентских задач, стоимость инференса, вероятно, тоже примерно удвоится. Инфраструктура подорожает, возможно, на 20-30%. Операционная нагрузка растёт медленнее линейной, потому что управлять приходится системами, а не отдельными задачами.

В: Какие продукты Cloudflare действительно критичны для продакшен-парка агентов?

Основная нагрузка ложится на Durable Objects. Это персистентные машины состояний, которые координируют долгие агентские задачи между вызовами Workers и не требуют внешней базы данных для координации. D1 служит реляционным хранилищем бизнес-данных. R2 — объектным хранилищем. Vectorize хранит эмбеддинги. Agents SDK — сравнительно тонкий слой оркестрации поверх Durable Objects. При оценке этого стека именно Durable Objects являются его архитектурным центром.

В: Как на практике выглядит ежедневная работа в Agent Operations?

В моём случае это 30 минут каждое утро на просмотр журналов задач в поисках сбоев или отклонений качества, около двух часов в неделю на отладку и развитие агентских рабочих процессов и регулярная проверка качества результатов за предыдущую неделю каждый понедельник. Всё остальное — реактивная работа: что-то ломается, и я это исправляю. Для более крупного парка, обслуживающего команду из 20+ человек, это, вероятно, работа на полставки, а не задача для свободного времени.

За чем следить в ближайшие 30 дней

Формулировка из отчётности Cloudflare начнёт распространяться. До конца сезона отчётности за Q2 как минимум ещё три-пять публичных технологических компаний, вероятно, прикроют сокращения штата «ростом производительности от ИИ». Внимания заслуживают основатели, которые объявят о сокращениях и одновременно раскроют конкретику внедрения агентов, а не ограничатся расплывчатыми тезисами о производительности. Это было бы реальным сигналом. Заявления без описания стека, числа задач и стоимости одной задачи — лишь спектакль для совета директоров.

Что касается самого стека Cloudflare, Agents SDK быстро развивается. Тарифы на гибернацию Durable Object изменились ранее в этом году и теперь существенно выгоднее для постоянно работающих агентов. Если вы оценивали эту архитектуру, но откладывали запуск, кривая затрат сдвинулась в вашу пользу. Операционная сложность никуда не исчезла, однако ею можно управлять в масштабе, который нужен большинству компаний от Series A до Series C.

В течение 12 месяцев найм в Agent Operations оформится в отдельную категорию рынка труда. Стоит заранее понять, как эта роль должна выглядеть в вашей компании, ещё до того, как название должности появится в LinkedIn.

Если вы хотите провести аудит процессов до утверждения плана на H2, мой чек-лист аудита рабочих процессов на DVNC.dev напрямую соответствует этой схеме.

Итоги

• В отчётности Cloudflare за Q1 2026 рядом оказались выручка $639.8M, 1,100 сокращений и заявление о росте производительности от ИИ «от 2x до 100x».
• Работа 6 продакшен-агентов на Cloudflare Workers, Durable Objects, D1 и Agents SDK обходится в $233 в месяц за 626 задач с учётом всех расходов — примерно $0.37 за задачу, включая инференс.
• Концепция «100x engineer» неверна. Суть перемен — в полном выводе процессов из категории человеческого труда, а не в умножении производительности отдельного человека.
• Роль, на которую пока почти никто не нанимает, — Agent Operations: специалист, управляющий парком агентов, проверяющий и развивающий его. Если сократить команду до минимума без этой компетенции, парк агентов начнёт деградировать.
• До включения расчётов в презентацию для совета директоров проведите 60-дневный параллельный тест: агент и человек, единая шкала качества и реальная оценка операционных расходов. Экономика часто оказывается убедительной, но не всегда соответствует громкому нарративу.
• Ключевой показатель — стоимость одной задачи при приемлемом качестве с учётом операционной нагрузки, а не множитель производительности.