OpenAI, Anthropic и Google боятся одного вопроса от технических директоров

Поставщики ИИ-инструментов для разработчиков — от OpenAI и Anthropic до Google и десятков стартапов с ИИ-агентами для написания кода — имеют общую заинтересованность в том, чтобы вице-президенты по инженерии никогда не задали один конкретный вопрос. Не «сколько сотрудников используют инструмент?» и не «насколько вырос объём генерируемого кода?»

Их настоящий страх — вопрос «каковы реальные результаты для бизнеса?» Внедрение ИИ в разработку программного обеспечения действительно взрывное. GitHub Copilot отчитывается о миллионах активных пользователей.

Cursor, Replit, Windsurf и десятки менее известных инструментов захватывают бюджеты технологических команд по всему миру. По данным отраслевых исследований, более 70% разработчиков в крупных компаниях уже используют хотя бы один ИИ-инструмент для написания кода. Весь рынок ИИ-ассистентов для разработчиков, по оценкам аналитиков, к 2027 году превысит 10 миллиардов долларов.

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

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

Для оценки настоящего влияния ИИ на производительность команды нужны базовые данные до внедрения, корректные контрольные группы, устойчивые определения понятия «производительность» (что само по себе предмет горячих дискуссий в инженерном сообществе) и время — минимум несколько кварталов. Поставщики инструментов заинтересованы в продлении лицензий и в ярких маркетинговых историях об успехе, а не в строгих исследованиях, которые могут показать скромный или даже отрицательный эффект в ряде сценариев. Немногие независимые исследования на эту тему дают неоднозначные результаты.

Эксперименты GitHub показали рост производительности на 55% для специфических задач вроде написания HTTP-сервера с нуля. Другие исследования — в том числе от METR и независимых лабораторий — фиксировали значительно более скромные показатели или предупреждали, что прирост в скорости написания кода нередко компенсируется ростом времени на ревью и отладку ИИ-сгенерированного кода. Реальность сильно зависит от типа задач, уровня опыта команды и того, насколько грамотно выстроен процесс работы с инструментами.

Отдельная проблема — ИИ-агенты нового поколения. Если первые инструменты вроде Copilot работали как продвинутое автодополнение, то агенты 2025-2026 годов претендуют на автономное выполнение целых задач: от написания кода до создания PR и прохождения части CI/CD. Это поднимает ставки: если вы не можете измерить ROI от базового ИИ-ассистента, как вы будете оценивать результаты полуавтономного агента?

Главный вывод прост, но неудобен для рынка: инженерным лидерам стоит перестать измерять использование и начать проектировать реальные эксперименты с измеримыми исходами ещё до того, как подписывать шестизначные контракты на ИИ-инструменты. Определите метрики заранее — cycle time, defect rate, PR review time, время онбординга новых разработчиков. Сравните команды с инструментом и без, а не просто отслеживайте общую «удовлетворённость».

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