Як стати Forward Deployed Engineer за 10 кроків: $785 тис. на рік (повний курс)

Forward Deployed Engineer перетворився з цікавої ролі в Palantir на найбільш рекрутовану позицію в AI за дванадцять місяців — кількість вакансій зросла на 729%.

Ось 10-крокова дорожня карта: що це за робота насправді, який стек потрібен, і який етап співбесіди відсіює 60% кандидатів, що пройшли кодинг.

Підпишіться на мій Substack, щоб отримувати свіжу AI-аналітику:

movez.substack.com

Це не зарплата дослідника. Це не зарплата штатного інженера у великій техкомпанії.

Це ринкова ставка для інженера, який робить те, що майже ніхто не оптимізує свою кар'єру під: змусити AI реально працювати всередині справжньої компанії.

Ніхто не просить цю людину тренувати модель. Їм не потрібен PhD, і їм не потрібно перемагати в алгоритмічних головоломках.

Їм потрібно зайти в бізнес із застарілими системами, відділом комплаєнсу та скептичною операційною командою — і вийти через шість тижнів із чимось, що працює.

Причина такої високої оплати — одна статистика. Дослідження MIT NANDA серед 300 корпоративних AI-проєктів показало, що 95% з них мали незначний або нульовий вплив на прибуток і збитки.

Моделі працювали добре. Розгортання провалилися — тому що ніхто не зміг змусити їх спілкуватися з legacy-базою даних, пройти перевірку комплаєнсу або вижити після передачі команді, яка їх успадкувала.

Назва запозичена з військової сфери: forward deployed означає розміщення спеціалізованих підрозділів близько до театру бойових дій, а не в штабі.

Palantir створила сучасну версію на початку 2010-х і назвала їх Deltas — і до 2016 року в компанії було більше Deltas, ніж інженерів-програмістів.

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

Ця ідея була нішевою десятиліття. Потім AI зламав універсальне SaaS, і це стало грою всього життя.

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

01. Дізнайтеся, чим насправді є ця робота

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

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

У кімнаті немає продакт-менеджера, який визначить обсяг, немає старшого інженера, якому можна передати архітектуру, і немає беклогу, який скаже, що важливо — ви самі вирішуєте, що будувати, що імітувати, а від чого відмовитися, прямо в кімнаті, протягом того ж тижня.

Типовий ритм у провідних AI-компаніях напрочуд однаковий: FDE сидить із клієнтом від чотирьох до восьми тижнів, випускає щось, що працює, а потім основна інженерна організація повільно перетворює на продукт те, що виявилося загальним.

Цей цикл і є всім стратегічним сенсом ролі. Ви одночасно приносите дохід і проводите найточніше продуктове дослідження компанії.

02. Зрозумійте, чому роль вибухнула

Цифра 95% із початку статті — це основа всього цього кар'єрного шляху, тому варто зрозуміти її точно.

• Ці корпоративні AI-проєкти не провалилися через погані моделі.
• Вони провалилися на інтеграції: системи не могли спілкуватися з legacy SQL-базами, не могли обробляти SAML-аутентифікацію клієнта, не могли відповідати вимогам щодо розташування даних і не могли підтримуватися операційною командою, яка їх успадкувала.

Потім три сили одночасно вказали в одному напрямку.

• AI зламав універсальне SaaS — горизонтальна обіцянка «купив і підключив» виживає в зрілих категоріях, але не в AI, де кожне підприємство має унікальні дані, унікальні робочі процеси, унікальні обмеження комплаєнсу та власне визначення «достатньо добре». Продаж AI компанії з Fortune 500 тепер завжди означає також продаж інтеграційного проєкту.
• Лабораторії повинні розгортати зі швидкістю руху технології — шестимісячна інтеграція вбиває пілот до того, як він стартує.
• І AI-інструменти зробили економіку прийнятною: за допомогою Claude Code та сучасного стеку один сильний FDE робить те, на що кілька років тому потрібна була команда з трьох осіб, і це єдина причина, чому відправка людини на місце на шість тижнів окупається.

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

03. Визначте ринок і оберіть цілі

Назва посади нестабільна, і це перше практичне, що варто знати — пошук лише за «Forward Deployed Engineer» приховає більшу частину ринку від вас.

