Привет, Хабр! С вами Александр Бондаренко, CPTO Garage Eight. В одной из предыдущих статей мы обсуждали, как эволюционирует Agile-подход, и пришли к выводу, что сегодня это уже не «набор ритуалов», а культурный фон, на котором строятся другие практики.

Теперь давайте разберемся, какие трансформации происходят в продуктовой разработке и почему мы вступаем в эпоху пост-Agile, платформенных команд и агентных связей. Как итеративная разработка переходит к непрерывному созданию продуктов и услуг, а на смену кросс‑функциональным командам приходят ИИ-агенты? Обо всём по порядку.

Погнали!

Как строилась работа команд раньше и что происходит сейчас

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

Нужно было запоминать всё: от настройки серверов и баз данных до верстки пользовательского интерфейса и бизнес-логики. Наш мозг — невероятная штука, но на такое он вряд ли способен. Тогда возникли Agile-команды: специалисты разделились на роли, стали быстрее тестировать гипотезы и более гибко адаптироваться к меняющимся условиям.

Со временем в нашей жизни и работе стали появляться новые технологии, ИИ-помощники, и Agile-командам пришлось переформироваться. Процесс стал делиться на роли, где каждая должна отвечать за отдельный процесс в общей цепочке.

Например, Backend — бизнес-логика и данные, Frontend — пользовательский интерфейс, QA — проверка качества, Product Owner — управление требованиями.

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

Как было: организационная единица — команда или так называемый отряд. 

Как становится: организационная единица — агентная сеть.

Феномен Product Engineer: схлопывание ролей

Вероятно, в будущем мы будем наблюдать частичное схлопывание ролей и появление гибридных компетенций. Фокус смещается с технической широты стека на полную цепочку создания ценности с помощью ИИ. Так на сцену выходит Product Engineer.

Кто такой Product Engineer

Product Engineer — это человек, который может закрыть полный цикл разработки. Он понимает продукт и бизнес, поэтому с помощью инструментов:

• реализует ценность в коде,

• пишет документацию,

• настраивает тесты,

• доводит результат до клиента.

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

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

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

Насколько реально продакт-инженерам перестроиться на автономные процессы

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

• Дизайн и фронтенд. Инструменты вроде v0.dev или Lovable позволяют инженеру описывать интерфейс на естественном языке и получать готовый React-код, который отвечает дизайн-системе компании. Исчезает необходимость в отдельном верстальщике для прототипирования и создания MVP.

• QA и тестирование. Генеративные модели способны автоматически создавать юнит-тесты, интеграционные тесты и даже E2E-сценарии на основе анализа кода. Роль QA трансформируется из «написания тест-кейсов» в «проектирование стратегии качества» и управление автоматизированными Quality Gates.

• Документация и анализ. ИИ-агенты могут автоматически документировать код и анализировать легаси-системы. В итоге они снижают порог входа в сложные проекты.

Однако это не значит, что теперь можно смело переходить к модели One-Person Team, где один человек заменяет целую команду. Это несет в себе колоссальные риски для энтерпрайза.

Почему модель One-Person Team не подходит даже с учетом автономности процессов

Переход к одиночкам-героям без страховочных механизмов создает экзистенциальные угрозы для продукта и бизнеса:

• Хрупкость знаний. Если Product Engineer уходит из компании, он забирает с собой не только понимание бизнес-логики, но и специфический контекст промпт-инжиниринга. Система становится необслуживаемой — магия создания кода ушла вместе с автором.

• Отсутствие критики. Работа в одиночку лишает инженера обратной связи. «Туннельное зрение» может привести к архитектурным ошибкам, которые уходят сразу в прод.

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

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

Чем заменить модель One-Person Team

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

1. Резервировать знания. Если один инженер выпадает, остальные сохраняют полный контекст системы и архитектуры (Bus Factor > 1). 

2. Сохранять скорость коммуникации. Синхронизация происходит мгновенно в рабочем процессе. О Scrum и прочих ритуалах можно спокойно забыть.

3. Контролировать друг друга. Второй инженер выступает критиком и валидатором AI-решений — предотвращает «туннельное зрение» и обеспечивает чистоту архитектуры (Code Review on The Fly).

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

Платформенные команды как архитекторы качества

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

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

Какие концепции будет применять в работе платформенная команда

