FDE: Новая должность, стимулирующая внедрение ИИ в предприятиях

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

За последний месяц я встретил четырех друзей, готовящихся сменить сферу деятельности — фронтенд-разработчика, архитектора решений, продукт-менеджера и традиционного инженера-алгоритмиста. У них разный опыт, возраст и город, но они все задали один и тот же английский аббревиатуру: 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 перенесла этот термин в индустрию программного обеспечения в конце 2000-х годов, чтобы описать модель работы, при которой инженеры отправляются из штаб-квартиры и живут на объектах клиентов; даже внутренние команды получили названия по военной транскрипции — Delta и Echo. Теперь это понятие снова взяли на вооружение OpenAI и Anthropic — и это не случайно: суть дела — отправить инженеров на передовую — осталась неизменной.

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

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

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

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

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

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

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

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

Я понимаю эту ассоциацию. В костюме, на выезде к клиенту, рисуя на доске в конференц-зале клиента, согласовываясь с топ-менеджерами уровня C — визуально 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 подключается к mission — клиент сам не знает, чего хочет, и знает только то, что «AI должен как-то помочь мне». Основа SOW — определенность, основа mission — исследование. Это совершенно разные подходы к запуску проекта.

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

Система оплаты другая. Это самое неинтуитивное. Компания, занимающаяся моделями, отправляет FDE на объект клиента, и их главный интерес — это не только гонорар за этот проект, а то, сколько токенов клиент будет потреблять в будущем? Станет ли он клиентом с высокой удерживаемостью? Расширится ли сотрудничество на другие направления бизнеса? Настоящий KPI 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 на место, и группа платила Accenture 3500 юаней в день за консалтинг — они оставались на несколько лет и в то время СМИ называли их «золотыми менеджерами». Позже я перешел в немецкую компанию SAP, которая даже ввела термин в индустрии консалтинга, и SAP-консультанты стали символом «золотых менеджеров». Таким образом, зарплаты в FDE, по всей видимости, будут расти в течение как минимум 24–36 месяцев, а спрос также будет стабильно расти.

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

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

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

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

Palantir была основана в 2003 году Питером Тиелем, Алексом Карпом, Джо Лонсдейлом и другими; её первыми клиентами были американские разведывательные органы. Сам Карп не имеет технического образования — он защищал докторскую диссертацию по философии у Юргена Хабермаса во Франкфурте, а затем был привлечен Тиелем на должность генерального директора. Должность FDE возникла именно из-за этой комбинации «нетипичного генерального директора + высококонфиденциальные клиенты»: обзор от 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 открыто приветствует кандидатов, не имеющих образования в области информатики: недавние наймы FDE пришли из областей машиностроения, экономики, философии и других. Два ключевых требования — это способность действовать при неполной информации и умение напрямую общаться с клиентами уровня C. Степень в области информатики — это преимущество, а не обязательное условие. Сам Карп является первым примером этого подхода — CEO с философским образованием, возглавляющий команду FDE из физиков, математиков и философов.

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

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

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

Прагматичный инженер о 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, также размещают аналогичные должности. Названия немного отличаются, но содержание описаний вакансий крайне схоже: понимание сценариев клиентов, создание демо-версий, настройка Prompt, запуск RAG, составление планов доставки, взаимодействие с инженерными командами клиентов до вывода на продуктивную среду. Эта волна вакансий — настоящие «отечественные FDE».

Три различия в почве и климате

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

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

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

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

Многие внутренние AI-команды крупных компаний начинают использовать модель 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. Один и тот же заказ, клиент попросил вас внести 8 изменений — сможете ли вы сохранить способность к самостоятельному суждению, а не выполнять действия механически?

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

6. Вы готовы подписать договор, написать отчет, пройти приемку клиентом и согласовать юридические условия с юридическим отделом?

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

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

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

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

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

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

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

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

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