FDE: Новая граница в инженерных ролях, основанных на ИИ

За последний месяц я встретил четырех друзей, готовящихся к смене карьеры — фронтенд-разработчика, архитектора решений, продуктового менеджера и традиционного инженера-алгоритмиста. У них разный опыт, возраст и город, но все они задали один и тот же вопрос на английском сокращении: FDE [2] — стоит ли мне этим заниматься?

FDE, полное название Forward Deployed Engineer [2]. Два года назад это был сленг внутри Palantir, а сегодня он тихо превратился в стандартное приветствие рекрутеров, частую позицию в вакансиях и один из кандидатов на звание «самой ценной должности в эпоху ИИ» в социальных сетях. В мае 2026 года OpenAI прямо с таким названием создала Deployment Company [3], первоначальные инвестиции составили 4 миллиарда долларов, и четко заявила, что будет отправлять инженеров непосредственно на объекты клиентов, интегрируясь в их рабочие процессы; команда Applied AI от Anthropic также одновременно набирает FDE в четырех часовых поясах. Этот термин превратился из внутреннего сленга в явное понятие всего за год с небольшим.

В своей предыдущей статье «Письмо супериндивидууму» [4] я обсуждал «двигатель человека» — любознательность, самообучение, внутреннюю мотивацию и практические навыки, и как они пробуждаются в полном Closed-loop. Однако человек не существует в вакууме; его необходимо «поймать» конкретной системой координат должности. Если супериндивидуум — это «сырьё» производственных отношений эпохи ИИ, то FDE — это наиболее явная форма должности, которая возникла на рынке за этот год.

На мой взгляд, FDE не попадает ни в одну из этих категорий — ни в консалтинг, ни в аутсорсинг. Он ближе всего к супериндивидуумам, причем отличие заключается в том, что FDE — это организованный супериндивидуум в промежутке между «модельной компанией» и «клиентом».

Знаете ли вы, откуда взялось слово Forward Deployed? Оно происходит из военного термина Forward Deployed Forces, обозначающего войска, развернутые за рубежом или на передовой и способные оперативно реагировать, в противоположность силам, оставшимся на базах на родине. Palantir перенесла этот термин в IT-сферу в конце 2000-х годов, чтобы описать модель работы, при которой инженеры отправляются из штаб-квартиры и живут на объектах клиентов; даже внутренние команды получили названия по военному алфавиту — Delta и Echo. Теперь OpenAI и Anthropic снова берут этот подход на вооружение — и это не случайность: суть дела — отправить инженеров на передовую — осталась неизменной.

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

Является ли FDE консалтинговой компанией в одежде ИИ? Где проходит граница между ним и традиционным консалтингом?

Является ли FDE более продвинутой формой аутсорсинга программного обеспечения? В чем разница между ним и моей текущей работой в качестве подрядчика?

Подхожу ли я для позиции FDE? Какие типы людей будут усилены этой ролью, а какие — раздавлены?

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

Если бы можно было выбрать только одно событие, чтобы обозначить момент возрождения FDE в этом цикле, автор выбрал бы 11 мая 2026 года — в этот день OpenAI объявила о создании Deployment Company [5], при этом COO Брэд Лайткап покинул свой прежний бизнес-направление и перешел на должность специальных проектов, напрямую отчитываясь перед Сэмом Альтманом, чтобы полностью посвятить себя этому делу. В ту же неделю OpenAI приобрела британскую AI-консалтинговую компанию Tomoro, сразу же включив в новую компанию 150 Forward Deployed Engineer и Deployment Specialist.

Стоит отметить, что на странице вакансий OpenAI одновременно размещено более десятка позиций FDE: в Сан-Франциско, Нью-Йорке, Вашингтоне, а также по отраслевым направлениям — Life Sciences, Semiconductor, Gov и другим, причем сама позиция рекрутера FDE [6] также вакантна. Аналитики оценивают, что эта команда расширится до 2000–4000 человек за три года. Это не масштаб исследовательской группы — это настоящая армия.

