Продуктовый инженер: как изменится роль программистов в ближайшие 3 года

Глеб пишет код за деньги с 2003 года: работал в NVIDIA, девять лет развивал студию заказной разработки, три года занимался образованием в Skillbox, а затем пришёл в Сбер. Чтобы не наблюдать агентную революцию только из менеджерского кресла, он на полгода вернулся в индивидуальную инженерную роль и ежедневно работал по десять-двенадцать часов. Перелом он почувствовал ещё с GPT-3.5: модель увидела в старом JavaScript-коде не набор строк, а реализацию мемоизации и уязвимости вокруг проверки входных данных. В 2024 году он решил, что генеративные модели окажутся рядом почти с любым цифровым продуктом: от разработки до гиперперсонализированного пользовательского опыта. Это не означало, что каждая инициатива выживет — в исследовательской работе большинство попыток закономерно закрывается, — но означало необходимость войти в практику самому. Позднее агенты смогли исследовать сложный супервизор для параллельной разработки микрофронтендов и указать на проблемы управления портами в рантайме — выводы, которых Глеб ожидал бы от сильного Staff-инженера. Теперь он может поручить пяти потокам разные варианты одной функции, получить работающий код с тестами и оставить лучший. Вместо двух-трёх завершённых задач за день появляются десятки, а короткий цикл результата создаёт почти азартную дофаминовую петлю.

Из этого опыта рождается определение продуктового инженера. Это не человек, которому добавили обязанности продакта, аналитика, архитектора и дизайнера без снятия прежней нагрузки. Это инженер, отвечающий не за участок кода, а за целую пользовательскую проблему. Глеб вспоминает задание в NVIDIA семнадцатилетней давности: обойти пользователей системы тестирования игр, понять их скрипты и недостающие возможности, защитить новый интерфейс, реализовать его поверх существующих сервисов, покрыть тестами, ввести в эксплуатацию и собрать обратную связь. Такая роль существовала задолго до AI, но была характернее для сильных инженерных культур и небольших компаний. Агенты делают её массовее: узкие функции фронтенда, бэкенда и инфраструктуры частично схлопываются, а два-три инженера с разными сильными сторонами могут закрыть поток, для которого прежде собирали большую кросс-функциональную команду. В платёжных, государственных, космических и других критичных системах специализация останется дольше: цена ошибки там требует более консервативной проверки.

Меньшая команда не означает автоматического сокращения продукта до прежнего объёма. Удешевление производства освобождает ресурс, но конкуренты тоже вкладывают его в новые возможности, поэтому рынок скорее потребует больше экспериментов. Проблема в другом: если поставка изменений позволяет реализовать в пять раз больше, нижние четыре пятых старой очереди задач не становятся ценными. Продуктовая функция должна с той же скоростью находить потребности, формулировать гипотезы и проверять влияние на метрики. В разговоре это объясняется через теорию ограничений: корова может дать сто литров молока, но двадцать крышек ограничат выпуск двадцатью бутылками; после покупки крышек ограничением окажутся пятьдесят самих бутылок. Так же после ускорения кода очереди возникают в бизнес-требованиях, ревью кода, тестировании, интеграции, выкладке, наблюдаемости и разборе инцидентов. Пять работающих вариантов интерфейса ещё нужно безопасно показать пользователям, развести эксперименты и отличить эффект изменения от фонового шума.

Ответственность продакта при этом не исчезает: исследовать потребности, описывать желаемые возможности продукта, приоритизировать, работать с каналами и после выпуска проверять полученную ценность. Модель может помочь превратить сырой разговор в ясные бизнес-требования, сценарии и критерии приёмки, но исходные знания и решение о ценности остаются у человека. Менеджеру тоже не получится просматривать разросшиеся бэклоги и передавать вниз готовые ответы через несколько слоёв трактования. Целеполагание остаётся наверху, а команды ближе к контексту должны сами выбирать следующий способ достижения цели. Поэтому организация становится более плоской не в смысле отсутствия руководства, а в смысле меньшего числа передач и большего содержания на каждом уровне. Существующие устойчивые процессы нельзя мгновенно превратить в AI-native: сначала рядом появятся новые контуры для продуктов с приемлемым риском, затем практика постепенно перейдёт в более критичные области.

Опытному программисту сложнее всего расстаться с мыслью, что его главное предназначение — вручную писать чистый, модульный и хорошо протестированный код. Глеб пересказывает близкий ему принцип: инженер решает известные проблемы и обнаруживает неизвестные, а код — лишь один из возможных инструментов. Дорогими становятся оставшиеся раньше на периферии навыки: сформировать технический образ результата, выбрать стратегию движения, декомпозировать, задать архитектурные и нефункциональные свойства, определить независимые проверки и скорректировать путь. Модели не обнуляют накопленный опыт — он нужен, чтобы увидеть неверное решение вне локального участка, выбрать готовый компонент вместо сорока часов разработки или понять, где автоматизированной системе нельзя доверять. Но практику приходится перестраивать. Сам Глеб говорит о нескольких месяцах интенсивной работы, рекурсивных снах с незавершённой отладкой и новом способе мыслить об организации агентов; одной статьи и готового набора промптов недостаточно.

Для джуна проблема обратная: качественный pull request больше не показывает, чему научился человек. Он мог сформулировать цель и ограничения, проверить план, понять архитектуру и владеть выпуском — или просто передать модели номер задачи. Простые работы не исчезнут полностью: в больших системах всегда останутся изменения меньшего масштаба, риска и числа неизвестных. Но руководителю нужно явно определить уровень абстракции, на котором новичок обязан понимать систему, и наблюдать не только артефакт. Полезны разговор о ментальной модели функции, разбор истории работы с агентом, реакция на новое условие, способность объяснить инцидент и качество самостоятельной проверки. Ответственность делится с создателями платформы: если автоматизированный контур обещал выдержать заданную нагрузку и не выдержал, это ошибка системы, а не только исполнителя. Рост проявляется в объёме сложности, который человек способен осмысленно удерживать, и в импакте своего уровня — от готовой функции и документации до улучшения Developer Experience, надёжности или отрицательного результата исследования. Участники предостерегают от счётчиков ради счётчиков: число агентов, циклов и выпущенных изменений легко превращается в новую погоню за значками. Полезность может проявиться не только в продуктовой метрике, но и в устойчивости, качестве внутренней среды или знании о направлении, которое проверили и обоснованно закрыли.