Значительный рост скорости написания программного обеспечения больше не является единственным вызовом для команд разработки. По мере того как такие инструменты, как Cursor, переходят от предложений кода внутри среды разработки к выполнению полноценных задач на основе спецификаций и тикетов, проблема может заключаться в способности организации определить, что стоит создавать, тестировать и безопасно развёртывать, а затем эксплуатировать и обслуживать.
Именно этому посвящено выступление Hannah Foxwell под названием «Переосмысление команды разработки», в котором основное внимание уделяется влиянию агентного программирования на людей и процессы, а не возможностям самих агентов. Foxwell строит своё рассуждение на трёх опорах, которые, по её мнению, сохраняют важность независимо от того, насколько ускоряются инструменты.
От нехватки скорости к избытку возможностей
Foxwell описывает путь, начавшийся с команд, выпускавших программное обеспечение дважды в год, а затем прошедший через Agile, облачные вычисления, DevOps и непрерывную поставку к нескольким развёртываниям в день. Она считает, что то, что раньше преподносилось как далёкая цель, — высокая скорость — начало превращаться в реальность, которой организации пока не знают, как воспользоваться.
В модели агентного программирования агенты могут декомпозировать спецификации, писать код и тесты, а затем помогать с развёртыванием и мониторингом. Однако эта возможность может создать обратное давление на управление продуктом: команды разработки могут выполнять работу быстрее, чем организация способна предоставлять чёткие и квалифицированные требования. Поэтому Foxwell не считает решением принятие каждой идеи или запроса, поскольку это может привести к раздутым продуктам без чёткого фокуса.
Первая опора: создавать то, что стоит создавать
Foxwell подчёркивает, что код — не цель, а средство решения реальной проблемы пользователя. По мере снижения стоимости проверки идей предпочтительнее создавать прототипы и тестировать их с пользователями, прежде чем превращать их в долгосрочное обязательство внутри продукта.
Среди предложенных в материале моделей — «продакт-менеджер, который программирует прототипы», чтобы сократить расстояние между идеей и тестированием, либо объединение продакт-менеджера с разработчиком, когда идея выходит за пределы возможностей быстрого прототипирования. Также упоминается роль полевого инженера — инженера, работающего рядом с клиентом и уполномоченного решать его проблемы, — и «продуктового инженера», участвующего в формировании продукта, поскольку он сам является его пользователем или близок к его пользователям.
Foxwell приводит эксперименты по пересмотру размера команд и их соотношения. Вместо модели команды из шести-восьми разработчиков и одного продакт-менеджера некоторые организации тестируют меньшие команды, тогда как Andrew Ng предложил противоположную модель, включающую двух продакт-менеджеров на одного разработчика, способного координировать целый флот агентов. Эти модели не предлагаются как фиксированные правила, а рассматриваются как эксперименты, отражающие перемещение узкого места от возможностей разработки к ясности требований и скорости принятия решений.
В то же время материал предостерегает от таких практик, как выпуск функции с немедленным переходом к другой задаче без анализа её использования, принятие каждого клиентского запроса или использование мнения самого высокооплачиваемого руководителя в качестве критерия приоритета. В среде, где написание программного обеспечения становится быстрее, исследование пользователей, пользовательский опыт и способность подтвердить ценность могут стать более важными факторами дифференциации, чем сама скорость выполнения.
Вторая опора: скорости нужна безопасность
Рост объёма изменений требует производственного процесса, способного ему соответствовать. Foxwell предупреждает, что пробелы в покрытии тестами и ручные этапы могут превратить процесс развёртывания в узкое место, из-за чего изменения будут накапливаться до момента их доставки пользователям.
Поэтому материал связывает скорость с автоматизированным тестированием, приводя примеры использования агентов для создания непрерывных тестов и помощи командам в устранении технического долга, миграции со старых платформ и реструктуризации кодовых баз. Идея заключается не в том, чтобы добавить искусственный интеллект поверх медленного процесса, а в том, чтобы заново спроектировать путь в production так, чтобы он выдерживал новый темп изменений.
Foxwell подчёркивает, что надёжность и безопасность не являются приемлемыми компромиссами ради скорости. Она предлагает опираться на показатели, уровни целей обслуживания и бюджеты ошибок, а также на письменную политику, определяющую действия организации при превышении допустимого уровня сбоев, например замедление выпусков или перенаправление ресурсов на надёжность и устойчивость.
Она также считает, что поэтапное развёртывание, feature flags, A/B-тестирование и сине-зелёные развёртывания помогают управлять большим количеством изменений, не подвергая им сразу всех пользователей. При этом пересматривается роль команд Site Reliability Engineering и внутренних платформенных команд: они рассматриваются как консультативные и расширяющие возможности функции, обеспечивающие безопасный и подготовленный путь для команд разработки.
Что меняется на практике?
Редакционный вывод из выступления заключается в том, что одни лишь агенты не доказывают, что команды разработки станут меньше или что рабочие места исчезнут. Несомненно другое: узкие места переместятся — от производства кода к выбору проблем, проверке ценности, расширению тестирования, контролю надёжности и быстрому принятию решений.
Открытым остаётся вопрос, будут ли организации использовать новые возможности для создания лучших продуктов и проверки идей или ответят на них накоплением ещё большего числа функций. Новые соотношения между разработчиками, продакт-менеджерами, платформенными командами и командами надёжности также остаются экспериментами, а не подтверждёнными результатами. Поэтому внедрение агентного программирования требует измерять его влияние на качество продукта, инциденты и пользовательский опыт, а не ограничиваться подсчётом строк кода или скоростью выпусков.