Anthropic практически повторяет те же действия. Должность Forward Deployed Engineer в команде Applied AI [7] одновременно открыта в шести городах: Бостоне, Нью-Йорке, Сиэтле, Сан-Франциско, Вашингтоне и Лондоне, с требованием к командировкам на объекты клиентов в объеме 25–50%. Одним из недавно часто цитируемых примеров является финтех-компания FIS — в своем объявлении она прямо указала: «Команда Applied AI и forward-deployed engineers от Anthropic уже интегрированы в FIS для совместной разработки Financial Crimes AI Agent и передачи знаний FIS, чтобы она могла самостоятельно расширять количество агентов в будущем».

В этой фразе скрыта настоящая суть работы FDE. Это не предпродажный архитектор, не SDR и не проповедник, приходящий обучать клиентов. Это инженер, который приходит с моделью и живет внутри кодовой базы клиента. Брэд Лайткап выражается еще яснее: «Наши клиенты говорят нам, что им нужна способность перейти от пилотного проекта к производству. Deployment Company — это когда мы встраиваем наших инженеров в их команды и предоставляем им все необходимые ресурсы для реализации».

Нарисуйте это в виде диаграммы — взаимоотношения между тремя сторонами станут совершенно ясны:

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

Вот почему FDE в этот цикл был одновременно возрожден двумя ведущими компаниями-разработчиками моделей — за этим стоит нечто большее, чем просто «мы тоже хотим учиться у Palantir и заниматься консалтингом». Это устройство сбора сигналов от модели: самые интенсивные болевые точки клиентов на передовой можно уловить только тогда, когда у компании есть свои люди на месте, поскольку требования, передаваемые через партнеров, всегда искажены. Anthropic идет по гибридному пути: одновременно самостоятельно развивает FDE и создает совместные предприятия с консалтинговыми компаниями и гигантами частного капитала для развертывания. Один подход более ориентирован на самостоятельное управление, другой — на экосистему, но суть у них одинакова: компании-разработчики моделей больше не просто поставщики API — они напрямую отправляют инженеров внутрь продуктов клиентов.

Следующие вопросы — два самых распространенных сравнительных вопроса: где проходит граница между FDE и традиционным консалтингом (таким как McKinsey, Accenture)? И это то же самое, что и нам знакомое аутсорсинг программного обеспечения?

Многие, впервые услышав описание работы FDE, сразу же думают: «Это же просто новая версия McKinsey и Accenture!»

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

Поместив эти два элемента рядом в таблице, различия сразу станут очевидны.

Самым важным моментом в этой таблице является строка «Амортизация активов».

Традиционная консалтинговая логика максимальной прибыльности основана на повторном использовании активов — один и тот же план для одного банка слегка дорабатывается и продается следующему; цифровой playbook для розничной отрасли можно многократно применять для тридцати клиентов. Это фундаментальная экономическая модель, на которой Accenture, Deloitte и McKinsey Digital росли последние тридцать лет.

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

Знаете ли вы, что такое Product Overhang? В предыдущей статье «Для супериндивидуумов» [4] я объяснил этот термин: возможности модели превышают существующие формы продуктов, но отсутствуют точка входа, права доступа и контекст для их реализации. Суть ценности должности FDE заключается в том, чтобы превратить висящие в воздухе Overhang из клиентских сценариев в конкретный работающий продукт. Клиенты покупают не квоты на вызовы API модели, а способность «реально внедрить этот набор Overhang в мой бизнес».

Это также объясняет различия в строке «структура проекта». Стандартная структура консалтингового проекта включает SOW (Statement of Work) + WBS (Work Breakdown Structure) + этапные приемки: в контракте четко прописывается, что должно быть доставлено, когда и по каким критериям будет проводиться приемка. Эта структура предполагает, что цели уже четко определены до подписания контракта.

Проекты FDE не работают по этой схеме. Самая частая фраза клиентов: «Я знаю, что ИИ должен мне чем-то помочь, но я не знаю, чем именно». Сама цель является частью проекта. Поэтому FDE не берет SOW, а берет mission — относительно расплывчатое направление; затем с помощью итераций постепенно проясняет это направление; и в какой-то из итераций превращает накопленное понимание модели в продукт.

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

