FDE: Нова посада, яка сприяє впровадженню ШІ в підприємствах

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

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

FDE, повна назва Forward Deployed Engineer^[2]Це було жаргонним терміном у колах Palantir два роки тому, а сьогодні воно тихо перетворилося на вітальну фразу рекрутерів, часту посаду у вакансіях та один із кандидатів на титул «найціннішої посади в епоху ШІ» у соціальних мережах. OpenAI у травні 2026 року безпосередньо створила компанію 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 консалтинговою фірмою у штучному інтелекті? Де межа між ним і традиційним консалтингом?

- Чи є FDE більш просунутим підходом до зовнішнього програмного забезпечення? У чому відмінність між 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 осіб протягом трьох років. Це не розмір дослідницької групи, це регулярна армія.

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

У цьому тексті приховано справжній обличчя роботи FDE. Це не продажовий архітектор, не SDR і не евангеліст, який приходить навчати клієнтів. Це інженер, який приносить модель і живе в кодовій базі клієнта. Бред Лайткап сказав ще чіткіше: «Наші клієнти кажуть нам, що їм потрібна здатність перейти від пілоту до виробництва. Deployment Company — це коли ми вставляємо наших інженерів у їхні команди і надаємо їм достатньо ресурсів для реалізації».

Намалюйте це у вигляді діаграми, і трьохсторонні відносини стануть дуже зрозумілими:

Зверніть увагу на дві найбільш інформативні лінії на цьому малюнку — це зворотні зв’язки, які FDE передає в обидва напрямки. До клієнтів: FDE не продає модель як SaaS, а об’єднує дані клієнта, права доступу, відповідність вимогам та внутрішні системи в єдиний канал, що дозволяє запускати модель. До компаній, що розробляють моделі: FDE повертає справжні болі клієнтів та приклади невдач у product та research, впливаючи на дорожню карту — повторювана помилка в шаблоні виклику інструменту може стати наступним вбудованим абстракцією в 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 не працюють за цією схемою. Найчастіше клієнти кажуть: «Я знаю, що AI повинен мені щось допомогти, але я не знаю, що саме». Сама мета є частиною проєкту. Тому FDE не приймає SOW, а приймає mission — відносно нечіткий напрямок; потім за допомогою ітерацій поступово уточнює цей напрямок; і на одній з ітерацій перетворює накопичене розуміння моделей у продукт.

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

Рядок «захисний рів» є найтоншим. Захисний рів FDE — це реальна інтуїція щодо меж здатностей моделі: скільки реальних сценаріїв клієнтів ти запустив цього місяця, стільки ти краще знаєш, що Claude 4.7 може робити, а що треба чекати до Claude 5. Цю інтуїцію неможливо включити до PPT чи бази знань — вона може існувати лише в головах інженерів, які працювали з цим протягом останніх 90 днів.

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

Якщо твердження «FDE — це нова версія Accenture» — це перше непорозуміння, то «FDE — це дороге зовнішнє програмне забезпечення» — це друге. Цей рівень ще більш вводить в оману, бо зовнішні докази виглядають дуже переконливо: FDE справді приїжджає на місце клієнта, щоб писати код, справді створює функції під бізнес клієнта і справді працює в робочий час клієнта. На перший погляд, вони не відрізняються від зовнішніх інженерів.

Але достатньо лише подивитися на зворотний зв’язок, щоб різниця була очевидна.

Найважливіша різниця на цьому малюнку — не те, що верхня частина дуже проста, а те, що в нижній частині з’явилася зворотна ланка, що поширюється на компанію з моделей. Ця ланка — не прикраса, це справжня причина існування посади FDE. Розкривши цю різницю, можна виділити щонайменше чотири пари порівнянь.

Речі, які підключаються, різні. Позаштатний персонал підключає SOW — список вимог, чітко визначений до підписання договору: які функції потрібно реалізувати, який технічний стек використовувати, за якими критеріями приймати роботу, як компенсувати порушення. FDE підключає mission — клієнт сам не розуміє, чого хоче, але знає, що «AI мав би змогти допомогти мені з чимось». SOW ґрунтується на визначеності, mission — на дослідженні. Це абсолютно різні підходи до запуску проекту.

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

Спосіб оплати інший. Це найбільш протилежне інтуїції. Компанія, що розробляє моделі, відправляє FDE на місце клієнта, і її головна увага не лише на тому, скільки вона отримає консультаційних платежів за цей проект, а на тому, скільки токенів клієнт буде споживати в майбутньому? Чи стане він клієнтом з високою збереженістю? Чи розширить свої бізнес-лінії? Справжнім KPI FDE є довгострокова крива споживання токенів моделі, а не цифра, зазначена в акті приймання проекту.

