Product Engineer и ИИ. Почему нельзя сначала сократить команду

Меня настораживает не идея Product Engineer и не использование ИИ в разработке. Меня настораживает управленческое прочтение этой идеи - наконец-то можно получить универсальных, легко заменяемых специалистов, которые будут делать все быстро, качественно и дешево. А остальных — сократить.

Поводом задуматься стала публикация Александра Бондаренко из Garage Eight о Product Engineers. Автор рассматривает небольшие команды с ИИ как эксперимент, а не универсальное решение.

В комментариях одни ждут сокращений, другие — роста затрат на поддержку. Звучат и напоминания о давно существующих универсалах и сложности освоения смежных профессий.

У меня эта дискуссия вызывает прежде всего вопрос: почему мы когда-то разделили роли и какую именно причину этого разделения теперь устраняет ИИ?

Я работаю в IT с 2007 года. За это время видел и сильные универсальные команды, и ситуации, в которых без отдельного человека, понимающего бизнес, разработка начинала буксовать. Поэтому хочу посмотреть на Product Engineer не через обещание заменить несколько должностей одним человеком, а через опыт организации инженерной работы.

Универсальный инженер — не новость

В начале профессионального пути я думал, что любой сильный senior-разработчик способен закрыть практически любую задачу. Потом выяснилось, что таких людей не так много. А широкая специализация не означает одинаково глубокую экспертизу во всех направлениях. Потом я узнал про Т-шейп, но сейчас не об этом.

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

Это не человек, который заранее знает все. И не человек, который уверен, что способен обойтись без чужой экспертизы. Его важное качество — способность учиться и понимать ситуацию, включая бизнес, ради которого вообще создается система.

В небольших компаниях мне часто встречалась потребность именно в универсалах с рабочими знаниями в нескольких областях. Отдельного специалиста на каждую функцию там просто нет. Но из этого не следует, что такую же организацию работы можно без изменений перенести в большую IT-компанию.

Поэтому новое название само по себе меня не впечатляет. Интереснее другое, насколько новые инструменты расширяют возможности инженера и что должно измениться вокруг него, чтобы этим расширением действительно можно было воспользоваться.

Зачем нам понадобились аналитики

В проектах, с которыми я работал около пятнадцати лет назад, специалисты, выполнявшие аналитическую работу, могли называться методистами или методологами. Так вышло, что в моем опыте не было такого пункта, как работа с аналитиком и получения задач от него, все приходилось делать самому. Я просто делюсь опытом, а не утверждаю, что профессии аналитика тогда не существовало.

Причина появления такой роли была вполне практической.

Чтобы хорошо выполнить задачу, программисту нужно было разобраться в бизнес-домене, особенностях процессов и законодательной базе. Кроме того, требовалось понять, что уже умеет наша программа и как именно это реализовано.

Если разработчик давно работал в этом домене, он мог обходиться без отдельного аналитика, дополнительное погружение не требовало много времени. Но если приходил сильный специалист из другой области, мы фактически теряли его на время изучения контекста.

Мы пробовали работать без методиста. Обычно получали один из трех результатов:

• Бизнес раздражался из-за вопросов, ответы на которые казались ему очевидными.
• Решение приходилось переделывать, мы не учли то, что участники процесса давно знали и не считали нужным объяснять.
• Разработка затягивалась, потому что изучение предметной области занимало больше времени, чем программирование.

Альтернативой были часы сотрудников бизнеса, которые подробно разъясняли разработчику техническое задание. Это тоже трата времени, но за счет времени бизнеса, время разработки тратилось меньше.

Аналитик понадобился не потому, что программист перестал быть умным. Нам стало слишком дорого заново собирать бизнес-контекст для каждого исполнителя.

Поэтому, обсуждая исчезновение роли, я сначала спрашиваю: исчезла ли работа, ради которой эта роль появилась? Или мы просто перестали отдельно ее называть?

Универсальность держалась на процессе

Примерно в 2014–2017 годах у нас была сильная команда с уклоном в универсальность. Начинали втроем, к концу периода выросли почти до двадцати человек. Разбирались в бизнесе, писали код, выполняли инфраструктурную работу — закрывали широкий круг задач.

При этом распределение знаний было неравномерным.

Четыре человека особенно хорошо понимали бизнес. На новые проекты обязательно шли один или двое из них. В инфраструктуре уверенно разбирались двое, и это регулярно становилось источником конфликтов и поводом подтягивать собственные знания.

Небольшие задачи брал любой свободный участник команды. Так мы одновременно ускоряли поставку и расширяли понимание системы. Термин time to market мы тогда не использовали, но по сути постоянно за него боролись: этого требовал бизнес.

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

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

Универсальность — не ровный круг компетенций. Это разные профили, которые хорошо сочетаются в команде.

