Топ постов Всеволода Викулина
(по мнению Всеволода Викулина)

За последнее время я написал несколько действительно хороших материалов. Но мне решительно не нравится, что еще не все их прочли. Давайте это исправлять!

Посты

- Почему все делают AI-пилоты, которые я ненавижу

- Почему вам должно быть пофиг на рисовалки агентов

- Как я очень очень не люблю векторный поиск

- Уже пора не делать агентов, а делать агентов, которые делают агентов

- Как мы настраиваем метрики качества через пирамиду

- Как оценивать инженеров через бодрость

- Основный принцип инференса LLM. Разобрался, и мир абсолютно понятен

Статьи

- Реальная автоматизация: почему внедрения AI‑агентов проваливаются — и что с этим делать

Видео

- Как мы внедряем GenAI в клиентскую поддержку

- Стратегия внедрия AI-агентов в корпорации

Вам LLM побыстрее или подешевле? Выберите только одно

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

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

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

И иногда он даже может занимать памяти больше, чем миллиардные веса модели.

ТУТ НЕМНОГО МАТЕМАТИКИ, БОРИТЕСЬ ИЛИ ПРОПУСКАЙТЕ

KV-кэш занимает =

2 (K и V) × слои × число KV-голов × размер головы × байт × длина контекста

Допустим, у нас 60 слоёв, 8 KV-голов, размер головы 128, и храним кэш в fp16:

2 × 60 × 8 × 128 × 2 = 245 760 байт ≈ 246 КБ на токен

Тогда, если контекст 2000 на 1 запрос:

245 760 × 2000 ≈ 0,49 ГБ =

= Полгигабайта памяти. На один запрос.

Сева, ну и что нам с этих полгигабайта?

Память = размер модели + батч × размер KV-кэша

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

Возьмём модель 35B в fp8 — это 35 ГБ. Если батч маленький, KV-кэш мал, на него можно забить. Но если батч 100, то кэш уже 50 гигабайт — больше, чем сама модель, и основное время будет уходить на его загрузку.

Итого очень понятный размен: больше батч — мы загрузили модель 1 раз и параллельно предсказываем весь батч. То есть больше пропускная способность видеокарты (токены в секунду), то есть можем держать больше запросов, то есть нужно меньше карт. Но при этом больше KV-кэш, дольше наш пользователь будет ждать своего ответа.

Можно легко построить график, как время между токенами зависит от пропускной способности карты (я Клод вроде справился). Если интересно, в комментах напишу промпт формулы, как такое рисовать.

Сева, а что нам делать-то?

Учиться терпению! Ну или платить. Очень простой план:

Шаг 1. Думаем, сколько пользователь готов ждать. Обычно ничего умнее, чем 5 секунд, не придумывается. Интересно, у всех так?

Шаг 2. Прикидываем пиковый RPS в сервис. Потом умножаем на 1.5, потому что прикинули плохо.

Шаг 3. Берём 1 карту, берём корзинку входных запросов (с продовым распределением, чтобы KV-кэш был честный). Бенчим ваш инстанс (команда vllm bench serve). Смотрим p50/p95/p99 перцентили. Расстраиваемся.

Шаг 4. Не хватило — делаем карты ×2, батч падает в 2 раза, время ответа падает по нашему графику. Правда, не в 2 раза, а процентов на 20, увы. Повторять до целевых 5 секунд.

Шаг 5. Видите, что вам нужно 100500 карт — сначала расстраивайтесь. А потом думаете. Может, они могут немножко подождать?))) Я там стриминг намучу, UI красивый сделаю, мемы смешные буду показывать, пока ответ загружается. И на одной H100 как-нибудь протянем...

Говорила мне мама, терпение — золото. 30 лет прошло. И только сейчас до меня дошло.

Первый обзор научной статьи в этом канале

Я не фанат читать свежие статьи. Сам когда-то занимался физикой и понимаю: 99 % работ никогда не доходят до применения. Читать сто статей, чтобы найти золото, я не могу — я не металлоискатель. У меня свой метод.