Зворотний зв’язок йде до іншого місця. Це найглибша група з чотирьох. У зовнішніх проектах зворотний зв’язок клієнта не йде далі, ніж до зовнішньої компанії, і не впливає на майбутні продукти, які зовнішня компанія продає іншим. Зворотний зв’язок FDE повертається до дорожньої карти компанії, що розробляє моделі — кожна проблема, яку клієнти зустрічають у реальних умовах, кожна невдача Prompt, кожен баг у виклику інструменту, стає вхідними даними для наступної версії навчальних даних, наступного дизайну інструментів та наступних функцій продукту. Іншими словами, кожен клієнт, який розгортає FDE, для компанії, що розробляє моделі, є одночасно природним партнером з дизайну.

Саме це — справжня причина, чому компанії, що розробляють моделі, готові платити високу зарплату FDE. Вони продають не просто сервіс — вони збирають сигнали про реальні форми продуктів на місцях клієнтів. Ці сигнали неможливо купити, захопити або отримати за допомогою опитувань — їх можна отримати лише тоді, коли конкретний інженер, працюючи в конкретному робочому процесі клієнта, кілька разів зіткнеться з перешкодами і повернеся з ними.

Чи ви знаєте, якою може бути загальна сума FDE від OpenAI та Anthropic? Згідно з публічними даними Levels.fyi про програмістів Anthropic^[8], медіанний загальний пакет для досвідченого SDE вже досяг \$710K. Позиція FDE має вищий ризик — потрібно мати справу з невизначеністю здібностей моделей, невизначеністю бізнесу клієнтів та невизначеністю формату продукту, тому галузевий огляд^[9]Згадується, що в передовій лабораторії штучного інтелекту FDE базові пакети для працівників середнього та вищого рівня зазвичай становлять 350K–550K, а працівники рівня Staff і вище можуть отримувати \$630K+. Ця винагорода не сплачується за «зовнішній час роботи», а є оплатою за прийняття на себе ризиків, пов’язаних з «продуктом + клієнтом + моделлю». >>> Згадаємо 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. Ступінь з комп’ютерних наук — це перевага, а не обов’язкова умова. Сам Карп є першим прикладом цього підходу — філософ, який очолює команду FDE з фізиками, математиками та філософами.

Другий корінь — це компанії нової генерації, засновані після 2023 року.

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

Ця хвиля FDE вивчає playbook Palantir — відправляти інженерів на місце клієнта, щоб повністю реалізувати робочий процес крок за кроком. Але носій продукту вже зовсім інший: у часи Palantir FDE займалися інтеграцією даних та кастомізацією інтерфейсу, а нове покоління FDE займається дизайном Prompt, оркеструванням агентів, викликом інструментів та вбудовуванням робочих процесів.

Прагматичний інженер про FDE^[13]Вони називають цю нову версію «вбудованою в підприємства для вирішення реальних, конкретних, високодоходних проблем» — формулювання майже ідентичне тому, що використовував Palantir у той час, лише слово «дані» було замінено на «модель».

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

Спільна риса: клієнти купують не програмне забезпечення. Вони купують «інженера + набір інструментів, які вирішать мою проблему». Це було незвичним у історії корпоративного ПЗ останніх тридцяти років. SAP, Oracle, Salesforce продавали саме програмне забезпечення — інженери існували як допоміжний ресурс, щоб «зробити це ПЗ доступним для клієнта». Palantir діє навпаки: інструменти існують як важелі, щоб «FDE міг вирішити проблему клієнта». Нове покоління моделей компаній успадкувало цю інверсію — OpenAI продаває не ліцензію на GPT-4, а «наш FDE може використовувати GPT-4, щоб автоматизувати вашу службу підтримки».

Відмінність: Епоха Palantir зосереджена на OPS-інтеграції — головна увага на інтеграції даних, моделюванні онтологій та управлінні правами. Нове покоління зосереджене на реалізації моделей — головна увага на проектуванні Prompt, оркестрації Agent та оптимізації збереження. Перше — це розширена версія системного інтегратора, друге — розширення продукт-інженера.

Ще один цікавий факт: багато ранніх 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 Direct Hire посаду «Експерт з AI-рішень для попереднього продажу», а такі компанії, як Moonshot, Zhipu, Tongyi та Hunyuan, також розміщують подібні вакансії. Назви трохи відрізняються, але зміст описів посад дуже схожий: розуміння сценаріїв клієнтів, створення демо, налаштування Prompt, запуск RAG, написання рішень для доставки та взаємодія з інженерними командами клієнтів до запуску. Ця хвиля посад — справжні «локальні FDE».

Три різниці в ґрунтах і воді