Та сама робота публікується як Applied AI Engineer (назва Anthropic), Forward Deployed Software Engineer або FDSE (Palantir), Solutions Engineer, Deployment Engineer та Founding Engineer (Customer Facing) у менших стартапах. Шукайте всі варіанти.

Зростання не є непомітним. Вакансій FDE на Indeed було 643 у квітні 2025 року, а стало 5 330 у квітні 2026 року — зростання на 729% за дванадцять місяців.

До середини 2026 року було 224 відкриті вакансії FDE у 39 AI-компаніях, і це лише ті, що були публічно опубліковані. Salesforce пообіцяла найняти тисячу. EY запустила спеціалізовану практику FDE у Великій Британії та Ірландії у квітні 2026 року — перша велика консалтингова компанія, яка офіційно впровадила цю модель.

Компенсація відображає дефіцит і різко розділяється за рівнями. Дані Levels fyi показують середню загальну компенсацію в США близько $238,000 з типовим діапазоном $205,000–$486,000, а FDE на рівні staff отримують понад $630,000. Медіана Palantir становить близько $215,000.

На передових лабораторіях це зовсім інший ринок: старші FDE в Anthropic та OpenAI отримують понад $785,000, причому Applied AI Engineers від Anthropic мають базову зарплату понад $300,000 на старших рівнях, а загальна компенсація регулярно перевищує $500,000.

Одна важлива примітка щодо планування, яку варто знати заздалегідь: Anthropic зазвичай не веде переговорів щодо оферів.

**

04. Розвивайте широту інженерних навичок

Це неінтуїтивна частина, і саме тут інженери з вузькою спеціалізацією помиляються.

Найсильніші FDE — не найглибші інженери в своїй компанії.

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

Конкретно, мінімум виглядає так. Python та TypeScript покривають більшість того, з чим ви зіткнетеся. Одна хмара — AWS, GCP або Azure, оберіть ту, на якій реально працюють ваші цільові клієнти.

Одна база даних, яку ви добре знаєте і можете налагоджувати під тиском, та один фронтенд-фреймворк, у якому ви можете швидко створити робочий інтерфейс.

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

Два м'якіші шари важливі не менше за технічні, і саме їх перевірятимуть на співбесіді.

Продуктове судження, тому що ви є PM у кімнаті, і ніхто інший не вирішить, що будувати, а що імітувати.

І ділова проникливість — хтось запитає, який ROI цього проєкту, і їм знадобиться відповідь, щоб захистити проєкт перед власним керівництвом.

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

05. Навчіться випускати AI, а не тренувати його

Ось найпоширеніша помилка, яка стоїть між інженерами та цією роботою: вони вважають, що повинні вміти тренувати моделі.

Ні. Ніхто не просить FDE робити тонке налаштування. Але ви абсолютно повинні вміти їх випускати — це зовсім інший і набагато більш доступний набір навичок.

AI-нативний шар наразі чітко визначений. Сильний промпт-інжиніринг. Вільне володіння основними API моделей.

• RAG-патерни — і, зокрема, знання, коли пошук є неправильною відповіддю.
• Структуровані виходи, тому що продакшн-системи потребують валідованих структур, а не тексту.
• Базова дисципліна оцінювання (evals) — це шар, який відокремлює тих, хто робить демо, від тих, хто випускає.

І хоча б один агентний фреймворк, у якому ви щось реально побудували.

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

Вміння мислити про затримку, вартість, надійність та безпеку як про компроміси, а не як про контрольні списки.

1# Оцініть від 1 до 5. Все, що нижче 3, — це ваш наступний місяць роботи.
2
3## Інженерна широта          # добре, але не елітно
4[ ] Python // бекенд, скрипти, дані
5[ ] TypeScript // інтеграції + робочий фронтенд
6[ ] Одна хмара, щось реально задеплоїв на ній
7[ ] Одна база даних, можу налагоджувати під тиском
8[ ] Можу підняти робочий інтерфейс за день
9
10## AI-нативний             # випускати, не тренувати
11[ ] Промпт-інжиніринг, що виходить за межі методу спроб і помилок
12[ ] API моделей: стрімінг, використання інструментів, бюджет токенів
13[ ] RAG // і знання, коли пошук — це НЕПРАВИЛЬНА відповідь
14[ ] Структуровані виходи + валідація схем
15[ ] Evals // шар, що відокремлює демо від продакшну
16[ ] Один агентний фреймворк, на ньому щось реально побудовано
17
18## Те, що ніхто не практикує
19[ ] Провів воркшоп з нетехнічним стейкхолдером
20[ ] Сказав платному клієнту "ми не повинні це будувати"
21[ ] Висловив свою роботу в доларах або зекономлених годинах
22[ ] Вивчив незнайому галузь достатньо добре, щоб випускати в ній
236
24Побудуйте стек