Нам было важно осознать, кто мы и как работаем, а затем построить процесс с учетом реальных сильных сторон. Не заставить всех соответствовать одному воображаемому профилю.

Документация вместо человека-справочника

С документацией сначала были просадки. По знакомому мему:

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

У нас появилось несколько типов документов.

Мы не пытались написать энциклопедию. Документы помогали не тратить время повторно и снижали зависимость от памяти отдельных людей.

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

Где я жду пользы от ИИ

Если мысленно дать той команде нынешние инструменты, я ожидаю заметного ускорения. У нас было бы больше документации, она могла бы стать подробнее, а поддерживать ее актуальность было бы проще. Тестирование тогда оставалось слабым местом — здесь я тоже вижу большой потенциал помощи.

Правила и инструкции можно было бы оформить в скилы и использовать в работе агентов. Это давало бы шанс не только быстрее получать код, но и последовательнее применять договоренности команды.

Когда меня спрашивают о возможном составе такой команды, моя субъективная оценка — десять–тринадцать человек вместо почти двадцати. Это не результат проведенного внедрения, не расчет экономии и тем более не рекомендация сократить треть сотрудников. Это предположение о конкретной команде, которую я хорошо знал.

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

Этот процесс кажется мне понятным, но не быстрым и не конечным. Есть ограничения проекта и оборудования, сопротивление изменениям и человеческое желание немного расслабиться, раз инструмент выглядит умным, пусть он сам во всем разберется.

Контекст нельзя просто загрузить

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

Появляются новые законы, исключения и ограничения. Нужно не только прочитать изменение, но и понять, как применить его к нашим процессам и какой ценой. Хорошее техническое решение не всегда означает хороший процесс для бизнеса. А иногда хороший выбор цвета в решнии будет играть на вашего конкурента.

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

Есть и более приземленный риск. Можно получить ответ примерно такого содержания:

Расхождений между документацией и кодом не обнаружено. Документация отсутствует.

Это мой ироничный пример из реальной жизни. Он хорошо выражает опасение: формально выполненное действие еще не гарантирует, что у нас вообще были достаточные основания для вывода.

Когда код есть, понимания нет

Один случай хорошо показывает, почему я не хочу считать скорость генерации отдельно от понимания результата.

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

Разработчик не понял, о чем я говорю. Ему понадобилось около двадцати минут работы в отладчике, чтобы найти эту функцию и разобраться, что я имел в виду.

Я не показывал ему конкретную строку в редакторе. Я понимал процесс и логику системы, поэтому мог предположить, где находится проблема. А человек, сгенерировавший код с помощью ИИ, такой картины в тот момент не имел.

Этот эпизод не доказывает, что ИИ замедляет разработку. И двадцать минут сами по себе не выглядят катастрофой. Для меня он про другое: создать реализацию и приобрести рабочую модель системы в голове — не одно и то же.

Если при оценке внедрения учитывать только время до появления кода, подобные затраты просто выпадут из расчета. Они вернутся при исправлениях и следующих изменениях.

Считать нужно до результата

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

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

Для пилота я бы использовал такую схему учета. Это предлагаемая схема, а не отчет о моем уже проведенном эксперименте.

Стоимость общей инфраструктуры я бы считал отдельно, а затем соотносил с количеством задач и команд, которые действительно ей пользуются. Иначе одна команда может демонстрировать экономию только потому, что часть ее работы оплачивает другая.

Мне важно сравнить не «человек писал код» и «модель написала код», а два способа получить сопоставимый по качеству результат. При этом затраты на внедрение и текущие расходы нужно видеть раздельно: без этого трудно понять, что именно мы окупаем.

Я допускаю, что в конкретных условиях ИИзация окажется дороже работы дополнительных сотрудников — даже при похожем результате. Это не аргумент против инструмента. Это причина сначала проверить экономику, а не заранее объявлять ее положительной.

Эксперименты и общий каталог

Кажется что в компании с ростом и развитием технологий должен появится какой-то набор готовых агентов, скилов, MCP и прочих инструментов. При этом общие инструменты должны быть согласованы прежде чем попасть в общий доступ, а вот эксперимент инженера совсем другое дело и там должна быть свобода. Пусть пробует инструменты, создает скилы и проверяет идеи — в рамках правил доступа к данным и допустимой среды.

Но личный эксперимент и инструмент для всей организации — разные вещи.

Если инженер автоматизировал процесс или дополнил скил знаниями о продукте, результат можно предложить в общий каталог. Вот здесь уже нужен понятный порядок рассмотрения: мы предлагаем другим пользоваться этим как частью рабочего процесса.

В качестве минимального порядка я бы рассматривал такой:

1. Автор описывает задачу, ограничения и способ применения инструмента.
2. Показывает примеры результата, включая неудачные случаи, и затраты на проверку.
3. Коллеги проверяют предметную и техническую корректность в пределах своей экспертизы.
4. Для принятого инструмента определяют владельца и способ проверки изменений.
5. После публикации собирают обратную связь и пересматривают устаревшие версии.

