В индустрии разработки программного обеспечения долгое время существовала аксиома: инженер — это главное узкое горлышко (bottleneck) любого проекта. Именно под них подстраивались процессы, создавались методологии Agile/Scrum, а офисы заполнялись спальными капсулами и столами для пинг-понга. Всё ради того, чтобы повысить продуктивность человека.
Однако кейс американской спортивной ИТ-компании PFF (Pro Football Focus), которой управляет распределенная команда инженеров из США, Испании и Индии, доказывает: эпоха классического Scrum подошла к концу. Внедрение автономных ИИ-агентов способно полностью перестроить фабрику разработки, превратив двух инженеров в аналог целого департамента.
Итоги эксперимента: 2 инженера против 10
В январе компания PFF запустила пилотный проект. Вместо того чтобы пытаться заставить людей писать код быстрее, они задались вопросом: «Как сделать так, чтобы ИИ-агенты выполняли работу быстрее, освобождая человека?»
Для эксперимента выделили всего двух сотрудников: сильнейшего фронтендера и опытного фулстек-разработчика. Их результаты сравнили с показателями стандартной продуктовой команды из 10 человек, работающей по классическому Scrum.
Метрики эффективности (Январь — Март)
| Метрика | Команда Scrum (10 человек) | AI-Augmented команда (2 человека) | Результат трансформации |
| Частота деплоев | 1 деплой в 5 дней | 5 деплоев ежедневно | Рост в 25 раз |
| Общая продуктивность(комбинация объема задач и сложности кода) | Базовый уровень | 10x относительно базового | Рост в 10 раз |
| Сроки реализации | 4 месяца (оценка) | Менее 2 месяцев | Сокращение сроков в 2 раза |
| Удовлетворенность клиентов | 7.0 – 7.5 из 10 | 8.6 из 10 | Существенное улучшение качества |
Главный инсайт эксперимента — эффект масштабирования. В старой модели оба инженера были бы заблокированы смежными задачами почти на 3 месяца. В новой модели один из инженеров полностью разблокировал свои задачи меньше чем за месяц и переключился на создание фич, которые компания изначально даже не планировала выпускать.
Смерть Scrum: какие церемонии ушли в прошлое?
Когда код пишут и проверяют агенты, традиционный гибкий процесс становится избыточным и неповоротливым. В PFF полностью демонтировали привычный фреймворк:
- Нет проджект-менеджеров: Больше нет необходимости играть в «испорченный телефон» между бизнесом и разработкой.
- Нет Sprint Planning: Зачем тратить часы на оценку задач (Story Points), если скорость выполнения стремится к нулю? (В будущем планирование заменят на оценку стоимости токенов для выполнения фичи).
- Нет Daily Standups: Агенты обновляют статус задач в Jira/GitHub автоматически на основе состояния ПР (Pull Request). Открыт ПР — задача в статусе In Progress, отправлен на проверку — In Review, смержен — Closed.
- Нет Sprint Refinement & Retrospective: Внутренние метрики заменили сквозными опросами удовлетворенности клиентов и частотой деплоя.
Что пришло на смену?
Вместо жестких спринтов команда перешла на Huddles (короткие созвоны). Раз в два дня инженеры, продуктолог и дизайнер собираются на 30–60 минут, смотрят на готовый MVP в продакшене и дают мгновенную обратную связь.
Конвейер разработки: от идеи до самолечения кода
Процесс разработки в «пост-инженерную» эпоху выглядит как автоматизированная линия сборки на автозаводе, где каждая микро-задача изолирована.
[Идея/Спецификация] ➔ [Интервью с Агентом] ➔ [Авто-генерация LDD] ➔ [Генерация тикетов/кода] ➔ [Авто-QA на Стейджинге]
- Интервью по спецификации: Агент проводит «интервью» с инженером или продактом, задавая уточняющие вопросы по бизнес-требованиям.
- Легковесный дизайн-документ (LDD): Агент анализирует все прошлые архитектурные документы компании и пишет новый LDD. Это гарантирует, что код будет написан в едином стиле (например, с использованием паттерна Service Repository для API, принятого в PFF).
- Создание тикетов и PR: Система сама декомпозирует задачу на пул-реквесты так, чтобы они не блокировали друг друга.
- Агентное QA и «Самолечение»: Как только код попадает на staging, запускается QA-агент. Он вычитывает критерии приемки (Acceptance Criteria) из тикета и тестирует интерфейс.
Вектор развития: Следующий шаг, который PFF внедряет прямо сейчас — автоматическое создание баг-фиксов самим агентом в случае провала теста (концепция Self-healing code).
Какими задачами теперь заняты люди?
Роль инженера радикально сместилась вверх по цепочке создания ценности. Агентам отдают то, что люди искренне ненавидят: проверку код-стайла, нейминг переменных, написание рутинных тестов и логирование.
Человек же выполняет роль системного архитектора и контролера:
- Проектирование и контекст: Фокус на верхнеуровневом проектировании (валидация LDD). Если инжиниринговый документ составлен архитектором точно, ИИ не уйдет в овер-инжиниринг и не напишет тысячу строк лишнего кода.
- Контроль безопасности: ИИ склонны искать кратчайшие пути решения задач, что часто приводит к уязвимостям. Человек обязан жестко контролировать безопасность.
- Сохранение ДНК продукта (Product Feel): Код, написанный искусственным интеллектом, часто выглядит шаблонно и «стерильно». Инженеры PFF следят за тем, чтобы интерфейсы и логика сохраняли уникальный бренд-код компании.
Как перевести свою компанию на новые рельсы?
Майк Спитц дает четыре ключевых совета для технологических лидеров, планирующих пережить эту трансформацию:
- Начинайте с лучших, а не со всей массы. Не нужно покупать подписку на ИИ-ассистентов сразу 100 инженерам и проводить хакатон. Выберите 1-2 разработчиков с самым глубоким системным пониманием вашего продукта — тех, к кому вся команда обычно ходит за советом.
- Формализуйте культуру в «скиллы». Обучайте агентов паттернам вашей компании. Если вы используете Trunk-based разработку и Feature Flags — эти правила должны быть жестко зашиты в промпты и контекст агентов.
- Будьте честны: выживут не все. Инженеры, привыкшие работать исключительно по детальному, разжеванному техническому заданию («скажите мне точно, какую строчку написать»), не смогут адаптироваться. Новая эпоха требует от инженера высокой продуктовой любознательности, системного мышления и навыков системного дизайна.
- Действуйте быстро, но поэтапно. Небольшие стартапы и middle-scale компании (как PFF с их 20 инженерами) имеют колоссальное преимущество перед гигантами с тысячами сотрудников. Они могут перестроить процессы за месяцы. В условиях экспоненциального роста технологий отставание на пару месяцев сегодня превратится в технологическую смерть уже через год.
Считаете ли вы, что вашей текущей команде разработки подошла бы подобная агентная модель, или специфика вашего продукта требует исключительно человеческого контроля над процессами?
На основе Agents Don't Do Standups: Building the Post-Engineer Engineering Org — Mike Spitz, PFF