# Блок 01. Что нужно знать перед внедрением ИИ в процессы разработки

- Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 1 из 15
- Автор: Юрий Кононов, CTO (https://ykononov.ru/)
- Страница: https://ykononov.ru/ai-cto/ii-v-razrabotke/
- Обновлено: 2026-10-12. Данные на 2026 год
- Время чтения: 15 мин
- Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено

Для кого этот курс, что в него входит, чего ИИ не сделает и почему единственно правильного способа внедрения пока не существует.

## От автора

Привет! Меня зовут Юрий Кононов, я CTO. В IT уже больше 15 лет: начинал бэкенд-инженером, потом – финтех и электронная коммерция, а затем – крупные организации разработки. В пике у меня было 20 команд и около 200 инженеров. Последние годы отвечаю за поставки в крупном банке: миллионы клиентов, монолит с историей, регуляторика, безопасность.  
Компании, для которых я развивал продукты – в штате или как подрядчик: Sber, VTB, Rosbank, Stockmann, Decathlon, Shell, Volvo, Kari, Haier, 4lapy и многие другие.

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

Если по ходу возникнут вопросы, замечания или захочется поделиться своим опытом – пишите. Телеграм: [@ykononov](https://t.me/ykononov). LinkedIn: [linkedin.com/in/ykononov](https://www.linkedin.com/in/ykononov/). Ещё у меня есть канал в Телеграме про ИИ в разработке, стоимость и процессы: [@ykononovmd](https://t.me/ykononovmd).

## Для кого этот курс

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

Курс не учит писать промпты и не объясняет, как собрать RAG (retrieval-augmented generation – генерация ответа с подтягиванием документов из базы знаний). Материалов на эту тему уже хватает. А вот материалов на вопрос «что делать с людьми, деньгами и рисками?» почти нет – и именно его я пытаюсь закрыть.

## Что вы сможете после курса

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

## Границы курса

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

Разработка ИИ-продуктов – это другой курс: чат-боты для клиентов, агенты внутри продукта, стоимость инференса на пользователя. Аудитория та же, но задачи другие, а если смешать – потеряется фокус. ИИ-агенты в продукте появляются в [блоке 02](/ai-cto/zachem-vnedryat-ii/), но только как одна из причин: команда, которая сама работает с агентами в разработке, быстрее учится их делать для пользователей.

## Какие задачи ИИ не решит

Перед стартом полезно принять 4 вещи.

**ИИ не чинит команду.** Главный вывод [отчёта DORA 2025](https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf) (DevOps Research and Assessment – многолетняя исследовательская программа Google о поставке софта, опрос почти 5 000 специалистов): ИИ работает как катализатор, а не как готовое решение. Сильные команды с хорошими основами он ускоряет, а команды с техническим долгом, хаосом в процессах и культурными проблемами – он эти проблемы усиливает. Там же: измеримой связи ИИ с помехами в процессах и выгоранием нет – они зависят от того, как устроена работа в команде.

**ИИ ускоряет один этап, и очередь переезжает на следующий.** Инженеры пишут код быстрее → кода становится больше → не успевают те, кто его проверяет. Данные [Faros AI](https://www.faros.ai/blog/ai-software-engineering) (компания продаёт аналитику процессов разработки, то есть заинтересована в теме) по более чем 10 000 разработчиков: у команд, активно работавших с ИИ, закрытых задач стало на 21% больше, принятых пул-реквестов – на 98% больше. Но ревью длится на 91% дольше, средний пул-реквест вырос на 154%, а багов на разработчика стало на 9% больше. Вывод простой: быстро писать код недостаточно – нужно так же быстро его проверять.

**Эффект от ИИ нельзя измерять ощущениями.** Подробно – в [блоке 11](/ai-cto/metriki-dora-baseline/), а коротко: в рандомизированном эксперименте [METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) (некоммерческая организация, оценивающая возможности ИИ) опытные разработчики с ИИ работали на 19% медленнее, но сами были уверены, что ускорились на 20%. Ощущениям верить нельзя – нужны метрики до и после.

**Внедрение ИИ не улучшает существующие процессы.** Меняется сама модель разработки: роли, скорость, бюджет. Просто вставить ИИ в текущие цепочки мало – нужно менять процесс. Какой смысл быстро генерировать код, если потом он 2 месяца согласовывается со службой ИБ по старому процессу?

## Какие знания у вас должны быть

Курс предполагает, что вы уже умеете несколько вещей.

1. **Управлять организацией разработки** – знаете, как устроены команды, процесс поставки, ревью, релизы. Курс не учит менеджменту.
2. **Читать метрики поставки** – если «частота деплоев» и «доля сбойных изменений» для вас новые слова, начните с [официального описания метрик DORA](https://dora.dev/guides/dora-metrics/).
3. **Распоряжаться бюджетом и людьми** – или иметь доступ к тем, кто распоряжается. Внедрение требует денег и кадровых решений, одной технической настройки мало.
4. **Ориентироваться в ИИ-инструментах** – и уметь применять их в своих задачах. Если ни разу не пользовались Claude, ChatGPT и тому подобным, начните с этого. Ещё есть мой бесплатный курс [«AI-PDLC»](https://ykononov.ru/aipdlc/) на 52 минуты – он даёт общую картину того, как меняется процесс создания продукта с ИИ, без установки инструментов и разбора промптов. Он не обязателен. Если пройдёте его до этого курса, здесь будет меньше нового и больше глубины.

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

## Почему единого правильного способа пока нет – и почему это нормально

Я не знаю единого правильного способа внедрения и использования ИИ. Но судя по данным, его пока не знает никто.

В 2024 году [DORA](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report) обнаружила: чем больше команды пользовались ИИ, тем хуже были 2 метрики – поставка на 1,5% медленнее, стабильность на 7,2% ниже. Через год, в отчёте 2025, картина со скоростью поменялась: команды с ИИ стали поставлять код быстрее. Стабильность по-прежнему ниже. То есть за год главный вывод отраслевого отчёта сменился на противоположный: в 2024 – «ИИ замедляет поставку», в 2025 – «ИИ ускоряет поставку, но она менее стабильна». Почему так, отчёт не объясняет. Моя гипотеза: изменились и инструменты, и то, как команды научились ими пользоваться.

[METR в феврале 2026 года](https://metr.org/blog/2026-02-24-uplift-update/) объявила, что перестраивает дизайн исследования: разработчики не хотят работать без ИИ и отказываются участвовать, из-за чего данные стали ненадёжными. Организация считает, что сейчас разработчики ускоряются сильнее, чем в начале 2025 года, но не может измерить, насколько: по сырым данным второго исследования (57 разработчиков, из них 10 прежних, 800+ задач) с ИИ задачи занимают на 4–18% меньше времени, но доверительные интервалы включают ноль. Подробнее в [блоке 11](/ai-cto/metriki-dora-baseline/).

Что это значит на практике: любой, кто продаёт вам «проверенную методологию», продаёт снимок годичной давности. Нормальная стратегия – измерять у себя, менять понемногу, не верить ни одному числу из чужой презентации (включая числа из этого курса), пока не проверите его на своих командах.

Сфера молодая, реальных кейсов и методологий, которые на 100% закрывают все потребности, на рынке ещё мало.

## Отличия внедрения в корпорации и небольшой компании

Под enterprise я имею в виду крупные корпорации со сложной структурой, требованиями регуляторов и большим объёмом старого кода. Инструменты – те же, что у небольшой компании. Другие – препятствия.

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

В корпорации тормозят другие вещи. Служба ИБ должна согласовать каждый инструмент. Регуляторы предъявляют требования к обработке данных. У части систем нет выхода в интернет. Релизы выходят по расписанию, любое изменение процесса проходит несколько уровней согласования. Решение может занять квартал и больше. При этом цена ошибки выше: неудачный инструмент или процесс попадает сразу во все команды – и исправлять придётся везде.

Курс написан на основе опыта работы в корпорации, так что по умолчанию речь именно о ней. Там, где подход для другого масштаба отличается, стоят 2 пометки:

**Корпорация:** от нескольких сотен до нескольких тысяч инженеров, есть служба ИБ, регулятор, закупки и годовой бюджет. В курсе её представляет Даниил (банк, 200 инженеров в 20 командах).

**Небольшая компания:** до пары сотен инженеров, ИБ как отдельной службы нет, процессы быстрее и проще. В курсе её представляет Мария (продуктовая компания, 60 инженеров).

**Если вы между ними** (100–300 инженеров, ИБ из 1–2 человек): по данным, ИБ и регулятору читайте пометку «корпорация», если у вас есть персональные данные клиентов, лицензия регулятора или КИИ (критическая информационная инфраструктура). По скорости решений, составу пилота и baseline читайте «небольшая компания». Если сомневаетесь, в вопросах данных берите более строгую пометку.

Если пометки нет – совет одинаков для всех.

## Как читать курс

Блоки идут от решения к практике, но проходить их можно по-разному.

**Где проходить курс:**

- на сайте: [ykononov.ru/ai-cto](https://ykononov.ru/ai-cto/);
- в Телеграм-боте: [@ai_cto_course_bot](https://t.me/ai_cto_course_bot);
- в репозитории на GitHub: [github.com/yknnv/ai-cto-ru](https://github.com/yknnv/ai-cto-ru).

**Если вы только начинаете:** 01 → 02 (зачем) → 11 (что мерить) → 05 (ИБ) → 04 (деньги) → 03 (подходы) → 13 (люди) → 14 (первые 90 дней). [Блоки 06](/ai-cto/spec-driven-development/)–[10](/ai-cto/soprovozhdenie-monitoring/) – справочные, по направлениям: возвращайтесь к ним, когда выбираете задачи первой волны. [Блок 12](/ai-cto/slozhnosti-vnedreniya-ii/) читайте перед второй волной.

**Если у вас уже есть пилот:** начните с 11 и 12, затем 14 и 15.

В [блоках 02](/ai-cto/zachem-vnedryat-ii/)–[05](/ai-cto/bezopasnost-politika-ii/) и 11–14 есть развилка из 3 вариантов. У каждого варианта есть плюс и цена, а верный часто медленнее других на старте. В [блоке 03](/ai-cto/ii-agenty-i-podhody/) ответ зависит от типа компании. Читайте исходы всех вариантов, в них главное. [Блоки 06](/ai-cto/spec-driven-development/)–[10](/ai-cto/soprovozhdenie-monitoring/) без развилок.

В [блоках 02](/ai-cto/zachem-vnedryat-ii/)–[07](/ai-cto/ii-v-programmirovanii/) и 11–14 есть промпт: модель задаст вопросы и соберёт документ. Используйте модель, которую разрешила ваша служба ИБ, и не вставляйте в ответы секреты, персональные данные и код из закрытых систем.

## Словарь

- **Baseline** – значения метрик до изменений. С ними сравнивают результат ([блок 11](/ai-cto/metriki-dora-baseline/)).
- **DORA** – исследовательская программа Google о поставке софта и её 5 метрик: частота деплоев, время от коммита до прода, время восстановления, доля сбойных изменений, доля внеплановых выкаток ([блок 11](/ai-cto/metriki-dora-baseline/)).
- **TTM** (time to market) – время от идеи до момента, когда она доступна клиентам.
- **Единица поставки** – то, что считаем результатом работы команды. В курсе это деплой.
- **p95** (95-й перцентиль) – значение, которое не превышают 95% замеров. Например, p95 задержки 180 мс: 95 запросов из 100 быстрее 180 мс ([блок 10](/ai-cto/soprovozhdenie-monitoring/)).
- **Стоимость единицы поставки** – все расходы на разработку, включая ИИ, делённые на число единиц за период ([блок 04](/ai-cto/stoimost-tokenov-okupaemost/)).
- **CI/CD** (continuous integration / continuous delivery) – непрерывная интеграция и поставка: автоматическая сборка, проверки и выкатка каждого изменения ([блок 09](/ai-cto/ii-v-ci-cd/)).
- **Токен** – минимальная единица текста, за которую платят поставщику модели ([блок 04](/ai-cto/stoimost-tokenov-okupaemost/)).
- **Контекстное окно** – сколько текста модель видит за 1 раз.
- **Кэширование промптов** – повторное использование неизменной части запроса со скидкой ([блок 04](/ai-cto/stoimost-tokenov-okupaemost/)).
- **Роутинг моделей** – выбор модели под сложность задачи: простое – на дешёвую, сложное – на сильную ([блок 04](/ai-cto/stoimost-tokenov-okupaemost/)).
- **Предохранитель** (circuit breaker) – автоматический стоп, когда расход превысил лимит на сессию, инженера или команду ([блок 04](/ai-cto/stoimost-tokenov-okupaemost/)).
- **LLM** – большая языковая модель, на которой работает ассистент.
- **Агент** – модель, которая сама выполняет шаги: читает файлы, пишет код, запускает тесты ([блок 03](/ai-cto/ii-agenty-i-podhody/)).
- **Модель в контуре** – открытая модель на ваших серверах: код не уходит за периметр компании ([блоки 03](/ai-cto/ii-agenty-i-podhody/) и 05).
- **Шлюз** – корпоративный прокси, через который идут все запросы к моделям. В нём журнал запросов, лимиты и правила роутинга ([блоки 04](/ai-cto/stoimost-tokenov-okupaemost/) и 05).
- **Ступени автономии** – 5 уровней от автодополнения до автономного агента ([блок 03](/ai-cto/ii-agenty-i-podhody/)).
- **Файл контекста** – файл в репозитории с правилами и договорённостями, который агент читает перед работой ([блок 15](/ai-cto/shablony/)).
- **Набор эталонных задач** (golden set) – задачи из вашего кода с известным правильным результатом. На них проверяют, не стало ли хуже после смены модели ([блок 03](/ai-cto/ii-agenty-i-podhody/)).
- **Разработка от спецификации** (SDD, spec-driven development) – сначала пишется и утверждается описание изменения, потом из него генерируется код ([блок 03](/ai-cto/ii-agenty-i-podhody/)).
- **MoE** (mixture of experts) – модель, у которой на каждый токен работает только часть параметров ([блок 03](/ai-cto/ii-agenty-i-podhody/)).
- **Prompt injection** – атака через данные, которые читает модель: в них прячут инструкции ([блок 12](/ai-cto/slozhnosti-vnedreniya-ii/)).
- **MCP** (Model Context Protocol) – открытый стандарт подключения инструментов и данных к модели.
- **Evals** – автоматические проверки качества ответов модели или агента.
- **PDLC** – жизненный цикл разработки продукта, от исследования до эксплуатации ([блок 03](/ai-cto/ii-agenty-i-podhody/)).
- **Первая волна** – первые направления задач, с которых команды начинают работать с ИИ: сначала надёжное, потом рискованное ([блок 07](/ai-cto/ii-v-programmirovanii/)).
- **Пилот** – первая команда, которая работает с ИИ по правилам и с замером ([блоки 13](/ai-cto/komanda-roli-obuchenie/)–[14](/ai-cto/pilot-90-dney/)).
- **Вторая волна** – 3–5 обычных команд после пилота и до раскатки на всех ([блок 12](/ai-cto/slozhnosti-vnedreniya-ii/)).
- **Платформенная команда** – люди, которые владеют инструментами, файлами контекста и обучением после пилота ([блок 14](/ai-cto/pilot-90-dney/)).

## Источники

- [DORA 2025, анонс Google Cloud](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
- [DORA 2025, официальная страница отчёта](https://dora.dev/dora-report-2025/)
- [DORA 2024, анонс Google Cloud](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report)
- [Метрики DORA, официальное описание](https://dora.dev/guides/dora-metrics/)
- [METR, исследование 2025 года](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
- [METR, обновление за февраль 2026](https://metr.org/blog/2026-02-24-uplift-update/)
- [Faros AI, AI Productivity Paradox, июль 2025](https://www.faros.ai/blog/ai-software-engineering)