В ваших системах уже есть слепые зоны. ИИ только усугубляет их.

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

Тогда я размышлял о разрастании SaaS, а не о коде, сгенерированном ИИ. Но сегодня моя философия ещё более актуальна и важна для поддержания.

Многие из нас прочитали отчет DORA 2025, который обнаружил, что, в отличие от предыдущего года, внедрение ИИ теперь положительно коррелирует с пропускной способностью доставки. Вывод заключался в том, что нестабильность доставки продолжала расти, и они проверяли, покрывают ли прирост скорости эту проблему. Нет. Это соответствует нашему опыту. Наша команда приняла агентный подход к разработке и увидела рост пропускной способности на 48 % за два квартала, за которым последовал рост проблем со стабильностью на 16 %. Десять человек — небольшая выборка, но это также выборка, из которой я могу увидеть полную картину, и закономерность сохранялась.

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

Разрыв всегда был. ИИ лишь расширил его.

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

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

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

Тем не менее, мы всё ещё отвечаем за те же цели. Вы всё ещё отвечаете за скорость, качество, затраты и реальное состояние вашей команды. Вы больше не можете слепо доверять прошлогодним панелям мониторинга.

Здесь есть справедливое возражение. отчет DORA о ROI 2026 описывает J‑кривую: падение продуктивности сразу после внедрения, вызванное кривой обучения, стоимостью проверки кода, сгенерированного ИИ, и downstream‑процессами, которые ещё не успели адаптироваться. Они называют это «стоимостью обучения» трансформации и предупреждают руководителей не принимать её за провал. Справедливо. Но стоимость обучения и реальная проблема выглядят одинаково на панели, построенной из тикетов. Если вы не можете понять, в какой из них находитесь, вы не проявляете терпения. Вы угадываете.

Нужно вернуться к основам. Познай себя. Познай свою команду. Пойми, какие проблемы вы решаете.

Как «познать себя» с помощью ИИ?

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

Слепая зона 1: Театр скорости

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

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

Слепая зона 2: Долг ревью

Пропускная способность ревью не масштабируется автоматически вместе с объёмом выпуска. Налог на проверку — это не просто этап, который нужно пройти; это часть постоянных расходов на агентное развитие. A недавнее исследование руководителей инженерных команд выявило, что 80% команд тратят как минимум 10% своего времени на ревью, и примерно каждая десятая тратит более 40%. При такой нагрузке команды колеблются между растущей очередью и формальным одобрением, и ни то, ни другое не является реальным решением.

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

Слепое пятно 3: Скрытая работа

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

Чтобы понять, сколько работы действительно выполняется, необходимо отслеживать, насколько меняется кодовая база и история pull‑request’ов. Без этого ваш план пропускной способности строится на том, что люди запомнили и записали, а не на том, что они действительно сделали. 

Слепое пятно 4: Дрейф качества

То же исследование показало, что почти половина руководителей инженерных команд сталкивается с трудностями в обнаружении проблем безопасности из недели в неделю. Сложность, дублирование и зависимости, которые не совсем уместны, накапливаются в большом количестве небольших, по отдельности разумных изменений. Ни одно из них не выглядит тревожным само по себе. В том же исследовании Стэнфорда качество кода упало на 9% , а его дисперсия более чем утроилась. Среднее значение изменилось немного, но разброс (то, что заметно) изменился значительно. При объёмах ИИ они накапливаются быстрее, чем большинство процессов ревью успевают их поймать. Дрейф обычно проявляется как оповещение on‑call, связанное с зависимостью, которую никто не помнит проверять. К тому моменту есть хорошая вероятность, что клиент заметил проблему первым.

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

Слепое пятно 5: Непроверенные расходы

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

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

Начните с того, чего вы не видите

Вопрос финансов о капитализируемых расходах и страница on‑call в 2 утра кажутся несвязанными, но так не является. Оба могут быть «примерно оценены» по активности. И тем не менее оба поддаются ответу с доказательствами, исходя из самого кода.

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

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