Я статейный ждун. Жду, когда компании, у которых R&D-отдел в сто раз больше моего, перепробуют все эти статьи и найдут, что реально работает. А потом хитрый ждун про это узнаёт: от знакомых, из пресс-релизов или из тех же статей, но уже от самой компании — с комментарием, где оно работает в проде.

Сегодня смотрим на метод, которого я дождался, — AlphaEvolve. По слухам, его уже вовсю применяют наши большие западные коллеги. А теперь и я сам убедился в адекватности подхода. Садитесь поудобнее.

Что такое AlphaEvolve

Статья Google DeepMind.

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

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

Что этим методом наоптимизировали в самой статье:

— планировщик Borg: 0,7 % всех мощностей Google, больше года в проде
— FlashAttention: в одной боевой конфигурации инференса ядро на 32 % быстрее
— и даже побили рекорд перемножения комплексных матриц 4×4

Но применять можно к чему угодно. Хоть к классификации текстов: тюним промпт по F1 на обучающей выборке, финально меряем на тестовой (только не перепутайте!).

Почему я думаю, что за этим будущее

Одно слово. Интерпретируемость. Это основная проблема всех AI-моделей. А тут вы буквально видите, что «оптимизатор» выучивает из обучающей выборки.

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

Ещё вы можете явно задать правила оптимизации: про это пиши, про это не пиши. Настоящий рай для любителей всё контролировать (мне, например, очень нравится).

Что вам надо делать сейчас

Важно: это работает, но только на крупных моделях, которые умеют в длинный контекст. Ваш любимый 1.5B Qwen не вытянет. Но на топ-тир моделях оно заводится.

А если нужно подешевле, то давайте дистиллировать результат в веса любимого Qwen'а. И весь такой цикл работает по кнопке: автоматически подобрали промпт на крутой модели, автоматически продистиллировали в веса маленькой.

Думаю, вскоре и обычные Qwen'ы научатся так делать.

И нафига тогда я отличия Adam от SGD в универе учил?

Как стать AI-native компанией

AI всегда был гонкой инфраструктуры. Если вы хотите крутые AI-продукты, пожалуйста, сделайте логирование всех данных, сложите их в огромное хранилище, потом варите из этого таблички, а сверху табличек обучайте модели на кластере. Хотите покруче — переходите на новую инфраструктуру. Через 2 года сможете. Чтобы варить лучшую AI-кашку, нужно иметь дорогой горшочек. Почти из золота.

Мне, кстати, никогда это не нравилось. Я люблю 80% эффекта за 20% усилий. Поэтому мне нравится искать дырки в заборах: нетривиальные решения, которые срезают дорогие и долгие углы. Вот, например, последняя дырка в заборе — как мы описываем процесс для автоматизации через агентов. Дешево и быстро. А дорогие и долгие процессы мне не нравятся. Как-то неспортивно.

Вот сейчас открылась огромная дырень в заборе технологичности. И я просто кайфую. Готовы узнать какая?

AI может сам писать код. Наверное, вы ожидали инсайда покруче. Давайте еще раз. Дорогая инфраструктура — это код. AI может сам писать код. Так должно стать понятнее.

Нету хорошего интерфейса для разметки? Навайбкодь его. Нет всех тулов для агентов? Навайбкодь их. Нету бизнес-описания процесса? Ах да, только что рассказывал.

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

Ценность софта будет падать. Я допускаю, что через год Codex за 2 недели работы сделает с нуля неплохую A/B-платформу. Куда тогда инвестировать, если не в инфраструктуру?

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

А если у вас есть бодрая опытная команда, она может собрать AI-экскаватор, которым уже можно дырявить огромные бетонные стены. И загребать ковшом тонны профита.

AI-native — это люди. А не GPU, хранилища, кластера и крутые платформы. Главное — собрать таких людей. Ну и чтобы они потом не разбежались.

