Product Engineer: почему ИИ сливает продакта и разработчика в одну роль

Представьте типичный продуктовый конвейер. Продакт неделями собирает данные и защищает идею перед руководством, дизайнер рисует макеты, разработчик получает готовое ТЗ, тестировщик проверяет, аналитик смотрит A/B. Каждый отвечает за свой кусок, а пользователя видит в лучшем случае один человек. Теперь на рынке появляется вакансия, которая пытается свернуть всю эту цепочку в одну роль — Product Engineer.

Это мнение практика, а не исследование. Автор больше 20 лет в ИТ, развивал Маркет ВКонтакте (MAU 14 млн) и сейчас запускает собственный продукт. Но сигналы, на которые он опирается, вполне проверяемы.

Что это за роль

В вакансиях Y Combinator, PostHog и в статье команды MWS/МТС набор требований похож. Нужно продуктовое мышление, умение разговаривать с пользователями, способность сформулировать бизнес-проблему и full-stack навыки, чтобы самому сделать решение и довезти его до продакшена.

Главное отличие от обычного разработчика в контуре ответственности. Обычный разработчик берёт сформулированную задачу и часто никогда не видит конечного пользователя. Product Engineer сам находит проблему, сам решает, каким должен быть результат, пишет код, выкатывает его и обязательно проверяет влияние на метрики. По сути, это продакт и инженер в одном лице.

Идея не новая: бизнес давно мечтал о таких универсалах. Но совместить в одном человеке инженерное и предпринимательское мышление почти нереально, слишком разные навыки и темпераменты. ИИ закрывает недостающую часть стека.

Почему именно сейчас

Автор приводит несколько сигналов.

Массовое использование ИИ. По официальным данным, каждую неделю Claude Code используют 11 млн разработчиков, Gemini — 8,5 млн, Codex — 5 млн. В России, по данным ВШЭ, в небольших организациях ИИ применяют 4,8%, а в крупных ИТ-компаниях — 71%. Правда, выборка смещена в сторону компаний на 500–10 000+ человек, так что цифры по крупным компаниям стоит читать с поправкой.

Рутина уходит к ИИ. Продакты используют его для поиска информации, анализа данных и генерации требований. Разработчики, по опросу Stack Overflow, — для генерации и рефакторинга кода, отладки, тестов и документации. За людьми остаются коммуникация, ответственность за результат (проверить, выбрать дату релиза, исправить инцидент) и лидерство.

Агенты становятся специалистами. Система SKILLS.md превращает агента в узкого помощника с инструкциями, памятью и сценариями. Есть фреймворки оркестрации: CrewAI, Google ADK, OpenAI Agents SDK, Claude Agent SDK. Автор сам использует набор скиллов Гарри Тана, главы YC, который частично заменяет ему команду разработки.

Бигтех сокращает штат. Oracle, Amazon, Dell, Cisco и Atlassian уволили сотни тысяч человек. Спрос на тех, кто только набирает код руками, падает.

Какие навыки нужны

Список автора можно свести к пяти пунктам:

• Работа с агентом как с коллегой. Документация и доступы в проекте нужны не только людям, но и ему, поэтому окружение надо строить с расчётом на обоих.
• Делегирование. Задачу выполняет агент, а ответственность остаётся на вас. Для этого нужно задавать правильные вопросы и уметь оценивать результат.
• Умение договариваться. Раньше за технарей это делали продакт и тимлид, теперь придётся самому.
• Маркетинговый взгляд. Код пишет каждый третий, ценность теперь в понимании потребностей пользователей и в ценностном предложении.
• Архитектура. Прочная архитектура по-прежнему нужна, а ручной набор кода обесценивается.

Что с этим делать

Если вы разработчик, начните с того, чего конвейер вам не давал: сходите на пару интервью с пользователями, заведите метрики на свою фичу и посмотрите на неё после релиза. Если вы продакт, попробуйте самостоятельно собрать прототип с помощью агента и довести его до деплоя. Если вы основатель или нанимаете людей, проверьте в вакансиях, не просите ли вы «универсала» без понимания, как он будет сочетать роли.

Ограничения тоже есть. Это авторская гипотеза, а не подтверждённый тренд: вакансий с таким названием пока мало, а в проектах со 100+ участниками, как интеграция ВКонтакте с Ozon, одним человеком не обойтись. Кроме того, ИИ ускоряет рутину, но не снимает ответственность. Скорее всего, Product Engineer появится в небольших командах и стартапах, где у каждого широкий контур задач, а в больших компаниях конвейер останется. Сама идея при этом полезна: чем короче путь от проблемы пользователя до метрики, тем меньше времени и смысла теряется на передачах между ролями.