AI Can Ship Features Across Multiple Repos

Як змусити AI-агента працювати з кількома репозиторіями: стратегія та інструменти

У відео розглядається проблема, з якою стикаються команди, що використовують AI-агентів для роботи з кодовою базою: більшість уявлень про таких агентів зводяться до одного проекту, одного репозиторію. Однак у реальному світі, особливо з мікросервісами та розподіленими системами, логіка розкидана по багатьох репозиторіях, сервісах і навіть командах. Одна зміна функціональності може зачіпати всі частини одночасно. Автор ставить питання: чи існує загальна стратегія, яка працює незалежно від конкретної архітектури?

Конкретний приклад: подвійні бали лояльності

Щоб зробити проблему наочною, автор наводить приклад застосунку з трьома сервісами: продуктовим (product service), сервісом замовлень (order service) та сервісом лояльності (loyalty service). Завдання — додати функцію, за якою певні продукти дають подвійні бали лояльності. Коли хтось купує такий продукт, на його рахунок нараховуються додаткові бали. Описати це просто, але реалізація зачіпає всі три сервіси: потрібно змінити логіку в кожному з них. Саме такі сценарії потребують уміння AI-агента координувати зміни між репозиторіями.

Два ключові компоненти для міжрепозиторної роботи AI-агента

Автор стверджує, що для ефективної роботи з кількома репозиторіями необхідні дві речі:

1. Представлення системи — це може бути Docker Compose файл, діаграма архітектури або будь-який інший опис, який показує, як сервіси з’єднані між собою (URL, змінні середовища). Це дає агенту початкову точку — карту, з якої він розуміє, які сервіси існують і як вони пов’язані.

2. Здатність агента проводити дослідження — використовуючи карту системи, агент має переглядати кожну кодову базу і визначати, як реалізувати зміни в усіх сервісах. Найкращий спосіб організувати це — через MCP-сервер, який надає два інструменти: один для пошуку в усіх кодових базах, інший для отримання повного контексту конкретного файлу.

Як влаштовано MCP-сервер

MCP-сервер (Model Context Protocol) стає посередником між AI-агентом та кодовим сховищем. Перший інструмент дозволяє агенту шукати фрагменти коду в усіх репозиторіях, щоб зрозуміти, де сервіси перетинаються та які файли потрібно змінити. Другий інструмент надає повний вміст файлу, що дає змогу агенту глибоко вивчити кожну кодову базу. Такий підхід перекладає основну роботу на налаштування цих інструментів, але потім дозволяє агенту автономно досліджувати систему.

Варіанти реалізації пошуку та читання файлів

Автор описує три способи налаштування інструментів для пошуку та читання файлів, залежно від масштабу проекту:

1. VS Code workspace — для невеликих проектів можна просто завантажити всі репозиторії в один робочий простір VS Code. Вбудовані інструменти (наприклад, Copilot) вже дозволяють агенту шукати та читати файли без додаткового налаштування. Це найпростіший шлях, що працює «з коробки».

2. GitHub REST API або GitHub MCP — гнучкіший варіант, що дозволяє агенту шукати та завантажувати файли прямо з GitHub. Однак пошук тут більш обмежений, і цей метод працює повільніше. Підходить, коли потрібна інтеграція з Git-хостингом, але не ідеальний для швидкої роботи.

3. Кастомний RAG-конвеєр з векторною базою даних — найкращий варіант, на думку авторів. Він збирає всі репозиторії, розбиває код на фрагменти (chunks), створює ембедінги та зберігає все у векторній базі (наприклад, Qdrant). Це дозволяє виконувати семантичний пошук — знаходити фрагменти за значенням, а не за точним збігом ключових слів. RAG слугує механізмом пошуку, а для отримання повних файлів можна використовувати GitHub API або подібний інструмент.

Таким чином, серверна частина системи складається з карти системи (наприклад, Docker Compose) та MCP-сервера з інструментами для пошуку та читання. Але ключовим для реалізації змін є правильно складені запити (prompts).

Два спеціальні запити для роботи AI-агента

Автор представляє два типові запити, які використовуються у запропонованому робочому процесі:

1. Map system (Карта системи)

Цей запит отримує початкову точку — у прикладі це файл Docker Compose. Агент використовує інструмент пошуку в коді, щоб знайти, як усе з’єднане: міжсервісні виклики, спільну конфігурацію, API-контракти тощо. Коли потрібно заглибитися, він отримує повний файл і читає його. Результат — Markdown-документ, який детально описує, як система взаємодіє на рівні коду: які сервіси спілкуються один з одним, через які інтерфейси, з посиланнями на реальні файли з репозиторіїв.

2. Plan solution (Планування рішення)

Після отримання карти запускається другий запит. Йому передається опис функціональності, яку потрібно реалізувати, і він читає карту системи як контекст. Потім агент «розгалужується» — використовує підаґентів для пошуку в репозиторіях та збору доказів, щоб точно визначити, що і де потрібно змінити. У прикладі з подвійними балами лояльності агент виявив зміни в усіх трьох сервісах і створив окремий план виконання для кожного з них. Результатом є набір файлів специфікацій (spec files) — по одному на репозиторій, які детально описують, що саме потрібно змінити.

Практична реалізація та висновки

Після отримання таких специфікацій подальша реалізація залежить від проекту: розробник може взяти кожен spec і впровадити зміни, або ж передати їх іншому AI-агенту для автоматичної імплементації. У будь-якому разі, команда отримує чіткий, обмежений план для кожного сервісу, що бере участь у зміні.

Автори з компанії Bitovi впроваджували подібну інфраструктуру в різних конфігураціях: з RAG і без нього, з GitHub API, VS Code workspace, векторними базами даних, а також із конвеєрами на платформах Temporal та N8N. Вони наголошують, що існує багато способів досягти результату, і закликають команди, які працюють у складних багаторепозиторних середовищах, звертатися до них за допомогою, оскільки вони мають глибокий практичний досвід у цій темі.