Разработка с ИИ: с чего начать команде
Это первый из блоков про конкретные направления, поэтому здесь важно одно правило: задачи подходят для ИИ в разной степени. Для каждого направления я отмечаю, насколько отдача предсказуема и какие данные это подтверждают, чтобы вы начинали с надёжного и осторожно шли к рискованному.
Вы выбираете, с чего команды начнут работать с ИИ. Дальше 5 направлений разработки и ревью, которое меняется вместе с ними. В промпте в конце блока направления выстроены от самого надёжного к самому рискованному: понимание кода, документация, unit-тесты, рефакторинг и миграции, генерация кода. Так первую волну можно собрать без угадывания.
Разработка
Ярлык рядом с заголовком показывает, насколько вывод подтверждён данными:
- подтвержденоесть данные исследований
- с оговоркамиданные есть, но узкие или противоречивые
- на логикеданных нет, вывод сделан рассуждением
Это первый из блоков про конкретные направления, поэтому здесь важно одно правило: задачи подходят для ИИ в разной степени. Для каждого направления я отмечаю, насколько отдача предсказуема и какие данные это подтверждают, чтобы вы начинали с надёжного и осторожно шли к рискованному.
Это самое очевидное применение ИИ и самое неоднозначное по данным. В эксперименте Peng и др. 2023 года задача с нуля решалась на 55,8% быстрее. В эксперименте METR 2025 года опытные разработчики в знакомых зрелых репозиториях работали на 19% медленнее. Эти результаты не противоречат друг другу, потому что получены на разных задачах.
Отдача высокая и предсказуемая там, где задача изолированная, типовая и с понятным критерием результата: новый сервис по образцу существующего, обработчик по шаблону, скрипт для разовой операции, прототип. Отдача низкая или отрицательная там, где нужно глубокое понимание неявных договорённостей проекта, например при правке в ядре старого монолита, где любое изменение задевает 10 других модулей.
Практический совет: начинайте генерацию кода с задач первого типа, а для второго типа используйте ИИ только как помощника в понимании, роль автора ему там может не подойти.
первая волна – понимание кода и документация: там нет риска для прода, зато есть быстрый эффект на старом монолите. Миграции добавляют позже, после согласования с ИБ.
в коде больше нового и меньше легаси, поэтому генерацию по образцу и миграции можно запускать сразу. Ограничение то же: не отдавать агенту ядро, которое никто не покрыл тестами.
Это самое недооценённое направление и, по моему опыту, самое безопасное для старта. Модель хорошо объясняет, что делает функция, находит, где обрабатывается такой-то случай, составляет схему зависимостей модуля, переводит логику с одного языка на другой для чтения. Цена ошибки здесь ниже, чем при генерации: человек читает объяснение и ничего не мержит. Но неверное объяснение легаси ведёт к неверному решению, поэтому объяснения, на которые опирается изменение, сверяйте с кодом или с человеком, который знает модуль.
Для легаси это особенно ценно. Инженер, которому досталась система без документации и без её авторов, раньше тратил на археологию недели, а с ИИ тратит дни.
ИИ в ревью полезен как первый фильтр: типовые ошибки, несоответствие стандартам, пропущенная обработка ошибок, подозрительные места. Человека он заменить не может, потому что не знает, зачем это изменение и уместно ли оно в контексте продукта.
Но есть обратная сторона, которая важнее: ревью становится узким местом. По данным Faros AI, с ИИ число пул-реквестов выросло на 98%, их размер вырос на 154%, а время ревью увеличилось на 91%. Кода становится больше, пул-реквесты крупнее, поэтому проверять их дольше. Если вы ускорили генерацию и не изменили ревью, вы просто перенесли очередь. Варианты такие: требовать мелкие пул-реквесты, автоматизировать первый проход, выделять время на ревью явно вместо остаточного принципа. Подробнее об узком месте в ревью – в блоке 12.
Ещё один способ разгрузить ревью – показывать ревьюеру не только дифф, но и последствия изменения: какие функции, сервисы и тесты оно затрагивает. Такой анализ строят по графу кода отдельные инструменты или платформы окружения (блок 03).
Здесь лучшая отдача из всех направлений, и она показана на масштабе, хотя и заявлением самой компании: Amazon обновил больше половины рабочих Java-систем с помощью ассистента, при этом 79% автоматических ревью кода выпустили без дополнительных правок. Причина проста: миграция версий, обновление зависимостей, переименование, замена устаревшего API относятся к задачам однотипным, объёмным, с автоматической проверкой результата (компилируется, тесты проходят). Именно такие задачи люди часто откладывают.
Граница проходит так: ИИ хорошо делает механический рефакторинг и плохо делает смысловой. Разбить монолит на сервисы по бизнес-границам он не сможет, потому что границы определяются решением о бизнесе, код их не задаёт.
Здесь самый подтверждённый эффект: по DORA 2024 рост использования ИИ на 25% связан с ростом качества документации на 7,5%. Для масштаба: тот же рост даёт качеству кода +3,4%, скорости ревью +3,1%, а пропускной способности поставки −1,5% и стабильности −7,2%. То есть 7,5% – это не доля от 100%, а самый большой положительный эффект из всех, что нашёл отчёт. Документацию по коду, описание API, инструкции по развёртыванию, журналы изменений модель генерирует из кода быстро и в целом верно.
Здесь действуют 2 правила. Первое: документация, сгенерированная из кода, описывает, что код делает, а вопрос «зачем» оставляет без ответа, его дописывает человек. Второе: сгенерированную документацию нужно встроить в процесс (обновляется при каждом изменении, проверяется в ревью), иначе она устареет через месяц, как и написанная вручную.
Unit-тесты (модульные тесты, проверяющие отдельную функцию или класс) подходят для ИИ хорошо: модель быстро покрывает функцию тестами на типовые и граничные случаи, которые человек ленится писать.
Подвох в том, что модель пишет тесты под то, как код работает сейчас, хотя нужны тесты под то, как он должен работать. Если в коде ошибка, тест закрепит ошибку. Поэтому сгенерированные тесты нужно проверять на смысл, одного того, что они проходят, мало. За процентом покрытия гнаться тоже не стоит: 100 тестов, проверяющих очевидное, хуже 10, проверяющих важное.
Что говорят коллеги
Даниил и Мария о том, какие задачи они отдали бы ИИ первыми.
Для меня главная фраза в блоке про ядро старого монолита, потому что это буквально наш код, а генерация там сейчас скорее навредит. Поэтому первая волна у меня состоит из понимания кода и документации: модель объясняет, человек читает, в прод ничего не уходит. К тому же только это ИБ согласует быстро. Миграции я хочу, но любое массовое изменение в банке идёт через долгое согласование, поэтому в первый год я туда не полезу.
Мы как раз начали с понимания кода, а через квартал финансовый директор спросила, что мы ей покажем. Объяснения модулей хорошо работают, но их не посчитаешь. Цифры дали миграции: однотипная работа, автоматическая проверка, понятный результат. Ещё один урок второго года: про ревью надо думать до генерации. Мы сначала разогнали код, а потом месяц разбирали очередь пул-реквестов.
Обсуждение:
Список задач первой волны
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, разбирается тестирование, где ИИ одновременно сильно помогает и сильно обманывает.
Дальше блок 08 «Тестирование»: Тестирование относится к областям, где ИИ одновременно сильно помогает и сильно обманывает.