Как GitLab мигрировал систему ограничения запросов с помощью ИИ-агентов: опыт и уроки

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

Что произошло: миграция системы rate limiting с помощью ИИ

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

Почему этот эксперимент важен для разработчиков

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

Как именно ИИ-агенты помогали мигрировать код?

В команду входили три инженера: Макс Вульф (Staff Backend Engineer, отвечал за монолит и развертывания), Боб Ван Ландюйт (Scalability, архитектура библиотеки) и автор эксперимента (контролировал рамки и писал начальный код). Агенты выполняли следующие задачи: чтение контекста, написание спецификаций, реализация ограниченных изменений, создание тестов и предварительное ревью. Для контроля качества использовался GitLab Duo Code Review. Работа велась по строгому циклу: прочитать эпик, написать спецификацию, провести adversarial review спецификации, реализовать после снятия блокеров, проверить с явными доказательствами, adversarial review merge request, эскалация человеку, слияние. Adversarial review ограничивался двумя раундами, после чего требовалось вмешательство человека. Всего было создано 14 пронумерованных спецификаций и более 30 merge request'ов.

Какие результаты показал эксперимент?

Хотя точные метрики производительности агентов не раскрыты, эксперимент подтвердил, что ИИ-агенты способны эффективно справляться с задачами миграции при условии четкого процесса. Ключевым элементом стал цикл adversarial review, который позволил выявить ошибки на ранних этапах. Агенты успешно генерировали спецификации и код, но окончательное решение по сложным вопросам оставалось за людьми. GitLab отметил, что такой подход может быть масштабирован на другие системы, особенно если они имеют схожую структуру и четкие границы.

Кого затронет этот опыт?

Прежде всего, разработчиков, использующих GitLab, а также инженеров, интересующихся практическим применением ИИ-агентов для миграции кода. Команды, работающие с критичными системами, могут перенять описанный подход, чтобы ускорить рефакторинг и снизить нагрузку на людей. Однако важно понимать, что успех зависит от качества организации процесса и готовности команды к новому формату работы.

Что пока остается неизвестным?

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

Выводы и перспективы

Эксперимент GitLab показал, что ИИ-агенты могут быть полезным инструментом для миграции кода, но они не заменяют людей полностью. Четкий процесс, adversarial review и наблюдаемость — ключевые условия успеха. В будущем такие подходы могут стать стандартом для рефакторинга крупных систем, но пока требуют ручного контроля и тщательной настройки.