Вы ведь не уйдете, правда?

Всеобъемлющая статья про инференс LLM

Многие у меня спрашивают, как посчитать GPU и как после этого сохранить рассудок. Потому что насчитали столько, что даже начальник, который очень-очень любит ИИ, не окнет.

Теперь у меня есть для вас решение: прочитать мою статью и начать оптимизировать насчитанное.

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

- Как устроен инференс LLM
- Как оценить, сколько на него нужно GPU
- Какие есть методы оптимизации
- В каких движках это релизовано

Читайте, делитесь с друзьями.

И задавайте вовпросы в комментариях или в личные сообщения @seva_batareika.

Кто управляет разработкой AI-проекта

Несколько лет назад во время очередного релиза я понял, как называется моя профессия. Проджект-менеджер. Почему-то многие фыркают на это название. Ну, деливери-менеджер. Ну ладно, AI-деливери-менеджер. Так точно должно звучать круто. Сейчас обсудим, что это за зверь и как им стать.

В чем задача?

Довести проект до прода. И чтобы он был успешным для бизнеса. Как вы понимаете, учитывая плачевную статистику AI-проектов, сделать это сложно. А чтобы ваши проекты были успешными, вам одновременно надо иметь:

— Техническую адекватность. Вы должны хорошо знать ML, базово — бэкенд, немного фронтенд и продакт-менеджмент. Не лучше всех в команде, но достаточно, чтобы выслушать профессионала и понять его.

— Хорошие софты. Лидерство. Короче, чтобы с вами было хорошо и приятно работать.

— Любовь к принятию решений. Вы не самый сильный технарь, но вы должны брать на себя ответственность за финальное решение. Вам должно быть ОК принимать решения в условиях неопределенности. И отвечать за принятое.

Откуда такие берутся?

На самом деле пересечение этих трех осей довольно редкое. Такой милый технарь-решала (прям мой портрет, ей-богу!).

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

Хорошим проджект-менеджером AI-деливери-менеджером можно стать за несколько лет внедрения реальных кейсов. Успешного внедрения.

Карьерные перспективы

Это очень-очень дефицитная профессия. Ее уже не хватает, и дальше будет не хватать все сильнее. Взять этот ваш AI, собрать команду головорезов технарей и нанести непоправимую пользу бизнесу — это будет все востребованнее.

Наносить пользу можно в разных масштабах: один агентик в соло, пять агентиков с командой — и вот ты уже трансформируешь огромную операционную функцию. Дальше можно и всю компанию!

А что дальше?

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

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

Кому можно вайбкодить и как это делать

Управление AI-агентами очень похоже на управление людьми. Это мало кто в индустрии понимает, но я попробую вас убедить на самом простом примере — вайбкодинге.

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

Базовая теория управления от Всеволода Викулина

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

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

— Вы не эксперт, а исполнитель эксперт. Декомпозировать сами вы уже не можете. Но совсем не контролировать нельзя, а то наделает всякого. Вы не контролируете его по ходу работы, а ставите конкретные KPI, которые он должен выполнить. Например, пройденные тесты, скорость работы и тд. Но не забывайте тут закон Гудхарта.

— И вы эксперт, и исполнитель эксперт. Идеальная комбинация. Можно пробовать оба варианта: и KPI навесить (он же эксперт, сам разберется), и расписать, что конкретно делать, если вы считаете, что вы самый умный (у меня так).

— Ни вы, ни исполнитель не эксперты. Ну, вы понимаете, что будет.

Не вайбкодер, а багодел

Может ли менеджер навайбкодить простой личный сайт? Может, даже если он не разбирается в разработке (я, кстати, навайбкодил). Клод в этом давно экспертен, а результат легко проверить глазами.

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

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

Вместо резюме

В менеджменте агентов нет ничего уникального. Вы на самом деле всё это уже умеете делать со своими коллегами.

Хотя нет, всё-таки есть. Агент не принесёт вам оффер, что другой человек платит ему x2 за те же токены. В OpenAI до этого ещё не додумались. Пожалуйста, не подсказывайте им.

