Манифест с ручками

Всем чмоки в этом чате.

Продолжаю цикл манифестов, за которые регулярно улетаю в минус. В этот раз решил пойти ва-банк и выдать каждому «Пульт управления концом».

Вот ссылка. Но сначала несколько слов о том, что это и каким именно конецом предлагается управлять.

В «Манифесте созидателя» мы разбирали жизнь в мире дешёвого кода. В «О праве на следующий бюджет» — право продукта продолжать существование за чужой счёт. Теперь очередь организационной структуры. Сколько людей понадобится, чтобы этот продукт создавать, продавать и сопровождать? И кто будет оплачивать праздник производительности, если клиент тоже обзавёлся агентами?

У пульта есть ручки, переключатели, стрелка и лампочки. Утешительные выводы в базовую комплектацию не входят.

Т.е. это жизненно необходимый прибор для менеджера верхнего тира любого B2B AI 67 Native Cloud SaaS 360. В основе — глубокий консенсус ведущий аналитиков, решето Айкына и фаза Луны. Прибор считает штат и фонд оплаты труда вашей компании при заданном ИИ-ускорении. Степень согласия с аналитиками регулируется тумбликативно.

Тридцать человек, вентиляция на пять

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

Я предлагаю считать продукт целиком.

Допустим, над ним работают тридцать человек. Они уточняют требования, проектируют, пишут код, проверяют, выкатывают, разбирают инциденты. Ещё они объясняют друг другу, что именно уточнили, спроектировали и почему проверили не то.

Аналитик поговорил с заказчиком. Менеджер превратил разговор в задачу. Разработчик понял задачу по-своему. Тестировщик восстановил исходный замысел по косвенным признакам. На демонстрации выяснилось, что заказчик имел в виду другое. Все были заняты. Все могут предъявить результат работы. Особенно хорошо сохранилась переписка.

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

Модель простая:

 W = n · (1 − r) / (1 + κ · (n − 1))

Здесь n — размер команды, κ — цена координации, r — доля переделок после вычета координационных затрат. Дальше задаём ускорение работы и ищем, сколько людей нужно для прежнего результата.

При моих настройках для нового продукта — ускорение ×3,2, κ = 0,03, переделки с 35% до 15% — тридцать человек превращаются примерно в 4,2 человеко-эквивалента. В варианте для унаследованной системы — примерно в 12,5. Это результаты конкретных положений ручек. Полтора землекопа нанимать не требуется.

Почему выигрыш больше, чем само ускорение? Потому что уменьшившаяся команда меньше времени тратит на обслуживание собственного размера. А если один человек с агентами удерживает задачу от требований до приёмки, часть передач между ролями исчезает вместе с потерями контекста.

Этот резерв появился задолго до языковых моделей. В исследованиях QSM на проектах 2005–2011 годов крупные команды расходовали в три-четыре раза больше усилий, получая небольшое сокращение сроков и больше дефектов. ИИ здесь помогает пересобрать производство. Накладные расходы он не изобрёл.

Из этого не следует, что две трети ваших сотрудников бездельники. Вполне возможно, они добросовестно обслуживают способ организации работы, который больше не нужен в прежнем объёме. Для человека, занятого на полную ставку, разница философская. Для ФОТ — существенная.

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

Продолжайте ревью

Возражение известно: код агент напишет, а проверять кто будет?

В отчёте Faros за второй квартал 2026 года — два года телеметрии по 22 тысячам разработчиков. Эпиков на человека стало примерно на 66% больше. Время ревью выросло примерно впятеро, инцидентов на пул-реквест — на 243%. Производство разогнали, приёмка захлебнулась.

У CircleCI в отчёте 2026 года средняя пропускная способность выросла на 59%, а у медианной команды пропускная способность основной ветки упала на 6,8%. Это данные за сентябрь 2025-го. Здесь считают запуски рабочих процессов CI, а не строки кода.

Я читаю это как задержку адаптации. Генерацию уже перестроили, остальную фабрику ещё нет. Заваленный пул-реквестами сеньор теперь охраняет вход в продакшен с той же пропускной способностью, с какой раньше писал код. Только очередь длиннее.

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

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