Это не готовый регламент и не требование проводить совет ради каждой правки. Конкретная форма должна соответствовать риску и масштабу применения.

Возможно стоит делать несколько согласований или ставить KPI для каталога командам и ролям, но пока это идеи, а не внедренная мной система. При их проработке я бы отдельно проверял, не начинаем ли мы поощрять количество скилов вместо пользы от них. Ценность каталога для меня — в повторном использовании и результате, а не в числе опубликованных файлов.

Как не потерять собственную голову

Второй вопрос — как в такой среде будут появляться новые сильные инженеры.

В нашей команде небольшие задачи помогали людям погружаться в систему. Если отдать их агенту целиком, я не хочу автоматически считать освободившееся время выигрышем, а для начинающего специалиста это могло быть отличным обучением, а для нового сотрудникам отличным вкатом.

Я бы оставлял часть задач новичкам именно как тренировку. И рассматривал бы практику, при которой все разработчики периодически выполняют работу без ИИ — пусть с потерей скорости, но с сохранением самостоятельного навыка.

Условная «одна задача из десяти руками» или такая идея разные лимиты токенов в зависимости от опыта и отдельные учебные режимы. Я их не проверял и не предлагаю считать установленной нормой. Для меня важен вопрос, который стоит за этими идеями: может ли человек объяснить решение, найти ошибку и продолжить работу, если помощь модели исчезнет?

Здесь мне вспомнилась история об исследовании врачей. Работа Budzyń и соавторов в The Lancet Gastroenterology & Hepatology, опубликованная в 2025 году: в четырех мед. центрах Польши изучали колоноскопию до и после внедрения ИИ-помощника. В анализ вошли 1443 такие процедуры. Частота обнаружения аденом снизилась с 28,4% до 22,4% — на 6 процентных пунктов.

Это ретроспективное наблюдательное исследование, а не доказательство того, что именно ИИ вызвал снижение. На ограничения причинных выводов указывают и авторы в сообщении The Lancet об исследовании. Тем более эти данные нельзя напрямую переносить на программистов или выводить из них правило «10% задач без ИИ».

Для меня это повод относиться к сохранению навыков как к вопросу, который надо исследовать и проверять, а не отмахиваться от него словами «теперь думать будет модель».

Ускорение не отменяет отдых

Меня беспокоит еще одна сторона ИИзации. Мы высвобождаем время, но вместо возможности восстановиться человек может получить требование выполнять условные «500% прежней нормы».

Я не рассматриваю эту цифру как измерение производительности. Это образ ожиданий, с которыми легко прийти к сотрудникам: инструмент ускорил отдельные операции, значит, можно пропорционально увеличить поток задач.

Но в той модели работы, которую я хочу построить, остаются понимание контекста, выбор решения и проверка результата. Я бы не планировал загрузку так, будто эти действия ничего не требуют от человека. И не хотел бы обменять экономию на рутинных операциях на постоянную перегрузку.

Часть высвобождаемого времени я предпочел бы оставить на обучение, улучшение процесса и восстановление, а не целиком заявлять и использовать как дополнительную производительность.

Сначала перестроить, потом решать

Если руководитель услышал из всего разговора только «вместо двадцати можно оставить десять», моя первая рекомендация — сохранить команду на время эксперимента.

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

Я бы предложил такой порядок действий:

1. Выбрать ограниченный набор повторяемых задач и зафиксировать исходные затраты и качество.
2. Провести пилот, не лишая команду людей, необходимых для текущих обязательств и настройки нового процесса.
3. Учесть полный цикл работы и расходы на общие инструменты.
4. Проверить не только создание результата, но и последующее исправление или изменение.
5. Посмотреть, где возникло реальное высвобождение времени, а где работа только переместилась к другим людям.
6. По результатам решать, как менять состав команды, объем задач и организацию работы.

Мне близка аналогия с заводом: нельзя считать предприятие автоматизированным в тот момент, когда ему купили коробочное решение. С IT-отделом я бы поступал так же. Чем больше организация, тем больше времени закладывал бы на ее перестройку.

Быстро создать прототип — полезное умение. Но если его легко сделать и так же легко бросить, это нельзя назвать инженерным результатом. Мне важнее понять процесс, довести решение до рабочего состояния, доставить до ПРОДа и уметь его поддерживать.

Я хочу использовать ИИ, чтобы таких результатов становилось больше. Поэтому первый вопрос к пилоту у меня будет не «сколько человек теперь можно убрать?», а «какую работу мы действительно научились выполнять лучше — и можем ли мы это показать?»

В конце не будет вывода, но вы можете прийти в telegram и выразить свои мысли в комментариях.