GitLab перевела rate limiting на ИИ-агентов: 14 спецификаций и 30+ merge request

Небольшая команда GitLab провела эксперимент и с помощью ИИ-агентов мигрировала часть легаси-системы ограничения запросов (rate limiting) на единую реализацию в библиотеке labkit-ruby, не снижая планку надёжности — итог эксперимента команда сама называет успешным.

Какой была система до миграции

В GitLab годами параллельно существовали два пути ограничения запросов: прикладной `Gitlab::ApplicationRateLimiter` со 121 ключом и отдельная система на уровне Rack. Цель миграции — объединить оба пути в единую реализацию в `labkit-ruby`, чтобы система была наблюдаемой, тестируемой и работала одинаково во всех частях продукта. Каждый запрос к монолиту GitLab проходит через эту систему, поэтому её сбои должны быть видимыми и обратимыми.

Кто и как работал над миграцией

Над проектом работали три инженера GitLab и набор ИИ-агентов.

• Макс Вулф (Max Woolf), Staff Backend Engineer в команде API Platform, отвечал за сторону монолита и проводил большинство релизов
• Боб Ван Ландёйт (Bob Van Landuyt) из команды Scalability отвечал за саму библиотеку и архитектуру решения
• Ещё несколько инженеров подключались точечно, чтобы вникнуть в контекст и помочь с кодом и ревью
• Использовались GitLab Duo Agent Platform и GitLab Duo Code Review

Агенты читали контекст, готовили черновики спецификаций, реализовывали ограниченные по объёму изменения, писали тесты и делали предварительный ревью merge request. Люди оставляли за собой scope, архитектуру, релизы и финальное решение.

Как был устроен рабочий цикл

Команда работала по строгому циклу: прочитать эпик, написать спецификацию, провести её adversarial-ревью, приступить к реализации только после снятия блокеров, проверить результат явными доказательствами, провести adversarial-ревью самого merge request, эскалировать на ревью человека и только потом мержить. Adversarial-ревью ограничили двумя раундами — после этого решение обязательно передавалось человеку.

• По проекту команда выпустила 14 пронумерованных спецификаций
• В библиотеку `labkit-ruby` ушло более 30 merge request
• На практике жёсткость цикла отличалась от инженера к инженеру: Боб Ван Ландёйт нередко проводил несколько раундов спецификации и ревью в одиночку, прежде чем показать общий артефакт команде

Что это значит

Эксперимент GitLab показывает: ИИ-агенты уже способны брать на себя рутинную часть миграции легаси-кода — черновики спецификаций, реализацию и тесты, — но именно жёсткий рабочий процесс, командная структура и обязательное человеческое ревью определяют, останется ли система такой же надёжной, как раньше. Авторы эксперимента прямо отмечают: агенты работают, но заодно обнажают слабые места в том, как команда обычно организует свою работу, — сам по себе цикл ревью и наблюдаемость оказались не менее важны, чем возможности агентов.

Частые вопросы

Сколько людей работало над миграцией rate limiting в GitLab?

Над проектом работали три инженера GitLab — Макс Вулф, Боб Ван Ландёйт и ещё несколько человек, подключавшихся точечно, — вместе с набором ИИ-агентов на базе GitLab Duo Agent Platform.

Сколько кода и спецификаций выпустила команда?

За время эксперимента команда подготовила 14 пронумерованных спецификаций и отправила более 30 merge request в библиотеку labkit-ruby.