🔥 С 8 до 188 PR в месяц в финтех-проекте

23 сентября 2026 · 6 минут чтения

До внедрения — около 8 открытых PR в месяц. После начала работы с ИИ-агентами пик достиг 188 в июне 2026 года по всему проекту. С октября 2025 года открыто 1 077 PR, принято 911; статья показывает помесячный ряд и границы вывода.

До внедрения, с января по сентябрь 2025 года, в репозитории продукта было открыто 68 pull request'ов — в среднем около 8 в месяц. Так называют заявку на изменение кода, которую проверяют и принимают в проект; дальше я пишу просто PR. Пик после начала работы через ИИ-агентов пришёлся на июнь 2026 года: 188 PR за месяц по всему проекту, а не на одного разработчика. Из них 27 открыл второй разработчик. С октября 2025 по сентябрь 2026 года открыто 1 077 PR за 12 календарных месяцев, принято 911. Сентябрь неполный: данные выгружены 23 сентября. Ниже весь ряд по месяцам и рядом с ним второй ряд: 212 зарегистрированных разборов инцидентов из реестра, который появился в ноябре 2025 года.

Как устроена работа с агентами в этот период, я здесь не рассказываю: об этом будет отдельная статья. Здесь только измерение.

Откуда цифры

Два источника. Первый — репозиторий продукта на GitHub: все pull request'ы с момента его создания в 2018 году, 2 095 штук, с датами открытия и слияния. Я выгрузил их через API целиком, без выборки и ручной фильтрации. PR от ботов, программ, которые сами предлагают обновления библиотек, включены: с ноября 2025 по сентябрь 2026 года их 34 из 1 048, около 3%.

Второй — реестр инцидентов в Google Sheets: 212 записей PIR с номером, датой, продуктом, статусом и датами восстановления, разбора и закрытия. PIR здесь — паспорт разбора инцидента: что случилось, почему, как восстановили и какие задачи поставили, чтобы не повторилось. Считаю записи по дате регистрации: колонка «когда разобран» заполнена только у трети строк.

Pull request'ы: до и после

Девять месяцев до внедрения — это 68 PR, в среднем около 8 в месяц. Из них 58 открыл один разработчик. В октябре я вошёл в проект и начал работать через агентов: за месяц открыто 29 PR, из них 23 — мои.

Первый скачок пришёлся на октябрь 2025 года: с 5 PR в сентябре до 29 в октябре. Затем ноябрь — 15 PR, декабрь — 41. Дальше 53 в январе, 105 в феврале, 118 в марте, 167 в апреле, 128 в мае, 188 в июне. За первое полугодие 2026 года открыто 759 PR. С октября 2025 по сентябрь 2026 года — 1 077, в среднем около 90 в месяц против примерно 8 до внедрения. Октябрь–декабрь были переходными месяцами, а сентябрь учтён только по 23-е число.

Потом ряд падает: 112 в июле, 63 в августе, 58 в сентябре. Второй разработчик, который вошёл в проект в июне, работает по той же схеме: 27 PR в июне, 29 в июле, 53 в августе, 50 в сентябре. Мои PR с августа почти исчезают: 4 в августе и ни одного в сентябре.

Чего ряд PR не доказывает

Три оговорки, без которых эти цифры нельзя нести на слайд.

• Число PR ничего не говорит о пользе. Ряд показывает, сколько запросов на изменение кода открыли; принятые PR посчитаны отдельно в таблице. Сколько из них принесли деньги или сняли риск, эти данные не отвечают.
• Контрольной группы нет. Одновременно с агентами менялись инфраструктура, процессы и состав команды. Разделить вклады по этим данным нельзя, и я не пытаюсь.
• Единица работы стала мельче. Через агента задача дробится на небольшие проверяемые PR: так проще проверять и при ошибке отменять. Поэтому часть роста объясняется дроблением. Какая часть, я не измерял.

Инциденты: 212 PIR за одиннадцать месяцев

До ноября 2025 года реестра инцидентов не было. Сбои случались и их чинили, но без счётчика, разбора и задач по итогам. Поэтому графика «инцидентов стало меньше» здесь нет и быть не может: сравнивать не с чем.

Реестр появился в ноябре 2025 года, через месяц после начала работы с агентами: одна запись в ноябре, 16 в декабре, дальше 23, 26, 35 и пик 38 в апреле. Затем 27, 18, 11 в июле, 15 в августе. Из 212 записей закрыты 208: разобраны, задачи поставлены и выполнены.

У роста с декабря по апрель две причины, и разделить их по этим данным я не могу. Команда привыкала записывать каждый сбой, в том числе те, что раньше проходили незамеченными. А на март и апрель пришлись миграции, то есть перенос данных и инфраструктуры, и запуск новых окружений: это совпадает с разгоном PR. Снижение с мая — единственное место, где я вижу сигнал о надёжности, но и его нельзя отделить от дисциплины регистрации.

Два ряда вместе

Пик PR — апрель–июнь, пик PIR — март–апрель. Ряды совпадают по времени, но связывать их напрямую нельзя: реестр считает сбои по всем продуктам компании, а PR — по одному. Потом оба ряда садятся. В августе 63 PR и 15 PIR, в сентябре за 23 дня 58 PR и 2 PIR, и уже с другим разработчиком за рулём.

Таблицу можно прокрутить по горизонтали.

Методика

Чтобы получить исходный замер своей команды, используйте четыре промпта для техдиректора: коммиты, слитые PR и оценка часов по каждому разработчику. Для сравнения «до» и «после» сохраняйте одинаковые источники и правила подсчёта.

• PR относится к месяцу по дате открытия; в таблице отдельно показано, сколько PR принято в проект. Черновые PR включены: 15.
• В заголовке сопоставлены среднее до внедрения — 68 открытых PR за январь–сентябрь 2025 года, около 8 в месяц — и пик после начала работы с агентами: 188 открытых PR в июне 2026 года по всему проекту. Это разные виды показателя, а не среднее «до» и «после» на одного разработчика. С октября 2025 по сентябрь 2026 года открыто 1 077 PR за 12 календарных месяцев; октябрь–декабрь были переходным периодом, сентябрь неполный. Отдельно в тексте показаны 759 PR за первое полугодие 2026 года.
• Реестр: лист «Журнал» в Google Sheets, 212 строк с префиксом PIR. Месяц записи — по дате регистрации, она входит в номер записи.

Автор: Данил Письменный · Дата: 23 сентября 2026 · Обновлено: 7 октября 2026