Что нужно знать перед внедрением ИИ в процессы разработки
Для кого этот курс, что в него входит, чего ИИ не сделает и почему единственно правильного способа внедрения пока не существует.
Как устроен курс
Привет! Прежде чем начнём, расскажу в двух словах, как устроен курс.
В курсе 15 блоков. Они идут по порядку: следующий открывается, когда пройден предыдущий.
Большинство блоков устроены как симулятор. Сначала вы получаете ситуацию и выбираете один из трёх вариантов, потом видите, что случилось через квартал, а затем читаете разбор с цифрами и ссылками на исследования. Правильный ответ на развилке я заранее не подсказываю.
Курс вместе с вами проходят двое технических директоров. Даниил ведёт разработку в банке, а Мария второй год внедряет ИИ в продуктовой компании. В каждом блоке они комментируют ваш выбор, но не всегда соглашаются друг с другом.
В блоках с 02 по 07 и с 11 по 14 есть промпт для документа. Вы копируете его в модель, которую разрешила ваша служба ИБ, модель задаёт вопросы и собирает рабочий документ: причины внедрения, модель окупаемости, политику для ИБ, дизайн пилота. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем.
Хотите проходить курс по расписанию? Я составлю график под ваше время и перенесу его в AISuppy – это мой ассистент в Телеграме. Там будут задачи по блокам и напоминания. Курс работает и без этого.
Прогресс и ответы хранятся только в вашем браузере, регистрации нет. Внизу экрана всегда есть кнопки «Назад» и «Далее». Начнём со знакомства.
Что нужно знать
Для кого этот курс, что в него входит, чего ИИ не сделает и почему единственно правильного способа внедрения пока не существует.
Привет! Меня зовут Юрий Кононов, я CTO. В IT уже больше 15 лет: начинал бэкенд-инженером, потом – финтех и электронная коммерция, а затем – крупные организации разработки. В пике у меня было 20 команд и около 200 инженеров. Последние годы отвечаю за поставки в крупном банке: миллионы клиентов, монолит с историей, регуляторика, безопасность.
Компании, для которых я развивал продукты – в штате или как подрядчик: Sber, VTB, Rosbank, Stockmann, Decathlon, Shell, Volvo, Kari, Haier, 4lapy и многие другие.
Курс я написал, чтобы структурировать всё, что знаю о внедрении ИИ в разработку, и поделиться с коллегами опытом – и удачным, и не очень. Ответов на все вопросы у меня нет, так что относитесь к тексту как к ориентиру, а не как к инструкции.
Если по ходу возникнут вопросы, замечания или захочется поделиться своим опытом – пишите. Телеграм: @ykononov. LinkedIn: linkedin.com/in/ykononov. Ещё у меня есть канал в Телеграме про ИИ в разработке, стоимость и процессы: @ykononovmd.
Курс для CTO, руководителей разработки, директоров по разработке и лидов – проще говоря, для тех, кто отвечает за процессы и команды. Поможет обосновать внедрение перед гендиром и финансовым директором, провести его, а потом доказать, что всё прошло успешно.
Курс не учит писать промпты и не объясняет, как собрать RAG (retrieval-augmented generation – генерация ответа с подтягиванием документов из базы знаний). Материалов на эту тему уже хватает. А вот материалов на вопрос «что делать с людьми, деньгами и рисками?» почти нет – и именно его я пытаюсь закрыть.
А вы? Расскажите в двух словах, кем работаете и чем занимаетесь.
- Обосновать внедрение перед гендиром и финдиром с цифрами в руках
- Посчитать, во что обойдётся внедрение, и заложить контроль над бюджетом
- Договориться со службой информационной безопасности заранее, ещё до старта
- Выбрать пилотную группу и собрать исходные метрики, чтобы через квартал показать эффект
- Понять, что делать с людьми: с сопротивлением, с джунами, с оценкой инженеров
- Не повторить ошибки, которые я и другие уже совершили
- Видеть общую картину по внедрению ИИ в процессы компании
Что из этого вам нужнее всего прямо сейчас?
Курс покрывает только генерацию кода и агентную разработку внутри команд – то есть то, как инженеры, тестировщики и аналитики используют ИИ в своей повседневной работе.
Разработка ИИ-продуктов – это другой курс: чат-боты для клиентов, агенты внутри продукта, стоимость инференса на пользователя. Аудитория та же, но задачи другие, а если смешать – потеряется фокус. ИИ-агенты в продукте появляются в блоке 02, но только как одна из причин: команда, которая сама работает с агентами в разработке, быстрее учится их делать для пользователей.
Перед стартом полезно принять 4 вещи.
ИИ не чинит команду. Главный вывод отчёта DORA 2025 (DevOps Research and Assessment – многолетняя исследовательская программа Google о поставке софта, опрос почти 5 000 специалистов): ИИ работает как катализатор, а не как готовое решение. Сильные команды с хорошими основами он ускоряет, а команды с техническим долгом, хаосом в процессах и культурными проблемами – он эти проблемы усиливает. Там же: измеримой связи ИИ с помехами в процессах и выгоранием нет – они зависят от того, как устроена работа в команде.
ИИ ускоряет один этап, и очередь переезжает на следующий. Инженеры пишут код быстрее → кода становится больше → не успевают те, кто его проверяет. Данные Faros AI (компания продаёт аналитику процессов разработки, то есть заинтересована в теме) по более чем 10 000 разработчиков: у команд, активно работавших с ИИ, закрытых задач стало на 21% больше, принятых пул-реквестов – на 98% больше. Но ревью длится на 91% дольше, средний пул-реквест вырос на 154%, а багов на разработчика стало на 9% больше. Вывод простой: быстро писать код недостаточно – нужно так же быстро его проверять.
Эффект от ИИ нельзя измерять ощущениями. Подробно – в блоке 11, а коротко: в рандомизированном эксперименте METR (некоммерческая организация, оценивающая возможности ИИ) опытные разработчики с ИИ работали на 19% медленнее, но сами были уверены, что ускорились на 20%. Ощущениям верить нельзя – нужны метрики до и после.
Внедрение ИИ не улучшает существующие процессы. Меняется сама модель разработки: роли, скорость, бюджет. Просто вставить ИИ в текущие цепочки мало – нужно менять процесс. Какой смысл быстро генерировать код, если потом он 2 месяца согласовывается со службой ИБ по старому процессу?
Курс предполагает, что вы уже умеете несколько вещей.
- Управлять организацией разработки – знаете, как устроены команды, процесс поставки, ревью, релизы. Курс не учит менеджменту.
- Читать метрики поставки – если «частота деплоев» и «доля сбойных изменений» для вас новые слова, начните с официального описания метрик DORA.
- Распоряжаться бюджетом и людьми – или иметь доступ к тем, кто распоряжается. Внедрение требует денег и кадровых решений, одной технической настройки мало.
- Ориентироваться в ИИ-инструментах – и уметь применять их в своих задачах. Если ни разу не пользовались Claude, ChatGPT и тому подобным, начните с этого. Ещё есть мой бесплатный курс «AI-PDLC» на 52 минуты – он даёт общую картину того, как меняется процесс создания продукта с ИИ, без установки инструментов и разбора промптов. Он не обязателен. Если пройдёте его до этого курса, здесь будет меньше нового и больше глубины.
Писать код не обязательно, но очень желательно поработать руками – пройти каждый шаг в роли члена команды. Если есть инженер, которому доверяете, можно делегировать.
А вы сами пользуетесь ИИ-ассистентами?
Я не знаю единого правильного способа внедрения и использования ИИ. Но судя по данным, его пока не знает никто.
В 2024 году DORA обнаружила: чем больше команды пользовались ИИ, тем хуже были 2 метрики – поставка на 1,5% медленнее, стабильность на 7,2% ниже. Через год, в отчёте 2025, картина со скоростью поменялась: команды с ИИ стали поставлять код быстрее. Стабильность по-прежнему ниже. То есть за год главный вывод отраслевого отчёта сменился на противоположный: в 2024 – «ИИ замедляет поставку», в 2025 – «ИИ ускоряет поставку, но она менее стабильна». Почему так, отчёт не объясняет. Моя гипотеза: изменились и инструменты, и то, как команды научились ими пользоваться.
METR в феврале 2026 года объявила, что перестраивает дизайн исследования: разработчики не хотят работать без ИИ и отказываются участвовать, из-за чего данные стали ненадёжными. Организация считает, что сейчас разработчики ускоряются сильнее, чем в начале 2025 года, но не может измерить, насколько: по сырым данным второго исследования (57 разработчиков, из них 10 прежних, 800+ задач) с ИИ задачи занимают на 4–18% меньше времени, но доверительные интервалы включают ноль. Подробнее в блоке 11.
Что это значит на практике: любой, кто продаёт вам «проверенную методологию», продаёт снимок годичной давности. Нормальная стратегия – измерять у себя, менять понемногу, не верить ни одному числу из чужой презентации (включая числа из этого курса), пока не проверите его на своих командах.
Сфера молодая, реальных кейсов и методологий, которые на 100% закрывают все потребности, на рынке ещё мало.
Под enterprise я имею в виду крупные корпорации со сложной структурой, требованиями регуляторов и большим объёмом старого кода. Инструменты – те же, что у небольшой компании. Другие – препятствия.
В небольшой компании внедрение ограничивают в первую очередь деньги и время. Команда из 5 человек видит всю работу целиком, решение принимается за неделю, а если оказалось ошибочным – издержки невелики.
В корпорации тормозят другие вещи. Служба ИБ должна согласовать каждый инструмент. Регуляторы предъявляют требования к обработке данных. У части систем нет выхода в интернет. Релизы выходят по расписанию, любое изменение процесса проходит несколько уровней согласования. Решение может занять квартал и больше. При этом цена ошибки выше: неудачный инструмент или процесс попадает сразу во все команды – и исправлять придётся везде.
Курс написан на основе опыта работы в корпорации, так что по умолчанию речь именно о ней. Там, где подход для другого масштаба отличается, стоят 2 пометки:
от нескольких сотен до нескольких тысяч инженеров, есть служба ИБ, регулятор, закупки и годовой бюджет. В курсе её представляет Даниил (банк, 200 инженеров в 20 командах).
до пары сотен инженеров, ИБ как отдельной службы нет, процессы быстрее и проще. В курсе её представляет Мария (продуктовая компания, 60 инженеров).
Если вы между ними (100–300 инженеров, ИБ из 1–2 человек): по данным, ИБ и регулятору читайте пометку «корпорация», если у вас есть персональные данные клиентов, лицензия регулятора или КИИ (критическая информационная инфраструктура). По скорости решений, составу пилота и baseline читайте «небольшая компания». Если сомневаетесь, в вопросах данных берите более строгую пометку.
Если пометки нет – совет одинаков для всех.
Сколько инженеров в вашей организации?
Блоки идут от решения к практике, но проходить их можно по-разному.
Где проходить курс:
- на сайте: ykononov.ru/ai-cto;
- в Телеграм-боте: @ai_cto_course_bot;
- в репозитории на GitHub: github.com/yknnv/ai-cto-ru.
Если вы только начинаете: 01 → 02 (зачем) → 11 (что мерить) → 05 (ИБ) → 04 (деньги) → 03 (подходы) → 13 (люди) → 14 (первые 90 дней). Блоки 06–10 – справочные, по направлениям: возвращайтесь к ним, когда выбираете задачи первой волны. Блок 12 читайте перед второй волной.
Если у вас уже есть пилот: начните с 11 и 12, затем 14 и 15.
- Baseline – значения метрик до изменений. С ними сравнивают результат (блок 11).
- DORA – исследовательская программа Google о поставке софта и её 5 метрик: частота деплоев, время от коммита до прода, время восстановления, доля сбойных изменений, доля внеплановых выкаток (блок 11).
- TTM (time to market) – время от идеи до момента, когда она доступна клиентам.
- Единица поставки – то, что считаем результатом работы команды. В курсе это деплой.
- p95 (95-й перцентиль) – значение, которое не превышают 95% замеров. Например, p95 задержки 180 мс: 95 запросов из 100 быстрее 180 мс (блок 10).
- Стоимость единицы поставки – все расходы на разработку, включая ИИ, делённые на число единиц за период (блок 04).
- CI/CD (continuous integration / continuous delivery) – непрерывная интеграция и поставка: автоматическая сборка, проверки и выкатка каждого изменения (блок 09).
- Токен – минимальная единица текста, за которую платят поставщику модели (блок 04).
- Контекстное окно – сколько текста модель видит за 1 раз.
- Кэширование промптов – повторное использование неизменной части запроса со скидкой (блок 04).
- Роутинг моделей – выбор модели под сложность задачи: простое – на дешёвую, сложное – на сильную (блок 04).
- Предохранитель (circuit breaker) – автоматический стоп, когда расход превысил лимит на сессию, инженера или команду (блок 04).
- LLM – большая языковая модель, на которой работает ассистент.
- Агент – модель, которая сама выполняет шаги: читает файлы, пишет код, запускает тесты (блок 03).
- Модель в контуре – открытая модель на ваших серверах: код не уходит за периметр компании (блоки 03 и 05).
- Шлюз – корпоративный прокси, через который идут все запросы к моделям. В нём журнал запросов, лимиты и правила роутинга (блоки 04 и 05).
- Ступени автономии – 5 уровней от автодополнения до автономного агента (блок 03).
- Файл контекста – файл в репозитории с правилами и договорённостями, который агент читает перед работой (блок 15).
- Набор эталонных задач (golden set) – задачи из вашего кода с известным правильным результатом. На них проверяют, не стало ли хуже после смены модели (блок 03).
- Разработка от спецификации (SDD, spec-driven development) – сначала пишется и утверждается описание изменения, потом из него генерируется код (блок 03).
- MoE (mixture of experts) – модель, у которой на каждый токен работает только часть параметров (блок 03).
- Prompt injection – атака через данные, которые читает модель: в них прячут инструкции (блок 12).
- MCP (Model Context Protocol) – открытый стандарт подключения инструментов и данных к модели.
- Evals – автоматические проверки качества ответов модели или агента.
- PDLC – жизненный цикл разработки продукта, от исследования до эксплуатации (блок 03).
- Первая волна – первые направления задач, с которых команды начинают работать с ИИ: сначала надёжное, потом рискованное (блок 07).
- Пилот – первая команда, которая работает с ИИ по правилам и с замером (блоки 13–14).
- Вторая волна – 3–5 обычных команд после пилота и до раскатки на всех (блок 12).
- Платформенная команда – люди, которые владеют инструментами, файлами контекста и обучением после пилота (блок 14).
Дальше блок 02 «Для чего внедрять ИИ»: Скорее всего, решение вы уже приняли – или вас к нему подталкивают: руководство, конкуренты, собственные инженеры.