Решаем бизнес-кейс

У большинства сложных проблем нет единственно правильного решения. На своих занятиях я люблю разбирать их в виде кейсов.

Делаем автоматизацию бухгалтерии. Взяли последнюю GPT: все работает, метрики хорошие. Но данные нельзя отдавать во внешние API, поэтому пересаживаемся на опенсорс. Берем любимую версию Qwen, тюним промпт — качество сильно отстает. Перед вами встает вопрос: что делать дальше?

Базовые мысли

Если на GPT все работает, значит, вы уже собрали весь контекст. То есть все знания у модели есть, просто ей не хватает интеллекта, чтобы правильно их использовать. Значит, интеллект нужно как-то добавить. Каким образом это можно сделать:

1. Взять LLM побольше.
2. Дать LLM порассуждать подольше.
3. Сделать сложный харнесс: контекст-инжиниринг, мультиагентность, вот это все.
4. Дообучить модель.

В чем размен каждого варианта

При одинаковом качестве важны два свойства:

1. Стоимость работы: а) сколько GPU нужно купить; б) сколько людей нужно, чтобы решение не развалилось.
2. Стоимость улучшения: насколько дорого переходить на новую технологию.

Разложим все четыре варианта по этим двум осям.

1. LLM побольше. Дорого из-за GPU. Поддерживать недорого: просто следим за инференсом. Улучшать дешево: просто подменяем модель и получаем тонны профита.

2. Рассуждать подольше. Также как пункт 1, только платим не столько за размер модели, сколько за токены.

3. Делать харнесс. По железу может быть дешевле пунктов 1 и 2, потому что можно работать с моделями поменьше (например, рекомендую харнесс Т-Серч, реально помогает). Но улучшать его сильно дороже: новая модель в старом харнессе может не дать аплифта, и его придется полностью переделывать. LangChain переделывал свой харнесс Open Deep Research 3 раза за год.

4. Дообучать. Инференс можно гонять на модели поменьше, зато нужна ML-команда. Вы попадаете в проблему data drift и постоянного переобучения. Новые модели тоже придется дообучать, и не факт, что это получится тем же кодом.

Что выбрать

Все зависит от вашей ситуации.

— Если кровь из носа нужен эффект с самой дешевой экономикой прямо сейчас, делайте 4.

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

— Если вы богатый Буратино, идите в 1 или 2: через 5 лет скажете себе из прошлого спасибо. Это, кстати, известный принцип — The Bitter Lesson. Его в 2019 году сформулировал Ричард Саттон, один из отцов современного RL: в долгосрочной перспективе всегда выигрывают методы, которые масштабируются вычислениями.

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

Вы же помните, что мы решали бизнес-кейс?

Кто должен внедрять AI в корпорацию? Новая статья

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

Мы с командой довольно сильно продвинулись в этом. Ключевые выводы я написал в новой статье. Там вы найдете:

- Почему возникают новые роли

- Кто такой Forward Deployed Engineer

- Что будет с профессией в будущем, и какая роль будет вместо нее

Как всегда, жду ваши вопросы/мысли в комментариях или в личных сообщениях.

Мне сегодня 31

AI-эксперт — он как вино. Хорошеет с каждым годом!

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

Кстати, если хотите мне что-то подарить — подарите мне внимание и прочитайте мою последнюю статью!

Только ради бога, не просите просто саммери у ChatGPT. Это ровно тот контент, которым жалко делиться с ИИ.

Друзья, многим стали писать в личку по поводу «обучения у меня». Наконец-то стал чувствовать себя знаменитым)

Это спам. У меня нет никаких наставничеств/ коучингов/менторств и тд.

Единственное, что у меня есть это совместный курс с ВШЭ для руководителей.

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

На остальное не обращайте внимание. Берегите время и деньги.

Нас ждёт очередная технологическая трансформация