Линия «экономический ров» — самая тонкая. Экономический ров FDE — это реальное ощущение границ возможностей модели: сколько реальных сценариев клиентов вы запустили в этом месяце, столько же вы знаете, что Claude 4.7 может делать, а что нужно ждать до Claude 5. Это ощущение нельзя вписать в презентацию или базу знаний — оно может существовать только в головах инженеров, которые работали с этим за последние 90 дней.

Так что, когда кто-то скажет: «FDE — это просто новая версия Accenture», можно ответить так: инженеры Accenture перепроектируют процессы клиентов, а FDE — заново исследуют границы моделей. Активы первого могут сохраняться десять лет, а активы второго нужно восстанавливать каждые 90 дней.

Если утверждение «FDE — это новая версия Accenture» — это первое неправильное понимание, то «FDE — это дорогостоящий аутсорсинг программного обеспечения» — это второе. Это понимание более вводящее в заблуждение, поскольку поверхностные доказательства кажутся очень убедительными: FDE действительно приходит на объекты клиентов для написания кода, действительно настраивает функции под бизнес клиента и действительно отвечает на рабочие часы клиента. На первый взгляд, он не отличается от аутсорсингового инженера.

Но достаточно лишь взглянуть на обратную связь, чтобы разница стала очевидной.

Самое важное различие на этом рисунке — не то, насколько проста верхняя часть, а то, что в нижней части появилась обратная связь, направленная к компании-разработчику модели. Эта цепочка не является декоративной — она является настоящей причиной существования должности FDE. Разбив эту разницу, можно выделить как минимум четыре пары сравнений.

Подключаемые вещи разные. Внешние подрядчики работают по SOW — списку требований, четко определенному до подписания контракта: какие функции реализовать, какую технологическую стек использовать, по каким критериям принимать результат и как компенсировать нарушения. FDE работает с миссией — клиент сам не знает, чего хочет, и знает только то, что «ИИ должен как-то помочь мне». Основа SOW — определенность, основа миссии — исследование. Это совершенно разные подходы к запуску проектов.

Объем работы разный. Аутсорсеры выполняют частичную доставку — модуль, веб-сайт, пайплайн данных, после завершения сдают проект и уходят к следующему клиенту. FDE работает端到端 — от выявления бизнес-болей, выбора модели, проектирования продукта до анализа удержания и оттока реальных пользователей после запуска.

Система оплаты другая. Это наиболее контринтуитивно. Компания, занимающаяся моделями, отправляет FDE на объект клиента, и их главная забота — не только сколько гонораров будет получено за этот проект, а то, сколько токенов будет потреблено клиентом в дальнейшем? Станет ли он клиентом с высокой удерживаемостью? Расширится ли сотрудничество на другие бизнес-направления? Настоящим KPI FDE является долгосрочная кривая потребления токенов модели, а не цифра, указанная в акте приемки проекта.

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

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

Знаете ли вы — какова общая компенсация FDE в OpenAI и Anthropic? Согласно открытым данным Levels.fyi о программистах-инженерах Anthropic [8], медианная общая компенсация опытного SDE уже достигла 710 000 долларов США. Роль FDE сопряжена с более высоким риском — необходимо справляться с неопределенностью в возможностях моделей, неопределенностью в бизнесе клиентов и неопределенностью в форме продукта, поэтому, как отмечается в отраслевом обзоре [9], общий пакет компенсации для среднего и старшего уровня FDE в передовых лабораториях ИИ обычно находится в диапазоне от 350 000 до 550 000 долларов США, а у сотрудников уровня Staff и выше он может достигать 630 000 долларов США и выше. Эта зарплата платится не за «аутсорсинг часов», а за то, что человек берет на себя совокупный риск, связанный с «продуктом + клиентом + моделью». > Вспомните 2006 год, когда я только начал работать в одном из государственных предприятий Китая — тогда происходила цифровая трансформация, и консультанты Accenture, приглашенные нашей группой, получали ежедневную оплату в размере 3500 юаней и работали у нас несколько лет; в то время СМИ называли их «золотыми менеджерами». Позже я перешел в немецкую компанию SAP, которая даже ввела термин для этой профессии — консультант SAP стал символом «золотого менеджера». Отсюда можно сделать вывод, что зарплаты FDE будут расти в течение как минимум 24–36 месяцев, а спрос на них будет стабильно увеличиваться.