Розгортання на власних серверах та відповідність вимогам безпеки даних знищують модель, що працює лише через виклик API. Вимоги внутрішніх клієнтів у Китаї щодо того, щоб дані не виходили за межі території, контролю над вагами моделі та можливості аудиту та відстеження значно вищі, ніж на ринку США. У проекті FDE робота, пов’язана лише з викликом API та запитами, може становити лише 30%, а решта 70% — це перенесення моделі до серверного приміщення клієнта, налаштування автентифікації, інтеграція з платформою даних та реалізація відповідності нормативним вимогам.

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

Бізнес-клієнти в Китаї мають інші бажання щодо оплати та темпи ціноутворення порівняно зі США. Модель Palantir, яка полягає у «спочатку розміщенні FDE, а потім стягненні високої ціни за підписку», важко прямо копіювати. Бюджети клієнтів у Китаї залежать від річних закупівель, оплата схильна до проектного формату, а бізнес-модель FDE часто є змішаною: підписка + ліцензування з приватизацією + доставка проекту.

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

Багато великих компаній почали використовувати модель FDE для обслуговування «внутрішніх клієнтів». Інженери з Alibaba Cloud PAI працюють у Taobao, а Tencent Hunyuan має подібний механізм для взаємодії з WeChat та рекламними напрямками. На JD зазначені посади: «Інженер з впровадження в галузі», «Інженер з застосування ШІ», «Експерт з інтелектуальних бізнес-процесів» — суть цих ролей — внутрішні FDE, які забезпечують енд-ту-енд реалізацію здібностей команди моделей на бізнес-стороні. Це надає лідерам великих компаній нову ідею: кілька внутрішніх FDE, що працюють на бізнес-стороні, можуть швидко створити перший демо-проект і передати дані про ROI керівникам бізнесу — це розчинить бар’єри між відділами швидше, ніж десять зустрічей з координації.

Автор попередньої статті «Звернення до суперіндивіду»^[4]Раніше згадувалося п’ять двигунів суперіндивіда: сильна допитливість, високий рівень дослідницького та інноваційного духу, здатність до самонавчання, сильна внутрішня мотивація, вміння діяти. Ці п’ять рис — це квиток у FDE, але не все. Крім цих п’яти двигунів, позиція FDE вимагає ще й певного набору конкретних додаткових якостей, а також існують кілька типів особистості, які явно не підходять. Автор бачив багато відмінних інженерів, які перейшли на позицію FDE, але не змогли адаптуватися — проблеми зазвичай не в навичках, а в характері та робочих уподобаннях.

П’ять якостей, властивих FDE

Не уникайте продаж і комунікації. Щоденна робота FDE — це не не в закритому приміщенні писати код, а безпосереднє взаємодіяння з CTO, керівниками бізнесу, закупівлями, відділом компліанси та ІТ клієнтів. Типовий ритм: CTO клієнта перериває вас під час демонстрації — реакція FDE не може бути «Я повернуся і виправлю версію, прийду наступного тижня», а повинна бути відразу відкрити IDE, змінити Prompt і перезапустити для нього. «Клієнт тут, я вношу зміни» — це норма для FDE.

Насолоджуйтесь сірою зоною. FDE отримує не чіткий PRD, а лише фразу: «Ми хочемо щось зробити з AI». Сам клієнт не може чітко сформулювати, чого хоче, і потребує, щоб 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 — це перша нова форма посади в AI промисловій революції, яка має назву, діапазон заробітної плати, опис вакансії та підтвердження платіжної здатності клієнтів. Вона не є синонімом концепції «суперіндивіда», а є першою конкретною точкою в цьому процесі трансформації — від абстрактного до реального.

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

Залиште по одному реченню для трьох категорій читачів.

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

Для HR та OD: Увага на «розрив між назвою та суттю». У вашій компанії вже можуть працювати FDE, але їхні посади позначені як «експерт з рішень», «галузевий архітектор», «інженер з застосування ШІ». Виявіть їх, пере класифікуйте та створіть для них шлях розвитку, що відповідає їхній роботі — це ефективніше, ніж наймати нових співробітників.

Керівникам: режим FDE може застосовуватися не лише зовні, а й всередині. Усередині компанії можна виділити кілька «внутрішніх FDE», які працюватимуть безпосередньо з бізнес-підрозділами, щоб інтегрувати здібності моделей безпосередньо в бізнес-процеси — це може бути набагато ефективнішим, ніж створення нового відділу штучного інтелекту та проведення десятка зустрічей з координацією між командами. Віддільні стіни не зникають через організаційний дизайн, а зникають завдяки робочому демонстраційному прикладу.

Перетворення професій у епоху ШІ вже розпочалося, FDE — це перший снаряд, який повідомляє нам: швидкість змін у здатностях моделей настільки висока, що виникають нові посади. Автор хоче залишити читачеві конкретне питання — якщо через три роки у вашій компанії у організаційній структурі з’являться три нові посади, які, на вашу думку, це будуть? Зрозуміти це питання корисніше, ніж просто прочитати цю статтю.