Угадайте, про что нобелевский лауреат по экономике Роберт Солоу сказал: «*** видны уже везде, кроме статистики производительности».

Про AI-агентов? Нет. Про компьютеры. Цитата 1987-го года.

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

GPT — это GPT

Есть класс технологий, который экономисты называют General Purpose Technology, технологии общего назначения. Сокращённо GPT. Иронично, правда?

Эта технология проникает во все сферы и меняет то, как мы живём и работаем. Примеры: паровой двигатель, электричество, компьютер. А теперь, похоже, и AI.

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

Нельзя просто так взять и внедрить GPT

Сама по себе технология общего назначения приносит мало. Деньги появляются, когда под неё перестраивают весь способ работы.

Классика — электрификация заводов. В конце XIX века фабрика работала от одной большой паровой машины. Она крутила вал под потолком, а от вала ремнями приводились все станки. Сначала люди просто выкинули паровик и поставили на его место большой мотор. И ничего не изменилось.

Эффект пришёл, когда до инженеров дошло: теперь мотор можно поставить на каждый станок. Исчезли валы, станки расставили по ходу производства. Производительность скакнула. Ушло на это около 40 лет.

Это называется комплиментарные инвестиции. Это вложения во всё, без чего технология не работает: образование сотрудников, перестройка процессов, инфраструктура и тд. По оценкам экономистов, в ИТ-трансформации на них приходилось 90% всех вложений.

Деньги будут, но не сразу

В начале перестройки эффекта не видно: затраты уже есть, а отдачи ещё нет. Ученые называют это J-кривой (см. картинку). Сначала показатели проседают, скептики в этот момент кричат: пузырь, пузырь!

Солоу пошутил в 1987-м, а во второй половине 90-х рост производительности в США заметно ускорился. И две трети этого ускорения экономисты приписали как раз ИТ. Компьютерам понадобилось лет десять. Электричеству — сорок.

Что вам делать с AI

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

Сначала определитесь, где новый паровой двигатель даст вам самое большое преимущество. И уверенно перестраивайте эту сферу на AI-рельсы. Вкладываясь в экспертизу команды и инфраструктуру.

Как именно это делать — обсудим вместе. И сделаем. Обещаю, быстрее, чем за 40 лет.

Две стадии AI-трансформации

Вам нужно трансформировать какую-то функцию: поддержку, бухгалтерию, разработку. Как подходить к такой объемной задаче? Мы с командой нашли рабочую схему. Рекомендую применить или хотя бы детально ознакомиться.

Стадия 1. R&D

На старте ничего не понятно. Ясно, что нужны агенты, а как без них. Но как именно нужны — непонятно совсем.

Вам нужна небольшая и очень экспертная команда. Такая, которая умеет выдвигать гипотезы и не демотивируется, когда 99% из них проваливаются.

Фокусируйте команду не на итоговой метрике (например, уровне автоматизации), а на скорости проверки одной гипотезы. Автоматизацию будете улучшать потом, когда станет понятно, что работает.

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

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

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

Стадия 2. Масштабирование

R&D закончился успехом, но метрики процесса не изменились, потому что массово в проде еще ничего нет. Теперь технологию нужно внедрять, и главная проблема этой стадии — внедрять придётся очень много. Здесь и появляются новые роли вроде FDE, про которых я писал в статье.

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

Главный рычаг, который мы нашли, — агенты, ускоряющие само внедрение. Разбейте CJM внедрения на участки, найдите бутылочные горлышки и встройте агента в каждое (подробнее про эти горлышки — в книге «Критическая цепь» Голдратта).

То есть секрет успешного внедрения — сразу автоматизировать команду внедрения.

И R&D после первого успеха можно не сворачивать. Он может найти новые технологии, которые поднимут ROI FDE-команды в несколько раз.

Что вы накапливаете во время стадий

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

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

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

Только не переживайте, что это работа скоро закончится. Человечество столько насоздавало процессов. На нашем веку хватит. Даже бок о бок с агентами.