Аутсорсинг — это арбитраж труда, а FDE — это полевой сенсор. Смешивание этих двух вещей заставит заказчика ошибочно считать, что FDE можно нанять по методу SOW, а кандидаты будут относиться к роли FDE, как к аутсорсинговой работе. Обе стороны быстро столкнутся со стеной.

Многие ошибочно считают, что термин FDE был изобретен OpenAI. На самом деле, это не так. У него есть два исторических корня: один — от Palantir, другой — от компаний нового поколения, появившихся после 2023 года. Сравнив эти два корня рядом, можно лучше понять, чем на самом деле занимается эта должность FDE.

Сначала посмотрите на хронологию.

Первый корень — Palantir.

Palantir была основана в 2003 году Питером Тиелем, Алексом Карпом, Джо Лонсдейлом и другими; её первыми клиентами были американские разведывательные структуры. Сам Карп не имел технического образования — он защищал докторскую диссертацию по философии у Юргена Хабермаса во Франкфурте, а затем был привлечен Тиелем на должность генерального директора. Должность FDE возникла именно из-за этой нестандартной комбинации «CEO без технического бэкграунда + крайне конфиденциальные клиенты»: как прямо отмечается в обзоре 36Kr [10], в начале Palantir подвергалась жесткой критике со стороны разведывательных органов, поскольку инженеры не имели доступа к реальным бизнес-сценариям, а требования, проходя через многоуровневую передачу, искажались. Позже Palantir добилась того, чтобы собственные инженеры могли работать непосредственно на объектах клиентов, совместно с аналитиками разведки. Эта модель позже была систематизирована Шьямом Санкар и стала прототипом FDE.

К 2009 году FDE расширились на коммерческий сектор. При развертывании JPMorgan платформы Palantir Metropolis 120 FDE были внедрены для мониторинга внутренних угроз. С этого момента FDE перестали быть просто «отправкой инженеров в командировки» и превратились в систематизированный подход к внедрению клиентов: Foundry / Gotham действительно интегрировались в бизнес-процессы клиентов, а не просто передавались лицензии и уходили.

У Palantir при найме на FDE есть неочевидное требование — не требуется образование в области информатики. Это можно включить в раздел «Знаете ли вы?»

Знаете ли вы — Palantir FDE не требует степени по информатике? Согласно критериям найма Palantir, собранным SkillScouter [11], и официальной странице карьеры Palantir [12], Palantir открыто приветствует кандидатов не из сферы информатики: недавние hires в роли FDE пришли из областей машиностроения, экономики, философии и других. На самом деле, ключевые требования — это способность действовать при неполной информации и умение напрямую общаться с клиентами уровня C. Степень по информатике — это бонус, а не обязательное условие. Сам Карп является первым примером этого подхода — философ по образованию, который возглавляет команду FDE с backgrounds в физике, математике и философии.

Второй корень — это компания новой генерации, основанная после 2023 года.

После запуска ChatGPT в конце 2022 года OpenAI быстро осознала одну вещь: просто разместить API модели на документации и оставить клиентам самостоятельную интеграцию — это невозможно. Клиенты не хотели его не использовать, а просто не знали, как это сделать — у них были бизнес-задачи, но отсутствовала продуктовая форма. Поэтому OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, Decagon и другие компании начали массово нанимать FDE.

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

В статье Pragmatic Engineer о FDE [13] эта новая версия называется «встроенная в предприятия для решения реальных, конкретных и высокоценных задач с помощью Claude» — формулировка практически идентична той, что использовалась Palantir в прошлом, за исключением замены слова «данные» на «модель».

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

