# Блок 07. Разработка - Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 7 из 15 - Автор: Юрий Кононов, CTO (https://ykononov.ru/) - Страница: https://ykononov.ru/ai-cto/ii-v-programmirovanii/ - Обновлено: 2026-10-12. Данные на 2026 год - Время чтения: 5 мин - Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено > Ускорить написание кода проще всего; гораздо труднее не превратить ревью в новую очередь, в которую упрётся весь выигрыш. Это первый из блоков про конкретные направления, поэтому здесь важно одно правило: задачи подходят для ИИ в разной степени. Для каждого направления я отмечаю, насколько отдача предсказуема и какие данные это подтверждают, чтобы вы начинали с надёжного и осторожно шли к рискованному. Вы выбираете, с чего команды начнут работать с ИИ. Дальше 5 направлений разработки и ревью, которое меняется вместе с ними. В промпте в конце блока направления выстроены от самого надёжного к самому рискованному: понимание кода, документация, unit-тесты, рефакторинг и миграции, генерация кода. Так первую волну можно собрать без угадывания. ## Генерация кода Это самое очевидное применение ИИ и самое неоднозначное по данным. В [эксперименте Peng и др. 2023 года](https://arxiv.org/abs/2302.06590v1) задача с нуля решалась на 55,8% быстрее. В [эксперименте METR 2025 года](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) опытные разработчики в знакомых зрелых репозиториях работали на 19% медленнее. Эти результаты не противоречат друг другу, потому что получены на разных задачах. Отдача высокая и предсказуемая там, где задача изолированная, типовая и с понятным критерием результата: новый сервис по образцу существующего, обработчик по шаблону, скрипт для разовой операции, прототип. Отдача низкая или отрицательная там, где нужно глубокое понимание неявных договорённостей проекта, например при правке в ядре старого монолита, где любое изменение задевает 10 других модулей. Практический совет: начинайте генерацию кода с задач первого типа, а для второго типа используйте ИИ только как помощника в понимании, роль автора ему там может не подойти. **Корпорация:** первая волна – понимание кода и документация: там нет риска для прода, зато есть быстрый эффект на старом монолите. Миграции добавляют позже, после согласования с ИБ. **Небольшая компания:** в коде больше нового и меньше легаси, поэтому генерацию по образцу и миграции можно запускать сразу. Ограничение то же: не отдавать агенту ядро, которое никто не покрыл тестами. ## Понимание кода Это самое недооценённое направление и, по моему опыту, самое безопасное для старта. Модель хорошо объясняет, что делает функция, находит, где обрабатывается такой-то случай, составляет схему зависимостей модуля, переводит логику с одного языка на другой для чтения. Цена ошибки здесь ниже, чем при генерации: человек читает объяснение и ничего не мержит. Но неверное объяснение легаси ведёт к неверному решению, поэтому объяснения, на которые опирается изменение, сверяйте с кодом или с человеком, который знает модуль. Для легаси это особенно ценно. Инженер, которому досталась система без документации и без её авторов, раньше тратил на археологию недели, а с ИИ тратит дни. ## Ревью ИИ в ревью полезен как первый фильтр: типовые ошибки, несоответствие стандартам, пропущенная обработка ошибок, подозрительные места. Человека он заменить не может, потому что не знает, зачем это изменение и уместно ли оно в контексте продукта. Но есть обратная сторона, которая важнее: ревью становится узким местом. По данным [Faros AI](https://www.faros.ai/blog/ai-software-engineering), с ИИ число пул-реквестов выросло на 98%, их размер вырос на 154%, а время ревью увеличилось на 91%. Кода становится больше, пул-реквесты крупнее, поэтому проверять их дольше. Если вы ускорили генерацию и не изменили ревью, вы просто перенесли очередь. Варианты такие: требовать мелкие пул-реквесты, автоматизировать первый проход, выделять время на ревью явно вместо остаточного принципа. Подробнее об узком месте в ревью – в [блоке 12](/ai-cto/slozhnosti-vnedreniya-ii/). Ещё один способ разгрузить ревью – показывать ревьюеру не только дифф, но и последствия изменения: какие функции, сервисы и тесты оно затрагивает. Такой анализ строят по графу кода отдельные инструменты или платформы окружения ([блок 03](/ai-cto/ii-agenty-i-podhody/)). ## Рефакторинг и миграции Здесь лучшая отдача из всех направлений, и она показана на масштабе, хотя и заявлением самой компании: [Amazon](https://simonwillison.net/2024/Aug/24/andy-jassy-amazon-ceo/) обновил больше половины рабочих Java-систем с помощью ассистента, при этом 79% автоматических ревью кода выпустили без дополнительных правок. Причина проста: миграция версий, обновление зависимостей, переименование, замена устаревшего API относятся к задачам однотипным, объёмным, с автоматической проверкой результата (компилируется, тесты проходят). Именно такие задачи люди часто откладывают. Граница проходит так: ИИ хорошо делает механический рефакторинг и плохо делает смысловой. Разбить монолит на сервисы по бизнес-границам он не сможет, потому что границы определяются решением о бизнесе, код их не задаёт. ## Документация Здесь самый подтверждённый эффект: по [DORA 2024](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report) рост использования ИИ на 25% связан с ростом качества документации на 7,5%. Для масштаба: тот же рост даёт качеству кода +3,4%, скорости ревью +3,1%, а пропускной способности поставки −1,5% и стабильности −7,2%. То есть 7,5% – это не доля от 100%, а самый большой положительный эффект из всех, что нашёл отчёт. Документацию по коду, описание API, инструкции по развёртыванию, журналы изменений модель генерирует из кода быстро и в целом верно. Здесь действуют 2 правила. Первое: документация, сгенерированная из кода, описывает, что код делает, а вопрос «зачем» оставляет без ответа, его дописывает человек. Второе: сгенерированную документацию нужно встроить в процесс (обновляется при каждом изменении, проверяется в ревью), иначе она устареет через месяц, как и написанная вручную. ## Unit-тесты Unit-тесты (модульные тесты, проверяющие отдельную функцию или класс) подходят для ИИ хорошо: модель быстро покрывает функцию тестами на типовые и граничные случаи, которые человек ленится писать. Подвох в том, что модель пишет тесты под то, как код работает сейчас, хотя нужны тесты под то, как он должен работать. Если в коде ошибка, тест закрепит ошибку. Поэтому сгенерированные тесты нужно проверять на смысл, одного того, что они проходят, мало. За процентом покрытия гнаться тоже не стоит: 100 тестов, проверяющих очевидное, хуже 10, проверяющих важное. ## Источники - [Peng и др., 2023](https://arxiv.org/abs/2302.06590v1) - [METR, 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) - [Faros AI, AI Productivity Paradox, июль 2025](https://www.faros.ai/blog/ai-software-engineering) - [Amazon Q, пост Энди Джасси, 24 августа 2024, пересказ с цитатой](https://simonwillison.net/2024/Aug/24/andy-jassy-amazon-ceo/) - [DORA 2024](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report) ## Что говорят коллеги Даниил: Банк · 200 инженеров · первый год. Мария: Продуктовая компания · второй год. Даниил и Мария о том, какие задачи они отдали бы ИИ первыми. **Даниил:** Для меня главная фраза в блоке про ядро старого монолита, потому что это буквально наш код, а генерация там сейчас скорее навредит. Поэтому первая волна у меня состоит из понимания кода и документации: модель объясняет, человек читает, в прод ничего не уходит. К тому же только это ИБ согласует быстро. Миграции я хочу, но любое массовое изменение в банке идёт через долгое согласование, поэтому в первый год я туда не полезу. **Мария:** Мы как раз начали с понимания кода, а через квартал финансовый директор спросила, что мы ей покажем. Объяснения модулей хорошо работают, но их не посчитаешь. Цифры дали миграции: однотипная работа, автоматическая проверка, понятный результат. Ещё один урок второго года: про ревью надо думать до генерации. Мы сначала разогнали код, а потом месяц разбирали очередь пул-реквестов. - **Мария:** Даниил, начни с одной миграции. Здесь лучшая отдача из всех направлений, и её можно показать на комитете цифрами. - **Даниил:** Одна миграция в банке означает полгода согласований. Понимание кода я запущу завтра, оно никому не навредит. - **Мария:** Запускай, но через квартал тебя спросят про эффект, а фраза «инженеры стали лучше понимать код» ответом не будет. ## Промпт для документа: Список задач первой волны 3 задачи, с которых ваши команды начнут работать с ИИ: сначала надёжное, потом рискованное. Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем. ``` Ты – опытный технический директор. Помоги мне составить «Список задач первой волны» – 3 задачи, с которых команды начнут работать с ИИ. Направления от самого надёжного к самому рискованному: 1. Понимание кода 2. Документация 3. Unit-тесты 4. Рефакторинг и миграции 5. Генерация кода Ревью – не направление первой волны. Это процесс, который нужно поменять одновременно с любым из направлений. Что нужно выяснить: - Какие сервисы и модули есть у нас, где больше всего легаси и рутины. - Для 3 направлений – конкретная задача из бэклога: сервис, объём, что именно сделать. - Чем измерим каждую задачу и какое значение сейчас. - Что поменяем в ревью, чтобы оно не стало узким местом: лимит на размер пул-реквеста, предварительная проверка моделью, время на ревью в плане. Предлагай порядок от надёжного к рискованному. Если я выбираю рискованное направление первым, спроси, почему. Если ИИ у нас уже используется на части направлений, не строй первую волну заново. Спроси, какие направления уже идут и с каким результатом, и составь список следующих 3 задач: новые направления или новые команды, по-прежнему от надёжного к рискованному. Тогда назови документ «Список задач следующей волны». Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: таблица «№ | Направление | Конкретная задача | Чем измерим | Сейчас», под таблицей – что меняем в ревью и строка «Ограничения ИБ и регулятора»: какие данные и модули в волну не входят. ``` ### Пример: список первой волны у Даниила Так выглядит готовый документ для банка: от надёжного к рискованному, и для каждой задачи заранее понятно, чем её измерить. | № | Направление | Конкретная задача | Чем измерим | Сейчас | | --- | --- | --- | --- | --- | | 1 | Понимание кода | Описание модуля расчёта комиссий (fees/, 38 тыс. строк, авторы ушли): схема зависимостей, список точек входа, объяснение 5 самых запутанных классов | Время входа нового инженера в модуль до первого самостоятельного изменения | Около 3 недель | | 2 | Документация | Описание API и сценариев ошибок сервиса комиссий для смежных команд: 14 методов без актуального описания | Вопросов от смежных команд в чате сервиса в неделю; часов на описание 1 метода | Около 15 вопросов; около 4 часов вручную | | 3 | Unit-тесты | Покрытие тестами модуля валидации платёжных реквизитов с ревью каждого теста на смысл | Покрытие; число реальных ошибок, найденных новыми тестами | 23%; ожидаем 2–3 ошибки на модуль | Миграции у Даниила – не раньше второго года: массовые изменения в банке долго согласуют с ИБ. Что меняем в ревью, чтобы оно не стало узким местом: изменения в fees/ дробим по задачам, а не по спринтам (сейчас медиана пул-реквеста 650 строк), в каждом пул-реквесте отметка «сгенерировано с ИИ» и ссылка на спецификацию, второй ревьюер для платёжных модулей, 4 часа на ревью в спринте у каждого инженера заложены в план. Цель: время ревью не выше текущих 3,1 дня при росте числа пул-реквестов. Ограничения ИБ и регулятора: персональные данные клиентов в модель не отправляем; изменения в формулах расчёта комиссий и в том, что идёт в регуляторную отчётность, в волну не входят; инструмент – только согласованный с ИБ. ## Итог блока Главное из блока: начинайте с задач, где отдача предсказуема (понимание кода, документация, unit-тесты, затем миграции), а генерацию в ядре монолита оставьте на потом. Ревью меняйте одновременно с генерацией, иначе очередь просто переедет. Дальше, в [блоке 08](/ai-cto/ii-dlya-testirovaniya/), разбирается тестирование, где ИИ одновременно сильно помогает и сильно обманывает.