Хайп считает частоту слова «AI» в JD. Я считаю мандат роли: кого покупают наверх, какую боль закрывает найм, и где лента врёт объёмом.
Недавно разобрал дневной корпус vacancy-intel — разведки по открытым вакансиям: десятки ролей за один день, много репостов одних и тех же JD, часть отчётов — stubs без веб-верификации. После дедупа остаётся порядка тридцати уникальных пар «компания + роль». Устойчивый сигнал читается не по красивой формулировке рекрутера, а по повторяющемуся мандату — зачем позицию вообще открыли.
Это другой угол, чем в разборе спроса на AI-специалистов. Там — какие IC- и specialist-кластеры проступают в org chart (agents, evals, Applied AI, partner delivery). Здесь — кого берут на лидерский слой, как AI-словарь маскирует разную зрелость, почему platform становится общим языком боли, и как не принять founding/plant-шум за тот же рынок.
Титул — про лидерство, не про IC
В корпусе доминируют Engineering Manager, Head, Director, CTO, founding. IC-роли — individual contributor, линейный инженер без managerial мандата (Applied AI, GenAI pipeline, QA, principal) — меньшинство.
Рынок в этом срезе ищет человека, который соберёт capability и склеит оргструктуру, а стратегию переведёт в roadmap — не ещё один слот в команде. Это совпадает с тем, что давно пишут в JD для EM/Head/Director: people leadership + delivery operating model + platform thinking + data/AI readiness + stakeholder management.
AI здесь усиливает неопределённость. Ядро покупки то же: предсказуемая поставка ценности и снижение риска для ЛПР. Там, где типичный EM начинает с найма и ритуалов, сильный сигнал в JD начинается с диагностики того, что прямо сейчас рвёт поставку.
AI — обязательный словарь при разной зрелости
Слово AI / GenAI / LLM встречается у большинства содержательных компаний. Смысл — разный.
| Кластер | Как звучит AI в JD | Что это обычно значит |
|---|---|---|
| Regulated enterprise (utilities, healthcare-adjacent) | evaluate, benefit assessment, GenAI + compliance | FOMO плюс страх production |
| Industrial / motion / water tech | «use AI tools», intelligent solutions | рычаг cost/productivity; часто сопротивление традиционного инжиниринга |
| Product / scale-up | AI в продукте, pipeline, orchestration | нужен governance и production readiness |
Нанимают не под «AI-исследование». Нужен перевод пилотов в систему: ownership, evals, границы агентов, observability, безопасность. Без этого AI остаётся набором параллельных демо — красивых на демо-дне и дорогих в эксплуатации.
Если вы CTO и в JD у вас «must use AI tools», а в оргструктуре нет владельца production AI — вы купили словарь, не capability.
Platform engineering как общий каркас боли
Повторяющиеся формулировки из дневного среза:
- simplify backend at scale;
- reduce operational overhead для product-команд;
- DevEx и observability;
- unified compute / internal platform;
- platform capabilities под Data/AI рядом с legacy (в том числе SAP-Basis).
Смысл один: product-команды должны ship'ить business logic, не владея всей операционной тяжестью. Post-M&A и multi-brand интеграция усиливают ставку на единый платформенный слой — классический пример в срезе: computing platform под экосистему delivery-брендов.
Когда в одной пачке вакансий рядом EM на platform и Head of Development & Data с мандатом «собрать platform под DE/DS/AI» — это не мода на слово platform. Без общего слоя velocity упирается в ops и интеграции, и компании это уже пишут в JD.
Enterprise modernization идёт рядом с AI
Кластер SAP Engineering Manager у крупного сервисно-интеграторского игрока — proxy спроса DACH-enterprise на ABAP / CAP / FICO / Logistics leadership. Рядом в том же дне — utilities с SAP-Basis, KRITIS и Data/AI platform в одном Head of Development & Data.
Классическая модернизация не «устарела». Она живёт в одном контуре найма с AI-повесткой. Читать сервисно-интеграторский SAP-кластер как «интегратор сам хочет SAP» — ошибка: чаще это зеркало клиентского спроса, особенно DACH.
География и шум: два рынка в одной ленте
Много DE-вакансий (m/w/d), industrial R&D, corporate startup в manufacturing, CTO через рекрутера с скрытым работодателем. Параллельно — founding CTO / co-founder с пустым или тонким JD и equity, плюс physical plant / production engineering.
Без triage лента смешивает три разных buying mode:
- Digital product / platform leadership — высокий fit к AI-driven engineering leadership.
- Founding / pre-product CTO — часто низкий fit как consulting lead: нет системы, которую чинить; нужен полный commitment и product invention.
- Plant ops / hardware R&D — соседний или чужой сегмент; титул «Head of … Engineering» обманывает глаз.
Гибридные титулы усиливают картину оргдыры: AI Engineer + Technical Product Owner, DVP Engineering & Product Management, Head of Development & Data. Компания склеивает eng + product + AI в одного человека — либо не может позволить раздельные функции, либо ещё не умеет их развести. Для кандидата и для консультанта это сигнал: скоуп размыт, success criteria будут спорить между собой.
Failure modes чтения ленты
- Считать частоту слова «AI» спросом на ML-research. Частота — про словарь. Спрос — про роль, ownership и production constraints.
- Принять founding CTO и plant Head как тот же рынок, что EM Computing Platform или Head of Dev & Data. Титулы похожи, buying mode разный.
- Игнорировать дубликаты JD. Один работодатель × N репостов LinkedIn раздувает «объём рынка» в дневном срезе. Считать уникальные company+role, не карточки.
- Читать SAP-кластер интегратора как внутренний product-mandate. Часто это proxy клиентского спроса.
Практический фильтр из четырёх вопросов
Когда смотришь пачку вакансий или intel-отчётов:
- Мандат: починить поставку / платформу / org — или «придумать продукт с нуля за equity»?
- AI-зрелость: evaluation / cost tool / production feature с governance?
- Платформенный слой: есть ли DevEx / internal platform / снятие ops с product — или только «цифры и модель»?
- Сегмент: digital product / regulated enterprise / industrial software — или физический завод?
Если три из четырёх указывают на transformational leadership + platform + production AI — это тот же рынок, где ценят предсказуемость поставки при неопределённости. Не ещё одного IC с «LLM» в резюме.
Что из практики цепляется к этому сигналу
В enterprise-трансформации с ландшафтом 40+ сервисов и 20+ распределённых команд (Askona: организация уровня $680M+ выручки) работало не «добавить AI-команду в углу», а platform governance + AI enablement (RAG, agents, AI-assisted coding) без большого взрыва по continuity. Тот же принцип, который сейчас читается в JD: сначала швы и operating model, потом ускорение.
Боль CTO, которую эти вакансии кодируют между строк: внедрить AI так, чтобы legacy остался стабильным, а management overhead не разросся. Нужна meta-роль ownership — кто решает, какие агенты на каких задачах, где их останавливать, кто отвечает за production-исход — а не набор пилотов с разными спонсорами.
Вердикт
Дневной срез vacancy-intel в 2026 говорит проще, чем хайп-лента: покупают лидеров поставки под platform и production AI. Словарь «AI» обязателен, зрелость разная, modernization (включая SAP) не ушла, а пересеклась с новой повесткой. Founding-CTO и plant-engineering в той же ленте — систематический false positive, если читать без triage.
Если в вашей компании открыли «ещё одного AI-инженера», а в JD соседей уже Head of platform / EM с мандатом на DevEx и governance — вы lag'аете не по модели. Вы lag'аете по оргструктуре поставки.