Будь-хто може змусити демо працювати; вся цінність FDE полягає в тому, що він знає, чому демо не виживе при контакті з реальною компанією, і що з цим робити.

06. Створіть три артефакти, які купують підприємства

Ось де загальна дорожня карта "вивчи AI" перестає бути корисною, а конкретика починає мати значення.

Власні публікації вакансій FDE від Anthropic чітко описують результати: ви вбудовуєтеся зі стратегічними клієнтами для створення продакшн-додатків на основі Claude, і ви випускаєте MCP-сервери, суб-агенти та навички агентів.

Ці три артефакти є конкретними одиницями роботи.

• MCP-сервери — це шар інтеграції, те, що з'єднує Claude із реальними системами клієнта: їхнім тікетінгом, їхнім складом, їхнім внутрішнім API, який не має документації і якого розуміє лише одна людина.
• Навички агентів кодують специфічний робочий процес та інституційні знання клієнта, щоб Claude дотримувався їхнього процесу, а не загального.
• Суб-агенти виконують роботу, яка інакше роздула б контекстне вікно для довготривалого завдання.

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

1# Артефакт, який реально випускає FDE: Claude, підключений до системи,
2# яку ніхто не проектував для нього. Legacy API, без документації, один хлопець, який її знає.
3
4from mcp.server.fastmcp import FastMCP
5
6mcp = FastMCP("warehouse-ops")
7
8@mcp.tool()
9def find_stalled_shipments(hours_stalled: int = 24) -> list[dict]:
10    """Відвантаження без події сканування за N годин. Використовуйте, коли операційна команда
11    запитує, що застрягло, або перед оглядом ескалації від клієнта."""
12    # Реальна робота: їхня legacy-схема, їхній часовий пояс, їхня колонка soft-delete,
13    # яку ніхто не задокументував.
14    return query(STALLED_SQL, hours_stalled)
15
16@mcp.tool()
17def reroute(shipment_id: str, hub: str, reason: str) -> dict:
18    """Перенаправити відвантаження. Записує рядок аудиту — комплаєнс
19    вимагає причину для кожного ручного втручання."""
20    return post_with_audit(shipment_id, hub, reason)
21
22# Зверніть увагу, що робить це артефактом FDE, а не демо:
23#   - docstrings кажуть, КОЛИ використовувати інструмент, а не лише що він робить
24#   - рядок аудиту існує, тому що їхня команда комплаєнсу вимагає його
25#   - хитромудрі схеми обробляються тут, а не залишаються для моделі

MCP-сервер, який обгортає справді заплутаний API, є сильнішим сигналом для найму, ніж будь-який сертифікат, тому що він доводить те, що інакше неможливо перевірити: що ви можете змусити передову модель бути корисною всередині системи, яку ніхто не проектував для неї.

07. Опануйте Claude Code як ваш мультиплікатор

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

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

Тому інструменти не є приємним бонусом до роботи; вони є несучою конструкцією для бізнес-обґрунтування вашої позиції.

Практично це означає, що вільне володіння Claude Code є частиною стеку навичок, а не чимось окремим.

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

Це також має прямий сигнал для найму. У технічному сценарному скринінгу Anthropic вам можуть надати доступ до Claude і попросити вирішити проблему з ним — навмисно, тому що це відображає реальну роботу.

Те, як ви керуєте моделлю, є частиною того, що оцінюється. Практика цього — це одночасно підготовка до співбесіди та виконання роботи.