Человек, способный всё это собрать, занят. Человек, чья ценность сводилась к обязательному присутствию между пул-реквестом и кнопкой Merge, получил повод пересмотреть карьерный план.

Статус сеньора сам по себе поведенческие сценарии не генерирует.

Смерть лицензии на рабочее место

Теперь посмотрим на ту же компанию с другой стороны договора. Вы продали ей сто лицензий. Она успешно автоматизировалась и оставила шестьдесят сотрудников. Объём работы сохранился. Продукт полезен. Пользователи довольны. На продлении вам нужны сорок новых клиентов в миниатюре, чтобы вернуться к прежней выручке.

Вы поздравили заказчика с повышением эффективности. Он вернул поздравление уменьшенным заказом.

SBI приводит снижение медианного NRR со 110,5% в 2023 году до 107,1% в 2025-м. NRR — сколько выручки осталось от прежней клиентской базы с учётом расширений, сокращений и уходов. По данным SBI, 58% компаний сообщают о снижении, связанном с тем, что клиент делает тот же объём меньшим числом людей.

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

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

Хранение, права, совместная работа и юридически значимые моменты остаются. Только продавать их придётся уже под другим обещанием. Ценность формата документа и ценность рабочего места редактора — разные товары.

Можно поднять цену, добавить обязательный ИИ-пакет, перейти на оплату за операции или результат. Но тариф не создаёт потребность. Новая строка в прайс-листе должна за что-то отвечать.

Осервисование софта

У дешёвого кода есть счётчик.

В модели я отдельно вывел ФОТ и расходы на ИИ. Уволенный человек не превращается в бесплатный агент. Он превращается в набор вычислений, проверок, повторных попыток и зависимостей от чужой инфраструктуры.

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

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

Продажа обещания «эта задача будет выполнена» приближает софт к сервисному бизнесу. Придётся считать себестоимость результата, долю неудачных попыток, цену контроля и то, кто платит за ошибки. Количество лицензий на красивый интерфейс перестаёт объяснять происходящее.

В аутсорсе та же проблема видна без калькулятора. Пока продаёшь часы, ускорение производства сокращает то, за что выставляешь счёт. Можно какое-то время продавать вчерашнюю трудоёмкость по сегодняшней себестоимости. Но конкуренты тоже умеют считать.

Поэтому человеко-час умер раньше программиста. У программиста ещё есть возможность продавать работающую систему. У часа такой возможности нет.

Битва маркетинга с продажами

Но ФОТ вендора это не только R&D. Процентов 50-70 команды это маркетинг, продажи, бэкофис. Им тоже достанется. На ранних этапах хотелось положить продажи и маркетинг в одну клетку и поделить на общий коэффициент. Получилось бы аккуратно. Аккуратность — частая причина неправильных моделей.

В подборке Amra & Elma приводятся снижение −53% вакансий на рутинное исполнение в маркетинге за два года и +29% для стратегических ролей. Но для меня главный сюжет здесь даже не в скорости производства рекламных материалов.

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

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

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

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

И здесь у большого вендора обнаруживается преимущество, которое дешёвый код не отменяет. Он уже продаёт этим клиентам. Новый продукт можно принести в существующий аккаунт, внедрить в существующую инфраструктуру. Для десяти продуктов не обязательно нанимать в десять раз больше продавцов.

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

Рост бюджетов в чужом огороде

«Но спрос на софт вырастет».

Конечно. В июльском прогнозе Gartner расходы на ПО в 2026 году — $1,468 трлн, рост на 15,5%. Там же прямо указано, что прирост концентрируется вокруг ИИ, а общий рост рынка не распределяется поровну между его участниками.

Теперь найдите на этой карте свой расчётный счёт.

Рост бюджетов на модели, инфраструктуру и хранение не обещает роста выручки вашему продукту. Рост выручки вашего продукта не обещает сохранения численности вашего отдела. А рост числа написанных программ не обещает, что за каждую из них вообще кто-то заплатит.

В пульте разобраны три одновременно работающих механизма.

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

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

Вычитание: модель забирает задачу, ради которой раньше приобретали отдельный инструмент. Потребность в результате сохранилась, покупка исчезла. Здесь бесполезно доказывать, что софта в мире станет больше. Покупали конкретно вас за конкретную работу.

