Copilot написал код, но кто им владеет? Пробел в управлении, который могут упустить инженерные команды

Инженер открывает Copilot, чтобы помочь написать код для сайта клиента. Через несколько секунд он получает код, который ранее потребовал бы значительно больше времени при ручном написании. Для многих веб‑разработчиков и компаний, оптимизирующих свои сайты, естественно задаваться вопросом: насколько надёжный этот код? Безопасен ли он? Нужно ли его проверять перед внедрением? Все эти вопросы сводятся к одному: кто будет нести ответственность за кодирование с помощью ИИ? И, что самое важное, кому принадлежит прирост производительности?

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

ИИ и кодирование становятся неизбежными

Инструменты кодирования с ИИ быстро набирают популярность и проникают в основную разработку. Согласно 2025 Stack Overflow Developer Survey, 84 % респондентов использовали или планируют использовать ИИ‑инструменты в своём процессе разработки.

Хотя внедрение ИИ в рабочие процессы веб‑разработчиков становится всё более распространённым, остаются сомнения в его надёжности. Тот же опрос показал, что 46 % не полностью уверены в точности результатов ИИ, а примерно 66 % назвали решения ИИ, «почти правильные, но не совсем», источником разочарования.

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

ИИ разрывает связь между часами и результатом

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

Контролируемый эксперимент с участием 95 разработчиков показал, что участники, имеющие доступ к GitHub Copilot, завершили конкретную задачу JavaScript HTTP‑сервера на 55,8 % быстрее, чем те, у кого доступа не было.

Это подчёркивает, что ИИ может ускорять разработку, потенциально без потери качества. Однако эти показатели успешны лишь потому, что эксперимент был проведён на очень конкретной задаче программирования. Хотя задача была выполнена быстрее, это не означает, что Copilot делает всю инженерную организацию на 55,8 % более продуктивной.

Другое исследование иллюстрирует эту идею. Эксперимент с участием 96 штатных инженеров‑программистов Google показал, что разработчики, использующие ИИ, завершили задачу корпоративного уровня примерно за 96 минут, по сравнению с 114 минутами у тех, кто его не использовал. Скорректированная оценка исследователей предположила приблизительное сокращение времени выполнения на 21 %. Однако исследование не изучало качество кода, созданного ИИ, и не затрагивало вопросы справедливости в отношении зависимости от технологии.

Также есть доказательства того, что ИИ замедляет время кодирования. Рандомизированное исследование METR включало 16 опытных разработчиков с открытым исходным кодом, которые работали над 246 реальными проблемами в репозиториях, с которыми они были знакомы. Используя инструменты, доступные в начале 2025 года, включая Claude Sonnet 3.5 и 3.7, а также Cursor Pro, они затратили примерно на 19 % больше времени на выполнение задач, несмотря на то, что многие ожидали экономию времени.

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

Проблема ценообразования, о которой никто не говорит

Модель «Время и материалы» (T&M) является распространённой в веб‑разработке при покупке программного обеспечения, так как она решает повторяющуюся отраслевую проблему: развивающийся проект.

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

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

Решение не в том, чтобы поощрять разработчиков работать медленнее. Модель T&M теперь сталкивается со структурной проблемой в дизайне ценообразования и стимулов. Использование почасовой ставки для определения ценности может быть ограничивающим. Покупатель может точно знать стоимость каждого инженерного часа, но оставаться в неведении относительно общей инвестиции, необходимой для достижения желаемого результата.

По мере того как ИИ меняет инженерную продуктивность, вопрос может сместиться от:

• «Сколько стоит час работы разработчика?» → «Что происходит со стоимостью, когда требуется меньше часов разработчика?»

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

Пробел в управлении имеет четыре владельца

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

1. Кто владеет кодом?

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

2. Кто несёт риск?

Быстрый код ценен только тогда, когда он не создаёт проблем в других местах. Эмпирическое исследование кода, сгенерированного ИИ выявило уязвимости в безопасности в 29,5 % изученных фрагментов Python и 24,2 % фрагментов JavaScript. Исследование также обнаружило уязвимости, охватывающие 43 категории из Common Weakness Enumeration.

Однако исследование показало, что передача предупреждений статического анализа обратно в Copilot Chat может исправить до 55,5 % выявленных проблем безопасности. Исследование демонстрирует, как ИИ может создавать и решать проблемы кодирования, но организациям необходимы процессы для определения способов валидации его результатов.

SP 800-218A от NIST отражает этот принцип, расширяя свою структуру безопасной разработки программного обеспечения лучшими практиками, охватывающими генеративный ИИ и модели двойного назначения.

3. Кто владеет приростом продуктивности?

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

4. Кто отвечает за приоритизацию?

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

Управление ИИ становится финансовым вопросом

Эти вопросы делают управление ИИ всё более актуальным. Представьте двух партнёров‑разработчиков, взимающих похожие почасовые ставки.

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

Покупателям придётся оценивать:

• Общая ожидаемая инвестиция
• Ответственность за перерасход
• Контроль качества работы, созданной ИИ
• Как распределяется выгода от повышения эффективности

Модель T&M может оставаться полезной для обеих сторон, если они сознательно принимают неопределённость в услугах. Соглашения с фиксированной ценой также могут работать, когда требования и результаты стабильны.

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

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

Тот же разговор об ИИ

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

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

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

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

Если ваша команда разработчиков примет ИИ уже завтра, подскажет ли ваша текущая модель управления и коммерческая модель, сделала ли она поставку более ценной?