Общее: клиенты покупают не программное обеспечение. Они покупают «инженеров, которые решат мою проблему, вместе с инструментами». Это было необычно в истории корпоративного ПО за последние тридцать лет. SAP, Oracle, Salesforce продавали само программное обеспечение — инженеры существовали как вспомогательный ресурс, чтобы «сделать это ПО доступным для клиентов». Palantir делает наоборот: инструменты существуют как рычаг, чтобы «FDE могли решать проблемы клиентов». Новое поколение модельных компаний унаследовало эту инверсию — OpenAI продает не лицензию на GPT-4, а «наши FDE могут использовать GPT-4, чтобы автоматизировать вашу службу поддержки».

Разница: Эпоха Palantir ориентирована на интеграцию OPS — основное внимание уделяется интеграции данных, моделированию онтологий и управлению правами доступа. Новое поколение сосредоточено на реализации возможностей моделей — основное внимание уделяется проектированию Prompt, оркестрации агентов и оптимизации удержания. Первое похоже на усовершенствованную версию системного интегратора, второе — на расширенную версию продукт-инженера.

Еще один интересный факт: многие ранние FDE в Palantir позже стали предпринимателями или напрямую присоединились к компаниям нового поколения моделей. В ранних командах Anthropic, OpenAI, Sierra и Hebbia можно насчитать длинный список бывших сотрудников Palantir. Это не совпадение — сама должность FDE заставляет человека одновременно нести ответственность за риск продукта, риск клиента и инженерный риск, что по сути является тренировкой для предпринимателей. Автор предпочитает рассматривать Palantir как скрытый инкубатор стартапов: он воспитывает не просто инженеров, а группу людей, знающих, как двигать проект от нуля к единице даже при неполной информации. Два корня в конце концов сошлись после 2023 года.

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

Два местных предшественника

Первым предшественником был архитектор решений от облачного провайдера. За последние десять лет Alibaba Cloud, Tencent Cloud и Huawei Cloud сформировали целую команду Solution Architects (SA), которые представляют архитектуры клиентам, пишут POC, разрабатывают планы миграции и сотрудничают с командами по внедрению до вывода на продуктивную эксплуатацию. Внутри Huawei существует отдельная должность «инженер по внедрению», ответственная за реализацию проектов на объектах клиентов. Эта система уже выполняет 80% задач FDE, но ее фокус остается на досрочных этапах и развертывании — ответственность за полный цикл продукта лежит не на SA: при изменении требований необходимо проходить процедуру изменения, а при смене модели — ждать расписания из головного офиса.

Вторым предшественником стала новая должность, появившаяся в стартапах в области ИИ. MiniMax размещает в BOSS Zhipin вакансию «Эксперт по предпродажным решениям в области ИИ»; аналогичные позиции также размещают компании, разрабатывающие модели, такие как Moonshot, Zhipu, Tongyi и Hunyuan. Названия должностей немного различаются, но содержание описаний вакансий крайне схоже: понимание сценариев клиентов, создание демо-версий, настройка промптов, запуск RAG, составление планов доставки, взаимодействие с инженерными командами клиентов до вывода продукта на производство. Эта волна вакансий — настоящие «отечественные FDE».

Три различия в почве и воде

Локальное развертывание и соответствие требованиям к данным подавляют модель, основанную исключительно на вызовах. Требования отечественных корпоративных клиентов к тому, чтобы данные не покидали пределы территории, веса модели находились под контролем, а аудит был прослеживаем, значительно выше, чем на рынке США. В проекте FDE объем работы, связанный исключительно с вызовом API и выполнением запросов, может составлять лишь 30%, остальные 70% — это перенос модели в клиентский центр обработки данных, настройка аутентификации, интеграция с платформой данных и оформление соответствия требованиям.

Модельные возможности всё ещё догоняют SOTA, и пространство для развития сжимается до инженерного уровня. Американские OpenAI и Anthropic могут привлекать клиентов за счёт самих возможностей моделей; в Китае различия в возможностях Tongyi, Doubao, Kimi, GLM и DeepSeek не столь значительны, и клиенты больше обращают внимание на инженерные аспекты: оркестрацию агентов, качество поиска RAG, интеграцию инструментов и проектирование рабочих процессов. В Китае FDE соревнуются не тем, «насколько сильна моя модель», а тем, «смогу ли я реально запустить этот бизнес».

