FDE: Нова межа в інженерних ролях, що ґрунтуються на ШІ

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

Цей текст відповідає на три конкретні запитання, які мене недавно запитали ці чотири друзі:

Чи є FDE консалтинговою фірмою у штучному інтелекті? Де межа між ним і традиційним консалтингом?

Чи є FDE більш просунутою формою аутсорсингу програмного забезпечення? У чому відрізняється від того, що я роблю як виконавець?

- Чи підходжу я для посади FDE? Які типи людей ця позиція підсилює, а які — знищують?

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

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

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

Антропік майже здійснює зеркальну дію. Позиція 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 не працює за цією схемою. Найчастіше клієнти кажуть: «Я знаю, що 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 підключає місію — клієнт сам не розуміє, чого хоче, і знає лише те, що «AI мав би якось допомогти мені». Основою SOW є визначеність, а основою місії — дослідження. Це абсолютно різні підходи до запуску проекту.

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

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

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

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

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

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

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

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

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

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

Розгортання на власному сервері та відповідність вимогам безпеки даних знищують модель, що працює лише через виклик API. Домашні корпоративні клієнти вимагають набагато вищого рівня забезпечення того, щоб дані не виходили за межі локальної мережі, ваги моделі були під контролем, а аудит був відстежуваний, ніж ринок США. У проекті FDE робота, пов’язана лише з викликом API та запуском Prompt, може становити лише 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, сприймають такий зворотний зв’язок як паливо, беруть на себе відповідальність за весь процес від початку до кінця і не перекладають вину на «недостатньо чітко сформульовані вимоги».

Чутливість до меж моделі. Це найбільш технічний і найбільш прихований аспект. 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, але їхні посади позначені як «експерт з рішень», «галузевий архітектор», «інженер з застосування ШІ». Виявіть їх, перекласифікуйте та створіть для них шлях розвитку, що відповідає їхній роботі — це ефективніше, ніж набирати нових співробітників з нуля.

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

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

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