Недавно мы запустили опрос, чтобы выяснить, насколько глубоко ИИ проник в процессы разработки. Хотели проверить пять гипотез, и вот как они звучали:
ИИ уже перешёл от личного использования к командному и сквозному внедрению.
Глубина внедрения ИИ зависит от размера компании и роли сотрудника.
Применение ИИ вышло за пределы генерации кода.
Чем выше инженерная зрелость, тем глубже внедрение ИИ и заметнее результат.
ИИ скорее убыстряет процесс разработки, чем пишет качественный код.
Мы проанализировали все заполненные анкеты — их оказалось 317. Под катом расскажем, насколько наши гипотезы подтвердились или опроверглись вашими ответами и попутно опишем пару‑тройку других интересных корреляций. Например, мы поняли, что размер компании часто не помогает, а, наоборот, мешает внедрить ИИ по сквозному принципу — «крупняки» делают это на 35% реже, чем небольшие компании. Но обо всём по порядку.
Паспорт исследования
Мы проанализировали 317 полностью заполненных анкет. Ответы собирали со 2 по 15 июля 2026 года. Участники указали должность, грейд, отрасль, размер компании, текущие сценарии использования ИИ и уровень внедрения.
Для анализа мы разделили респондентов на четыре непересекающиеся группы.
В группу разработчиков вошли бэкенд‑, фронтенд‑, fullstack‑ и мобильные разработчики без управленческого грейда. Тимлиды и архитекторы выделялись по должности или грейду. К бизнесу и руководству отнесены владельцы продуктов, руководители направлений, CIO, CTO и другие участники с управленческими ролями.
В выборке было много опытных специалистов:
Среди отраслей чаще всего встречались финтех, разработка и поддержка конкретного программного обеспечения, бигтех, заказная разработка и промышленность.
Мы спрашивали респондентов, насколько глубоко ИИ встроен в работу, кто запустил внедрение ИИ, в каких задачах уже применяется ИИ, есть ли в команде единые стандарты, актуальная документация и доступный для ИИ контекст, насколько ИИ помогает сокращать рутину, готова ли команда расширять применение ИИ, какие препятствия мешают внедрению и какие результаты связывают с ИИ. Под результатами понимались конкретные эффекты: сокращение рутинной работы, снижение затрат, повышение качества кода и тому подобные.
Утверждения о зрелости процессов и фактическом применении ИИ участники оценивали по шкале от 1 до 10. В отдельных вопросах о полученных и ожидаемых эффектах можно было выбрать не более трёх вариантов.
Гипотеза № 1. ИИ уже перешёл от личного использования к командному и сквозному внедрению
Мы предполагали, что ИИ постепенно перестаёт быть личным помощником отдельных специалистов и переходит на уровень командных процессов.
Гипотеза подтвердилась лишь частично: ИИ действительно широко распространён, но чаще остаётся личным инструментом. Сквозное внедрение пока встречается редко.
Уровни внедрения распределились так:
Получается, что у 53,6% участников ИИ либо почти отсутствует, либо остаётся личным инструментом. До нескольких регулярных процессов или сквозной интеграции дошли 32,5%.
Источником внедрения почти в половине случаев была локальная инициатива:
К системным инициативам мы отнесли 142 анкеты: в этих случаях внедрение либо выросло из инициативы сотрудников и стало общей практикой, либо последовательно проводилось руководством. В остальных 175 ответах ИИ использовали локально или внедряли формально.
Затем мы сравнили не просто наличие ИИ, а условия его применения и полученный результат:
Во всех случаях оценки были выше там, где ИИ внедряли системно. То есть различался не только охват, но и выхлоп: команды чаще сообщали о реальном использовании, готовности масштабировать практику и заметном сокращении рутины.
Дополнительные факты
Чем глубже ИИ встроен в работу команды, тем больше задач с его помощью решают. Мы посчитали, сколько направлений применения указал каждый участник: разработку, тестирование, ревью, документацию, архитектуру, CI/CD и другие. Ответы «Другое» и «Не используем ИИ» в расчёт не включали.
Например, показатель 2,96 означает, что участники из группы личного использования в среднем отметили около трёх сценариев. При сквозном внедрении среднее число сценариев увеличивается до шести.
Отдельно мы сравнили два варианта системного внедрения: инициативы, которые выросли снизу, и программы, последовательно запущенные руководством. Участники оценивали по шкале от 1 до 10, насколько ИИ сокращает рутинную работу без ухудшения качества: 1 означал отсутствие заметного эффекта, 10 — максимально выраженный эффект.
Средняя оценка составила:
6,91 балла — для системных инициатив, выросших снизу;
5,84 балла — для программ, последовательно запущенных руководством.
Вывод по гипотезе: ИИ уже используют массово, но до сквозного внедрения во весь процесс разработки дошли немногие. Главная задача теперь — превратить его из личного помощника отдельных сотрудников в общую инженерную практику.
Дмитрий Мацера
управляющий директор по ИТ Совкомбанк Технологии
Разрыв между личным и сквозным применением ИИ нельзя объяснить только качеством модели. Личный помощник — это диалог разработчика с инструментом: он сам проверяет ответ и сам отвечает за последствия. Сквозной сценарий — уже не «доступ к модели», а агентный контур.
В Совкомбанк Технологиях мы видим ту же границу на практике: интерес к ИИ возникает быстро, а переход от личного использования к командному требует уже не новой модели, а договорённостей между разработкой, архитектурой, информационной безопасностью и эксплуатацией. Узким местом оказывается не способность модели написать код, а возможность безопасно встроить её в реальный цикл поставки.
В таком контуре один компонент принимает задачу, другой ищет знания в разрешённых источниках, третий запускает проверку или создаёт черновик изменения. Но у каждого действия должны быть границы прав, журнал, защита от повторного запуска и понятный момент передачи человеку. Иначе компания масштабирует не производительность, а риск.
Поэтому я бы измерял зрелость не числом выданных доступов к ИИ, а долей процессов, где агент может безопасно выполнить ограниченное полезное действие и передать человеку проверяемый результат.
Гипотеза № 2. Глубина внедрения зависит от размера компании и роли сотрудника
До анализа мы ожидали, что крупные организации чаще доходят до сквозной интеграции благодаря бюджету, инфраструктуре и централизованному управлению. Также предполагалось, что разные роли (разработчики, бизнес, тимлиды и архитекторы) будут по‑разному оценивать результаты ИИ.
Первая часть гипотезы не подтвердилась. Вторая подтвердилась лишь частично. Размер компании не стал преимуществом. Среди участников, указавших размер организации, доля сквозного внедрения распределилась так:
В крупных компаниях (500 и выше) внедряют ИИ по сквозному принципу на 35% меньше, чем в небольших компаниях. При этом нельзя утверждать, что крупные компании в целом менее зрелые: статистически устойчивое различие обнаружено именно для сквозного внедрения. Возможные объяснения: более сложные согласования, жёсткие требования к безопасности и большое количество устаревших систем.
Кроме того, мы ожидали, что разработчики чаще будут говорить об ускорении рутины, тимлиды — о контроле и качестве, а бизнес — о сроках и затратах. На практике различия между ролями оказались слабее, чем мы ожидали. Для всех трёх групп главным эффектом стало ускорение рутины: его отметили около 80% разработчиков, тимлидов и представителей бизнеса.
Бизнес действительно несколько чаще говорил о сокращении сроков и затрат, но разрыв оказался небольшим. Снижение затрат выбрали 27,3% представителей бизнеса, 25% тимлидов и 14% разработчиков. Сокращение сроков отметили 45,5, 40,9 и 38% соответственно.
Ожидание, что тимлиды заметно чаще будут говорить о качестве и контроле, не подтвердилось. Снижение числа ошибок они выбирали даже реже разработчиков — 11,4% против 21%. Сокращение технического долга чаще отмечали представители бизнеса, а не технические руководители.
Вывод по гипотезе: размер компании не гарантирует более глубокого внедрения, а различия между ролями слабее, чем различия между системным и несистемным подходом.
Дмитрий Мацера
управляющий директор по ИТ Совкомбанк Технологии
Крупной организации сложнее не выбрать модель, а построить вокруг неё работающий контур. Модель можно протестировать за день. Гораздо дольше занимают подключение к репозиториям и системам задач, разграничение доступа, очистка и актуализация контекста, правила подтверждения действий и доказательства для информационной безопасности.
Именно поэтому быстрый пилот и промышленный агент — разные продукты. В пилоте мы проверяем, умеет ли система отвечать на вопрос. В промышленном контуре — может ли она по разрешённым правилам найти данные, выполнить действие, объяснить его и безопасно остановиться при отклонении.
Размер компании здесь не приговор. Но он делает цену архитектурной ошибки выше: один неуправляемый помощник можно отключить, десятки агентов с разными правами и интеграциями — уже нет.
Гипотеза № 3. Применение ИИ вышло за пределы генерации кода
Мы предполагали, что ИИ уже применяется не только для написания кода, но и на соседних этапах инженерного цикла.
Гипотеза подтвердилась. ИИ уже используют не только для написания кода. 78,2% участников указали хотя бы один дополнительный сценарий — например, документацию, тестирование, ревью, архитектуру или CI/CD. Только 15 человек, или 4,7% всей выборки, выбрали разработку как единственное направление применения ИИ.
Распространение по инженерному циклу идёт неравномерно. Документацию, ревью и тестирование отметила примерно половина участников. CI/CD, управление техническим долгом и анализ архитектуры встречаются заметно реже: для таких задач обычно требуется больше командного контекста, интеграций и формализованных правил.
Самым массовым сценарием ожидаемо остаётся разработка — её выбрали 229 из 317 участников, или 72,2%. Причём чем выше был профессиональный уровень респондента, тем чаще он сообщал об использовании ИИ в разработке:
Отдельно участников попросили оценить утверждение: «ИИ уже помогает команде снижать количество рутинных задач, не ухудшая качество разработки».
Оценку ставили по шкале от 1 до 10, где 1 означала отсутствие заметного эффекта, а 10 — существенное сокращение рутины без потери качества.
Средняя оценка среди пользователей ИИ в разработке составила 6,39 из 10. То есть инструмент уже даёт заметную пользу многим участникам, но устойчивый заметный эффект отмечают пока около четырёх из десяти пользователей этого сценария.
ИИ быстро распространяется среди разработчиков: уже при личном использовании его применяют 78,6% участников, а при переходе к командным процессам доля увеличивается примерно до 86% и дальше почти не меняется. Зато заметно растёт результат: средняя оценка сокращения рутины повышается с 5,46 балла при личном применении до 8,33 балла при сквозном внедрении от идеи до выпуска.
ИИ уже широко используют в разработке. Среди участников, для которых он остаётся личным инструментом, этот сценарий выбрали 78,6%. После перехода к командной работе доля увеличивается примерно до 86% и дальше почти не растёт.
Зато заметно меняется польза. При личном применении участники оценили сокращение рутины в среднем на 5,46 балла из 10, а при сквозном внедрении от идеи до выпуска — на 8,33 балла. То есть дальнейший рост связан уже не с числом пользователей, а с тем, насколько хорошо ИИ встроен в общий процесс.
Распространить помощников среди разработчиков сравнительно легко. Гораздо сложнее превратить их использование в устойчивое сокращение рутины на уровне общего процесса.
Для чего ещё разработчики используют ИИ
Пользователи ИИ в разработке почти никогда не ограничиваются только написанием кода. Из 229 участников этой группы 214 человек, или 93,4%, применяют ИИ хотя бы ещё в одном направлении.
Чаще всего разработчики используют его для работы с документацией и базой знаний — так ответили 65,1% участников. Почти столько же применяют ИИ в код‑ревью — 64,2%, ещё 58,5% — в тестировании. Реже его подключают к проработке MVP, архитектуре и дизайну.
Получается, что ИИ уже стал не только инструментом генерации кода. У большинства участников он постепенно распространяется на соседние этапы разработки — проверку, тестирование, документацию и проектирование.
Генерация документации опережает качество базы знаний
Документация, онбординг и база знаний стали одним из самых распространённых направлений применения ИИ. Этот вариант выбрали 164 участника, или 51,7% всей выборки.
Респонденты оценивали утверждение:
«Команда использует ИИ для актуализации или генерации технической документации».
Средняя оценка составила 5,27 балла из 10.
Отдельно участников спросили, достаточно ли в команде актуальной документации и описанного контекста, чтобы ИИ мог понимать систему и помогать с онбордингом. Здесь средняя оценка оказалась ниже — 4,43 балла.
Получается, что создавать новые документы с помощью ИИ команды уже научились лучше, чем поддерживать цельную и актуальную базу знаний.
Высокую оценку использованию ИИ для документации дали 35% участников. При этом только 21,8% так же высоко оценили полноту и качество накопленного контекста. У 40,7% респондентов оценка генерации документов была выше оценки самой базы знаний. Обратная ситуация наблюдалась только у 17%, ещё у 42,3% оценки совпали. Средний разрыв составил 0,85 балла.
Причина, вероятно, в том, что сгенерировать отдельный документ сравнительно просто. Гораздо сложнее сделать так, чтобы вся документация оставалась актуальной, не противоречила коду, была связана с задачами и архитектурными решениями, имела владельца и регулярно обновлялась.
Поэтому главный разрыв проходит между созданием текстов и управлением знаниями. ИИ уже помогает писать документацию, но для понимания всей системы ему зачастую не хватает качественного и актуального контекста.
Код‑ревью: интерес высокий, а результаты скромные
ИИ для ревью используют 154 из 317 участников, или 48,6%. Но заметного ускорения большинство пока не увидело: средняя оценка фактического эффекта составила 3,99 из 10.
При этом участники заметно выше оценили готовность применять ИИ для поиска ошибок, уязвимостей и других проблем в коде — в среднем на 5,46 балла из 10.
Почти у половины респондентов — 48,3% — готовность использовать ИИ оказалась выше уже полученного ускорения. У 35,6% обе оценки совпали, а у 16,1% фактический эффект был выше готовности. В среднем готовность опережала результат на 1,47 балла.
В комментариях ИИ чаще описывали как дополнительного проверяющего, а не замену человеку. От него ждут поиска багов, уязвимостей, граничных случаев, нарушений кодстайла и архитектурных правил. При этом без доступа к проектному контексту модель может выдавать лишние или ошибочные замечания, увеличивая нагрузку на ревьюера вместо экономии времени.
Вывод по гипотезе: ИИ уже применяют далеко за пределами генерации кода, но быстрее всего он приживается в задачах, где результат легко проверить одному специалисту. Ревью, архитектура и инфраструктурные процессы требуют общего контекста и формализованных правил, поэтому реальный эффект там пока отстаёт от ожиданий. Свободные ответы показывают важность актуальности документации: системное использование требует не просто доступа к модели, а управляемой базы знаний, актуальных правил и понятной ответственности.
Дмитрий Мацера
управляющий директор по ИТ Совкомбанк Технологии
То, что ИИ выходит за пределы генерации кода, — хороший сигнал. Но следующий шаг не в том, чтобы подключить одну и ту же модель ко всем этапам разработки. Следующий шаг — собрать специализированных помощников и агентов вокруг конкретных решений.
Например, один агент может подготовить изменения в документации по утверждённому шаблону, другой — проверить изменение на соответствие архитектурным правилам, третий — собрать результаты тестов и подготовить вывод для инженера. Ни один из них не должен самостоятельно выпускать код в продуктивную среду или менять настройки без заранее определённого уровня контроля.
В Совкомбанк Технологиях мы движемся именно в этой логике: не масштабируем отдельные чаты с моделью, а формируем управляемый контур для инженерных помощников и агентов. В нём важно не только качество ответа, но и состав доступных источников, минимальные права на действия, проверка результата человеком, журналирование и возможность быстро отключить сценарий при отклонении. Только так ИИ становится частью производственного процесса, а не набором личных экспериментов
В ревью и архитектуре главная проблема обычно не в модели, а в контексте. Если у системы нет актуальных решений, зависимостей, правил безопасности и прав доступа к ним, она будет выдавать убедительные, но плохо применимые рекомендации. Поэтому инвестиции нужны не только в вычисления, но и в управляемые знания, интеграции и оценку качества результата.
Гипотеза № 4. Чем выше инженерная зрелость, тем глубже внедрение и заметнее результат
Мы предположили, что результат от внедрения ИИ в разработку зависит не столько от доступа к конкретной модели или сервису, сколько от того, насколько хорошо в команде организованы инженерные процессы.
Для проверки взяли три оценки:
есть ли единые и понятные стандарты разработки;
описаны ли правила так, чтобы часть проверок можно было поручить ИИ;
хватает ли актуальной документации и проектного контекста.
Для каждого участника мы рассчитали среднее значение этих трёх ответов. Получившийся показатель использовали как условную оценку инженерной зрелости команды. Отдельного вопроса с таким названием в анкете не было — этот индекс был собран уже на этапе анализа.
Гипотеза подтвердилась. Результаты показали устойчивую связь: чем выше участники оценивали стандарты, документацию и контекст, тем глубже было внедрение ИИ и тем заметнее его применение в работе.
Все оценки в таблице приведены по шкале от 1 до 10. Видна почти ступенчатая картина: вместе с глубиной внедрения растут и качество инженерной среды, и фактическое использование ИИ, и полученный эффект.
Связь между сводной оценкой инженерной зрелости и другими показателями составила:
0,60 — с глубиной внедрения;
0,82 — с фактическим применением ИИ в инженерных процессах;
0,75 — с готовностью расширять его использование;
0,61 — с сокращением рутины без потери качества.
Чем ближе значение корреляции к 1, тем чаще два показателя растут вместе. Самая сильная связь обнаружилась между инженерной зрелостью и фактическим использованием ИИ. Причины могут быть такими: где‑то хорошие стандарты и документация упрощают внедрение ИИ, а где‑то переход к системному использованию заставляет команды лучше описывать правила и поддерживать контекст.
Наличие единых и понятных стандартов разработки в компании участники оценили в среднем только на 3,88 балла из 10.
Более половины респондентов дали стандартам низкую оценку, а 38,2% поставили минимальный балл.
Разница между уровнями внедрения заметна. Среди участников, для которых ИИ остаётся личным инструментом, стандарты на 6–10 баллов оценили только 15,9%. В группе со сквозным внедрением — уже 59,6%. При этом уверенные оценки от 8 до 10 поставили лишь 42,3% участников этой наиболее продвинутой группы.
То есть даже сквозное внедрение ИИ ещё не означает, что в команде полностью описаны и унифицированы инженерные правила. Это видно и по ответам о барьерах при внедрении ИИ в разработку: участники чаще указывали в качестве барьера не нехватку поддержки сверху, а проблемы внутри самого процесса разработки — безопасность, отсутствие стандартов, нехватку контекста и базы знаний.
Оставшиеся барьеры распределились так:
Среди пяти самых частых препятствий только качество ответов относится непосредственно к возможностям модели. Остальные связаны с безопасностью, правилами работы, документацией и доступом к контексту.
У тех, кто уже использует ИИ в разработке, картина почти не меняется: безопасность отметили 55,0%, отсутствие стандартов — 51,5%, качество ответов — 49,8%, нехватку контекста — 47,6%, отсутствие единой базы знаний — 41,5%.
При этом отсутствие поддержки руководства оказалось одним из самых редких ответов — его выбрали только 7,9% пользователей ИИ в разработке. Это ещё раз показывает, что главный барьер чаще находится не на уровне управленческого решения, а внутри инженерной среды.
Вывод по гипотезе: результаты опроса подтверждают связь между инженерной зрелостью и внедрением ИИ. Участники, которые выше оценивали стандарты, документацию и доступность контекста, чаще сообщали о глубоком внедрении, более широком применении ИИ и заметном сокращении рутины.
Дмитрий Мацера
управляющий директор по ИТ Совкомбанк Технологии
Исследование правильно показывает связь между инженерной зрелостью и эффектом от ИИ. Я бы только уточнил формулировку: зрелость нужна не модели — она нужна всей обвязке вокруг неё.
Агент не становится полезным от того, что ему дали большой контекст. Нужно определить, какие источники являются достоверными, кто отвечает за их актуальность, какие действия разрешены технической учётной записи, какие запрещены всегда и кто принимает спорное решение. Без этого мы получаем не интеллектуальную систему, а генератор текста с доступом к корпоративным данным. В Совкомбанк Технологиях мы смотрим на внедрение ИИ именно через эту призму: не как на отдельный инструмент, а как на часть управляемого инженерного процесса.
Модель действительно усиливает существующий процесс. Но агентный контур способен и закрепить порядок: если стандарты формализованы, проверки встроены в конвейер, а исключения попадают на рассмотрение человеку. Это и есть переход от эксперимента к управляемому производственному инструменту.
Гипотеза № 5. ИИ скорее убыстряет процесс разработки, чем пишет качественный код
Мы предполагали, что ИИ сначала поможет командам делать привычные задачи быстрее — например, писать код, тесты и документацию. Более сложные результаты, такие как снижение числа ошибок, улучшение качества и прозрачности процессов, должны появляться позже и требовать единых стандартов, актуальной документации и общего контекста. Результаты опроса подтвердили эту гипотезу частично: про скорость — да, а про качество кода — не всегда.
Результаты показали, что ИИ довольно быстро помогает ускорить работу. Такой эффект заметен даже там, где сотрудники используют его только как личный инструмент. А вот улучшение качества, снижение ошибок и повышение устойчивости процессов чаще встречаются при более глубоком командном внедрении.
К эффектам скорости мы отнесли сокращение рутины, сроков и затрат. К эффектам качества — улучшение кода, снижение числа ошибок и технического долга, уменьшение рисков выпуска и повышение прозрачности процессов.
Из таблицы видно, что ускорение отмечают почти девять из десяти участников независимо от глубины внедрения. С качественными результатами картина другая: при личном использовании о них сообщили 41,4%, а при сквозном внедрении — уже 66,7%.
Затем мы сравнили участников с разным состоянием инженерной среды. Для этого объединили оценки стандартов, документации и доступного проектного контекста.
Среди 80 участников с наиболее высокими оценками инженерной среды качественные эффекты отметили 65%. Среди 85 участников с самыми низкими оценками — только 36,5%. Иными словами, в первой группе вероятность сообщить об улучшении качества была заметно выше.
Та же картина видна и среди тех, кто уже использует ИИ непосредственно в разработке.
Чем выше участники оценивали понятность и единообразие стандартов, тем выше они оценивали и пользу ИИ. В группе со слабо описанными правилами сильный эффект отметили 21,8% пользователей. Среди участников, поставивших стандартам от 8 до 10 баллов, таких было уже 83,3%.
Вывод по гипотезе: получить локальное ускорение можно даже при личном использовании ИИ. Но улучшение качества, снижение ошибок и более устойчивый результат заметно чаще встречаются там, где ИИ встроен в командные процессы, а стандарты, документация и контекст уже подготовлены для его работы.
Дмитрий Мацера
управляющий директор по ИТ Совкомбанк Технологии
Локальное ускорение обычно даёт сама модель: быстрее написать черновик кода, теста или документа. Но качество, устойчивость и экономический эффект возникают только тогда, когда вокруг неё появляется большая инженерная обвязка. Нужны поиск по актуальным знаниям, интеграции с репозиторием и системой задач, автоматические проверки, ограниченные права на действия, контроль человека, трассировка и регулярная оценка ошибок. Это не «накладные расходы на ИИ», а основная часть промышленного решения.
В Совкомбанк Технологиях для нас важен именно реальный эффект от использования ИИ, а не сам факт его применения. Поэтому я бы не сравнивал команды по числу запросов к модели. Правильный вопрос другой: сколько времени проходит от задачи до проверяемого изменения, сколько дефектов выявляется до выпуска, сколько действий агент выполнил с первого раза и где человеку пришлось его остановить. Эти показатели отделяют демонстрацию возможностей модели от реального эффекта в разработке.
Что в итоге показало исследование
ИИ уже перестал быть только генератором кода. Разработку выбрали 72,2% участников, документацию и базу знаний — 51,7%, ревью — 48,6%, тестирование — 44,2%.
При этом сквозное внедрение от идеи до выпуска указали лишь 16,4%. Ещё 39,7% описали ИИ как личный инструмент отдельных сотрудников.
Размер компании сам по себе не давал преимущества во внедрении ИИ. Среди участников из организаций численностью до 500 человек о сквозном внедрении ИИ сообщили 22,2%, а среди респондентов из компаний с 500 сотрудниками и более — 9%. Это не доказывает, что небольшой размер автоматически ускоряет внедрение, но показывает: крупная компания ещё не означает более зрелого использования ИИ. В больших организациях интеграцию могут замедлять сложная инфраструктура, требования безопасности, устаревшие системы и длительные согласования.
Роль участника тоже влияла слабее, чем мы ожидали. Разработчики, тимлиды и руководители в целом называли похожие эффекты и препятствия. Принадлежность к конкретной должности оказалась менее важной, чем состояние процессов, в которых используется ИИ.
Самая устойчивая связь сквозного внедрения ИИ в процессы обнаружилась со стандартами, документацией и доступностью проектного контекста. Чем выше участники оценивали инженерную среду, тем глубже было внедрение, шире набор сценариев и заметнее эффект без ухудшения качества.
ИИ входит в разработку снизу: сначала как личный помощник для поиска, написания кода, тестирования и подготовки документов. Этот этап уже прошла значительная часть участников.
Следующий переход сложнее. Для него недостаточно выдать доступ к модели или встроить помощника в редактор. Нужны единые стандарты, актуальный контекст, база знаний, интеграция с процессами и понятные границы ответственности.
Поэтому главный разрыв проходит не между организациями с ИИ и без ИИ. Наиболее заметные различия находятся между теми, где модель ускоряет отдельного специалиста, и теми, кто смог превратить её в управляемую часть инженерного процесса.