1› Використайте суб-агента, щоб зіставити, як замовлення проходять від приймання до виконання в
2цьому репозиторії. Мені потрібна модель даних, точки інтеграції та місця, де стан
3може бути записаний двічі. Запишіть це в notes/orders.md.
4
5● Створюю дослідницького суб-агента · окреме контекстне вікно
6● Прочитано 23 файли · 41.2k токенів — жодного у вашому вікні
7
8✓  Повернено 680-токенове резюме → notes/orders.md Знайдено: приймання пише в `orders` І `legacy_orders`. Завдання звірки
9запускається щоночі. Все, що зазнає невдачі між 18:00 і 02:00, невидиме для операційної команди.
10
11 › Цей розрив — справжня скарга клієнта. Напишіть MCP-інструмент,
12який показує ці незавершені замовлення, потім ми покажемо його операційній команді.
13День 2. Попередній постачальник витратив шість тижнів, щоб знайти це.

08. Випустіть одне реальне розгортання для реального користувача

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

Це стіна, об яку розбивається більшість кандидатів, і це єдине в цьому списку, що ви не можете подолати лише читанням.

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

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

Остання частина не є опціональною — вся робота полягає в тому, що відбувається після демо.

Потім опишіть це так, як звітує FDE, тому що опис — це половина артефакту. Не «побудував RAG-чатбот на LangChain».

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

1# Диспетчерська тріаж для сантехнічної компанії з 14 фургонами
2// Структуруйте це як пост-мортем FDE, а не як README проєкту.
3
4## Робочий процес до
5Диспетчер витрачав ~2.5 години/день на читання нотаток до завдань і перепризначення фургонів.
6За рік через це звільнилися двоє. Ніхто ніколи не засікав час.
7
8## Обмеження, які я не міг змінити
9- Дані планування живуть в хостинговому інструменті з API лише для читання.
10- Диспетчер не буде користуватися новим додатком. Все мало працювати через SMS.
11- Власник не схвалював нічого, що стосується платіжних даних клієнтів.
12
13## Що я навмисно НЕ будував
14Автоматичне перепризначення. Вони йому не довіряли і вимкнули б на першому тижні.
15Натомість пропозиція + підтвердження одним натисканням.
16// Бути правим у цьому питанні було важливіше, ніж вибір моделі.
17
18## Що зламалося на другому тижні
19Нотатки до завдань мали непослідовні прізвиська фургонів ("великий синій" проти "V-3").
20Виправлено за допомогою таблиці псевдонімів, яку диспетчер редагує сама.
21// Це частина, яка відокремлює випущене від продемонстрованого.
22
23## Після
24~40 хвилин/день. Працювало 5 місяців. Вона досі ним користується. Власник додав 2 фургони.

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

09. Навчіться виявлення потреб клієнтів

Це крок, який варто прочитати двічі. Цикл співбесід Applied AI Engineer від Anthropic включає раунд розмови з клієнтом, і він має приховану вагу: він відсіває приблизно 60% кандидатів, які вже пройшли етапи кодингу.

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

Режим невдачі передбачуваний і майже універсальний: кандидат чує проблему клієнта і починає її вирішувати. Він пропонує архітектуру. Дехто відкриває редактор.

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

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

1# Проведіть раунд як дослідник. Вирішення занадто рано — це ознака.
2
3## Виявіть реальні обмеження
4- Що ви вже пробували тут, і чому це зупинилося?
5  // невдалі розгортання приховують усі важливі обмеження
6- Що не може змінитися незалежно від того, що ми побудуємо?
7  // комплаєнс, затримка, розташування даних, колективний договір
8- Хто має це затвердити, і що вони заперечуватимуть?
9
10## Знайдіть реальний робочий процес
11- Проведіть мене через останній раз, коли це пішло не так.
12- Хто робить це сьогодні, і скільки це їм коштує на тиждень?
13- Що відбувається далі, якщо ми помилимося о 3-й ночі?
14
15## Визначте "достатньо добре" — їхнє, не ваше
16- Яка точність змусить вас вимкнути це?
17- Як ви дізнаєтеся через 90 днів, чи це спрацювало?
18- Що замість цього робитиме людина, яка виконує цю роботу сьогодні?
19
20## Завершіть цикл
21- Відобразіть те, що почули. Нехай виправлять.
22- Назвіть те, що ви НЕ будували б, і чому.
23// Сказати "ми не повинні цього будувати" — це сигнал старшого рівня, а не ухиляння.

Кожного разу, коли ви сидите з людиною, чий робочий процес ви налагоджуєте, ви репетируєте цей раунд.

**

10. Пройдіть цикл співбесід