Предпочтения к оплате и темпы ценообразования на B-рынке отличаются от американских. Модель Palantir, основанная на «сначала размещении FDE, а затем взимании высокой абонентской платы», трудно копировать напрямую. Бюджеты клиентов в Китае связаны с ежегодными закупками, платежи чаще ориентированы на проекты, а бизнес-модель FDE обычно представляет собой гибрид абонентской платы, лицензирования на частное использование и проектной доставки.

Уникальная позиция: внутренний FDE

Многие внутренние команды ИИ крупных компаний начинают использовать модель FDE для обслуживания «внутренних клиентов». Инженеры из Alibaba Cloud PAI внедрены в Taobao, а у Tencent Hunyuan также есть аналогичный механизм для взаимодействия с WeChat и рекламными подразделениями. На JD указаны должности «инженеры по внедрению в отрасли», «инженеры по применению ИИ», «эксперты по интеллектуальным бизнес-процессам» — по сути, это внутренние FDE, которые обеспечивают энд-ту-энд реализацию возможностей команды моделей на стороне бизнеса. Это дает руководителям крупных компаний новую идею: несколько внутренних FDE, работающих непосредственно на стороне бизнеса, могут быстро запустить первый демо-проект и передать данные по ROI руководителям бизнес-подразделений — это разрушит корпоративные барьеры быстрее, чем десять встреч по согласованию.

В предыдущей статье «Письмо супер-индивидам» [4] я упоминал пять двигателей супер-индивидов: сильное любопытство, сильное стремление к исследованию и инновациям, высокая способность к самообучению, сильная внутренняя мотивация и хорошие практические навыки. Эти пять качеств — это входной билет для FDE, но не всё. Помимо этих пяти двигателей, позиция FDE требует ещё целый набор конкретных дополнительных качеств, а также есть несколько типов личности, которые явно не подходят. Я видел слишком много талантливых инженеров, перешедших в FDE, которые испытывали трудности с адаптацией — причина чаще всего не в способностях, а в характере и предпочтениях в работе.

Пять качеств, подходящих для FDE

Не избегайте продаж и общения. Ежедневная работа FDE — это не закрытая в комнате разработка кода, а прямое взаимодействие с CTO, руководителями бизнеса, закупками, юридическими и IT-специалистами клиентов. Типичный сценарий: клиентский CTO прерывает демонстрацию — реакция FDE не может быть «я вернусь и сделаю новую версию на следующей неделе», а должна быть немедленное открытие IDE, изменение Prompt и повторный запуск прямо перед ним. «Клиент здесь, я сейчас правлю» — это обычное состояние FDE.

Наслаждайтесь серой зоной. FDE не получает четкого PRD, а лишь фразу: «Мы хотим что-то сделать с ИИ». Сам клиент не может точно сформулировать, чего хочет, и ему нужен FDE, чтобы помочь превратить эту расплывчатую надежду в конкретную форму. Если вы можете действовать только при наличии четких требований, FDE будет вызывать у вас ежедневную тревогу.

Хорошая инженерная база, но не требуется 10x. FDE не требует, чтобы вы были самым чистым кодером или самым глубоким алгоритмистом в компании — ему нужно, чтобы вы могли реализовать полный цикл: сделать фронтенд с рабочей страницей, настроить бэкенд с работающим сервисом и подключить модель к источнику бизнес-данных. В мире FDE «приблизительно подходит» — это не недостаток, а достоинство.

Любит дорабатываться через обратную связь. В работе FDE много моментов, когда клиенты возвращают работу с требованием переделать: сегодняшний демо-презентация завтра получает отзыв «это не то, что я хотел»; решение, согласованное на прошлой неделе, на этой неделе требует переделки из-за нового руководителя клиента. Люди, подходящие для роли FDE, воспринимают такую обратную связь как топливо, берут на себя ответственность за весь цикл и не перекладывают вину на «непонятные требования».

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