Давайте для понимания снова ненадолго вернемся к Agile. В традиционном подходе контроль качества осуществлялся через людей: QA-инженеры проверяли функционал, архитекторы утверждали дизайн, безопасники проводили аудит перед релизом.

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

• Golden Paths. Стандартизированные шаблоны сервисов, где всё настроено из коробки. Инженеру не приходится тратить время на конфиги.

Пример: инженер хочет создать новый микросервис. Вместо того чтобы вручную настраивать CI/CD, подключать библиотеки логирования и проходить проверки безопасности, он использует шаблон платформы. Этот шаблон уже содержит встроенные проверки, подключение к мониторингу и правильные версии библиотек.

• Policy-as-Code. Кодификация правил организации через Open Policy Agent (OPA) и автоматическая блокировка нарушений.

Пример: инженер добавляет в Dockerfile инструкцию FROM node:14. В политике OPA прописан запрет на использование версий Node.js старше 18-й из‑за уязвимостей. Деплоймент блокируется с сообщением: «Версия Node.js устарела. Используйте версию ≥18».

• Quality Gates. Контрольные точки, которые код должен пройти перед попаданием в продакшен. Они заменяют ручной QA и позволяют безопасно масштабировать AI-кодинг.

Пример: перед деплоем в продакшен автоматически запускается нагрузочный тест — например, с помощью JMeter или k6. Если система не выдерживает целевую нагрузку, скажем 1000 RPS, или время отклика превышает 500 мс, релиз блокируется. Команда получает отчет: «Нагрузочный тест не пройден. Время отклика — 750 мс при нагрузке 1000 RPS».

Какие гипотезы о трансформации команд появляются в 2026 году

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

На этом же этапе появляется новая сущность — агентские организации. Структура смещается от фиксированной иерархии людей к динамической сети «человек ↔ агент». Есть два основных паттерна оркестрации:

• Sequential. Человек ставит задачу → агент-исследователь находит данные → агент-кодер пишет решение → агент-ревьюер проверяет.

• Group Chat. Product Engineer находится в чате с несколькими специализированными агентами — дизайнером, архитектором, тестировщиком — и управляет их дискуссией для разработки оптимального решения.

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

Важно отметить, что для большинства компаний это пока не реализованная модель, а скорее направление экспериментов. 

В Garage Eight мы также начинаем аккуратно тестировать подобные форматы. Так, например, уже сейчас мы запускаем три новые pod-команды — одну платформенную и две продуктовые. А во втором квартале этого года планируем попробовать протестировать этот подход и в двух других направлениях. Однако это не замена существующих команд, а способ проверить гипотезу о том, как может измениться структура разработки в будущем. 

Системные риски: модель «продакт-инженер + платформенная команда» неидеальна

Я бы выделил три основных риска.

1) Epistemic Debt. Это когда мы генерируем код, который не понимаем. AI генерирует код мгновенно — разрыв между объемом сгенерированного кода и способностью человека его осознать растет экспоненциально. Через год ваша система может превратиться в «черный ящик».

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

2) Vibe Coding и иллюзия компетентности. Это когда инженер итерирует промпты до тех пор, пока результат не станет «похож на правду». Сам же при этом не вдается в детали.

Исследования показывают, что до 40% AI-сгенерированного кода содержит уязвимости, так как модели обучались на данных во всём интернете, включая плохие примеры. Кроме того, часть информации может быть вовсе выдуманной. Без погружения в детали продакт-инженер может пропустить критическую уязвимость и подвергнуть систему опасности.

3) Junior Gap. Если AI выполняет работу джуниоров, молодым спецам не на чем учиться. Разработчики «среднего класса» исчезают. Новые сотрудники должны сразу обладать уровнем Senior+ в системном мышлении, чтобы управлять AI. Такая тенденция создает риск кадрового голода в будущем.

Что в итоге

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

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

Но полностью делегировать разработку AI без контроля — всё ещё утопия. Поэтому любые эксперименты с моделью продакт-инженеров или более компактными командами возможны только при условии сильной платформенной основы, стандартов и автоматизированных quality-gate’ов.

И не спешите списывать Agile. Скорее он постепенно перемещается из набора процессов и ритуалов в инфраструктуру и код — через стандарты, платформу и автоматизацию.

А вы что думаете? Уже замечаете, как меняется роль инженеров и продуктовых команд с появлением AI, или пока всё выглядит скорее как набор экспериментов? Давайте обсудим в комментариях.