Gartner прогнозирует распространение малых команд с 15% организаций в 2026 году до 60% к 2029-му и одновременно ожидает роста потребности в инженерах: спрос должен обогнать повышение эффективности.

С малыми командами у нас консенсус. Дальше он заканчивается. Я считаю, что Gartner не учитывает вычитание спроса моделями. В собственную разработку заказчика действительно может прийти больше инженеров. Из бюджета на покупной продукт они при этом унесут деньги вместе с работой. Для вендора утешение слабое.

Любимый аргумент «работы хватит всем» требует как минимум адреса того, кто эту работу оплатит. Количество нерешённых проблем в мире само по себе фонд оплаты труда не формирует.

Крутите сами

У пульта два связанных модуля.

Первый считает продуктовую команду. Задаёте исходную численность, ускорение работы, цену координации и переделки до и после. Получаете новую потребность в людях, вклад каждого механизма и мощность команды. Можно задать ухудшение. Можно поставить всё без изменений и получить исходный результат. Функция «автор всегда прав» в расчётное ядро не включена.

Второй собирает вендора целиком. Есть две заготовки: 125 и 3 000 человек. Разработка приходит из первого модуля; коммерция, поддержка, внедрение и администрация считаются отдельно. Можно менять рост числа клиентов и то, сколько выигрыша компания направляет в дополнительный выпуск.

При базовых параметрах и сохранении прежнего выпуска малый вендор получается примерно 125 → 71, крупный — 3 000 → 1 476. Это расчётные структуры компаний при заданных множителях, не результаты переписи софтверной индустрии.

Интереснее переключить крупного вендора с экономии на выпуск:

Второй вариант — около 72 малых команд вместо 32 больших. Каждой можно дать смежную задачу или продуктовую линию. Третий — компания смогла найти клиентов для расширенного предложения. Люди возвращаются прежде всего в продажи, поддержку и внедрение; разработка в этих двух вариантах одинакова.

Ручка «50%» стоит посередине геометрической шкалы между прежним выпуском и использованием всего исходного продуктового штата. Это не обещание сократить календарный срок вдвое. И слово «выпуск» не превращается в «выручку» автоматически.

ФОТ показан отдельно от вычислений. Средняя зарплата в модели фиксирована, поэтому доля ФОТ следует за долей штата. Счёт за ИИ находится рядом: экономия на сотрудниках и экономия денег — разные показания.

Под пультом есть формулы, допущения и источники. Возражение «у нас переделок меньше» теперь можно ввести числом. Возражение «у нас всё сложнее» всё ещё принимается, но потребует расшифровки.

Парадокс испуганного рынка

Допустим, вы решили не сокращать людей. Разработка подешевела — прекрасно, выпустим больше продуктов, быстрее проверим гипотезы, заберём соседние ниши.

Рациональное решение. У конкурентов оно тоже рациональное.

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

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

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

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

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

Для малого вендора отсюда ставка на скорость решения и глубину своей предметной области. Для крупного — на расширение портфеля внутри существующей клиентской базы. Одинаково автоматизировались, по-разному воспользовались результатом.

«Вы не первые» — утешительный неприз

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

Документы после появления настольных издательских систем не исчезли. Старое распределение работы между набором, вёрсткой и подготовкой к печати просто исчезло. Точно так же потребность в качественном ПО не выдаёт бессрочной гарантии каждому участнику сегодняшнего процесса.

Фраза «функция останется» часто звучит как обещание сотруднику. Хотя функция вполне способна остаться у другого сотрудника, в другой компании или в составе чужого сервиса.

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

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

Право на следующий проект

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

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

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

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

Платформу, на которой работают малые команды, тоже кто-то должен строить. Исполняемые сценарии, среды проверки, управление доступом, наблюдаемость и откат не возникают из надписи AI Native. Если вы сократили тех, кто это умеет, у вас осталась фабрика по производству инцидентов.

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

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

Фаза Луны настраивается плохо. Всё остальное — перед вами.

Крутите ручки, пока это ещё ваша работа.

Хау, я всё сказал.