Четыре категории людей, не подходящих для FDE

Технарь, который хочет прятаться в коде. FDE примерно 50% времени проводит не за написанием кода, а на встречах с клиентами, внутренней координации, обсуждениях продуктов и продвижении контрактов. Если ваш источник радости — четыре часа подряд без перерывов, написание кода, FDE приведет вас к длительному эмоциональному выгоранию.

Люди, которым нужны OKR, чтобы начать действовать. Цели FDE сосредоточены на клиентах, а не на вашей таблице производительности. Прогресс работы определяется вехами проектов клиентов, изменениями в возможностях модели и вашим собственным пониманием сценариев. Те, кто привык «сначала иметь OKR, чтобы понять, что делать», не найдут опорной точки.

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

Люди, которые сопротивляются коммерческому контексту. FDE должен понимать P&L клиента, ROI, процессы закупок и требования по соблюдению норм. Если вы по своей природе негативно относитесь к обсуждению денег, контрактов и бизнес-логики, работа FDE заставит вас чувствовать, что вы предаете свои технические идеалы.

Самопроверка

7 вопросов, каждый из которых соответствует реальной рабочей ситуации FDE. Если вы ответили «да» на 5 или более вопросов, стоит серьезно рассмотреть FDE; если на 3 или менее — рекомендуется быть осторожным.

1. Вы готовы ежедневно перераспределить 50% своего времени с кода на клиентские встречи, ответы на сообщения и звонки?

2. Когда клиент говорит вам: «Это не работает, я не могу объяснить почему», ваша первая реакция — любопытство или нетерпение?

3. Вам никто не написал PRD, сможете ли вы за неделю вместе с Claude Code создать прототип, который можно показать клиенту?

4. Одна и та же поставка, клиент попросил вас внести изменения в восемь версий — сможете ли вы сохранить способность к суждению, а не действовать механически?

5. Когда модель дает неверный ответ, ваша первая реакция — разработать резервный вариант или жаловаться на то, что модель плохая?

6. Вы готовы подписывать контракты, писать отчеты, проходить验收 клиентов и согласовывать合规-положения с юридическим отделом?

7. Вы готовы принимать быстрые прототипы и быстрые неудачи?

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

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

FDE — это не конец. Автор считает, что FDE — это лишь первая форма, получившая название в новом разделении труда. Впоследствии появятся Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher — все профессии, тесно связанные с клиентскими сценариями и требующие выращивания продукта в нечеткой зоне, получат свои собственные «前置部署» версии. Названия должностей будут меняться, но базовая логика останется неизменной: способности модели движутся вперед, а формы продуктов следуют за ними, а структура должностей перераспределяется в соответствии с рабочими процессами.

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

Для технических специалистов: FDE не требует, чтобы вы были самым сильным программистом в компании, но требует, чтобы вы были готовы перераспределить половину своего времени с кода на взаимодействие с клиентами. Если ваш ответ — «готов», то рынок только открылся, и набор в ведущие китайские компании по разработке моделей, облачные провайдеры и внутренние AI-команды крупных компаний ускоряется. Если ваш ответ — «не готов», это тоже нормально — в новой структуре разделения труда появятся и другие позиции для вас.

Для HR и OD: будьте внимательны к «расхождению между названием и сущностью». В вашей компании, возможно, уже работает несколько FDE, но их должности указаны как «эксперт по решениям», «архитектор отрасли», «инженер по применению ИИ». Идентифицируйте их, переклассифицируйте и создайте для них карьерный путь, соответствующий их реальным обязанностям — это эффективнее, чем нанимать новых сотрудников с нуля.

Для менеджеров: Режим FDE может применяться не только внешне, но и внутри. Создайте несколько «внутренних FDE» на стороне бизнеса, чтобы полностью интегрировать возможности команды моделей в бизнес-процессы — это может быть намного эффективнее, чем создавать новый отдел ИИ и проводить десять встреч по согласованию между командами. Организационные барьеры не устраняются за счет структуры, а исчезают благодаря работающему демо.

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

👦🏻 Автор: Генри (команда DeerFlow) [1]