Продукт-инженер
Специализация продукт-инженера: один человек с AI делает продукт целиком, где AI — рычаг. Что осваиваешь, статьи специализации и карта всех специализаций.
Есть вопрос, который раньше решали только размером команды: как одному человеку собрать продукт целиком — от проблемы пользователя до выката и бизнес-метрики. AI снимает объём работы; методология держит результат согласованным. Их сумма и есть продукт-инженер.
Один человек делает продукт
Прежде, чтобы довести продукт до пользователя, нужны были backend-инженер, frontend-инженер, тестировщик, кто-то по инфраструктуре. Каждый стык между ними — место, где продукт расходится: контракт понят по-разному, данные не сходятся, релиз буксует.
Продукт-инженер закрывает эти стыки внутри одной головы. Набор кода он делегирует AI (тот «прошёл» backend и frontend) — но инженерный фундамент остаётся его: продукт-инженер это full-stack инженер, который прошёл backend и frontend и понимает, что происходит под капотом. AI снял с него печатать, но не понимать: без этого нельзя ни поставить агенту контракт, ни принять его результат. Задача человека — вести продукт: понять проблему, оснастить и направить агента, принять результат, довести до пользователя и померить бизнес-результат. Это продукт-инженерный слой — поверх технических специализаций, а не вместо них.
Это инженер, а не менеджер. Продакт-менеджер решает, что строить, и передаёт дальше. Продукт-инженер решает что — и доводит до пользователя сам, с AI как рычагом. Роль требует инженерного суждения на каждом шаге: контракт для агента, приёмка его кода, поведение под нагрузкой. Без backend/frontend-фундамента это не работает — получится менеджер, который не может проверить, что сделал агент.
Одно знание в двух формах
Каждый кусок методологии существует дважды:
- Статья — тебе. Ты читаешь её здесь, чтобы понять предмет: зачем он, какие развилки, как принять решение.
- Правило — твоему AI-агенту. Тот же предмет как исполняемое правило, которое агент применяет на каждом PR.
Прочитал сам — понимаешь, что делает агент; дал агенту — он держит правило, пока ты думаешь о продукте.
Слой поверх технического крафта
Продукт-инженер опирается на технические специализации, но не переучивает их — этим занят AI. Они — про то, как собрано; продукт-инженер — про то, что и зачем.
| Технический слой | Что закрывает | Кто ведёт |
|---|---|---|
| Backend | Контракты, данные, DDD, брокеры, API | AI + программа |
| Frontend | Компоненты, состояние, формы, доступность | AI + Frontend · Mobile |
| E2E | Сквозные сценарии, Playwright | AI + E2E |
Эти технические программы — фундамент, который у продукт-инженера уже есть: он их прошёл, чтобы понимать агента. Делегирован набор кода, а не понимание — направляешь и проверяешь ты как инженер.
Программа: полный цикл AI-native
Семь фаз — как один человек с AI везёт продукт от идеи до метрик. Открыть программу целиком →
1. Кто такой продукт-инженер — роль и цикл работы: от проблемы до метрики, отличия от разработчика и продакта
2. Как работает ИИ — как работают модели · галлюцинации · токены и стоимость · контекст · вызов инструментов · агенты
3. Работа с агентами — базовый цикл · понимание кодовой базы · разработка функциональности · поиск и исправление ошибок · ревью и тестирование · настройка агентов · Скиллы · MCP · Memory Bank
4. Начать с проблемы — проблема, а не решение · контакт с пользователем · бизнес-метрика · наименьший ценный срез
5. Контракт и оснастка для AI — язык для AI · срез → контракт
6. Сборка и проверка — ревью AI-кода · исполняемые правила vs SonarQube · приёмка результата AI
7. Владение и бизнес-результат — владение от идеи до пользователя · AI как рычаг · релиз и метрики в одиночку · методология для AI
Дальше
- Методология для AI — чем связать весь путь: какие есть способы и какой из них учит этот сайт.
- Backend-программа — технический крафт, который под капотом ведёт AI.
- Кейс маркетплейса — как это выглядит на сквозном примере.