Цикл напрочуд однаковий у провідних компаніях, і він побудований так, щоб фільтрувати в обох напрямках одночасно — проти чистих алгоритмічних інженерів, які не вміють спілкуватися, і проти гладких консультантів, які не вміють кодувати.

Очікуйте приблизно п'ять етапів:

• Скринінг рекрутера щодо мотивації, досвіду та відповідності рівню.
• Технічний сценарний скринінг — в Anthropic, практичний сценарій розгортання Claude з використанням MCP-інструментів, де ви плануєте та виконуєте довготривале завдання та обґрунтовуєте надійність, управління контекстним вікном та узгодженість у продакшні.
• Раунд кодингу, який є практичним, а не LeetCode: обмежувач швидкості, обробка потокових даних, розподілена черга завдань, розподілювач бюджету токенів, оркестратор структурованого використання інструментів — часто з новими обмеженнями клієнта, які додаються посеред вправи, щоб побачити, чи ви робите чистий рефакторинг.
• Раунд з менеджером з найму щодо минулих проєктів та міркувань про клієнтів. Потім фінальна панель щодо дизайну рішень та цінностей.Дві примітки щодо підготовки, які люди пропускають.
• Відповідність місії серйозно перевіряється в Anthropic — прочитайте Core Views on AI Safety, Responsible Scaling Policy та нещодавні роботи з інтерпретабельності перед подачею заявки; загальний ентузіазм не проходить.

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

Шість стартових точок — знайдіть свою

• Додайте AI-шар, збережіть ретельність. Ваші продакшн-інстинкти — це дефіцитна половина; більшість AI-нативних кандидатів ніколи не запускали нічого реального. Додайте промпт-інжиніринг, API моделей, структуровані виходи та evals, потім випустіть один MCP-сервер для заплутаної внутрішньої системи.
• Перестаньте тренувати, почніть запускати. Ви надлишково кваліфіковані в моделюванні та недостатньо кваліфіковані в усьому іншому. Робота — це інтеграція, обмеження та стейкхолдери. Навмисно побудуйте щось нудне, що переживе перевірку комплаєнсу та передачу операційній команді.
• Ідіть туди, де відбуваються розгортання. Вакансії FDE на передових лабораторіях рідко бувають початковими. Прицільтесь на один щабель назовні — стартапи та консалтингові компанії, які розгортають AI на підприємствах, — де ви будете робити ту саму роботу з меншими бар'єрами, а через два роки перейдете на вищий рівень.
• Швидко закрийте прогалину в кодингу. У вас уже є половина, яка відсіває 60% кандидатів. Тепер пройдіть раунд кодингу: практичні вправи, а не LeetCode — обмежувачі швидкості, стрімінг, черги завдань, оркестратори використання інструментів, написані чисто в умовах змінних обмежень.
• Доведіть, що ви дійсно можете будувати. Виявлення потреб та управління стейкхолдерами вже ваші. Цикл явно розроблений, щоб відсіяти гладких балакунів, які не вміють кодувати — тому вся ваша підготовка — це одна випущена, підтримувана та публічно задокументована система.
• Можливо, ви вже робите цю роботу. Внутрішні платформні інженери, які працюють із бізнес-підрозділами, виконують функції FDE під іншою назвою. Перепишіть свій досвід мовою цієї ролі — змінені робочі процеси, зекономлені години, подолані обмеження — і ви вже живий кандидат.

Висновок:

Дефіцитним ніколи не була модель. Дефіцитна людина, яка може її впровадити.

Можливості перестали бути вузьким місцем десь за останні два роки.

Тепер дефіцитним є інженер, який може зайти в компанію із застарілими системами, відділом комплаєнсу та скептичною операційною командою — і вийти через шість тижнів із чимось, що реально працює.

Це дивна комбінація навичок, і саме тому вона так оплачується. Інженерна широта замість глибини. Судження без PM, на якого можна покластися. Терпіння сидіти в чиїйсь заплутаній реальності достатньо довго, щоб зрозуміти її, перш ніж написати рядок коду.

Більшість інженерів продовжуватимуть оптимізувати себе під ролі, які існували в 2020 році. Ті, хто навчиться розгортати, володітимуть десятиліттям — тому що кожна модель, яка звідси випускається, все ще повинна пережити контакт із реальною компанією.