Кто управляет разработкой 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-команды в несколько раз.

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

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

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

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

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