Чому Git більше не вистачає в епоху AI-коду

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Мене звати Артем Долобанько. Це історія про те, як DevOps-інженер поступово занурився у світ розробки та продуктів.

Я працюю в ІТ понад 15 років: починав як системний адміністратор, далі перейшов у DevOps, працював із інфраструктурою, high-load системами та командами різного масштабу. З часом я почав займатися не лише технічною частиною, а й продуктами — так з’явилися кілька компаній і проєктів, з якими я працюю сьогодні.

Останнім часом я все частіше ловив себе на думці, що традиційні підходи до управління вихідним кодом починають відставати від реальності. Особливо це стало помітно з появою AI-інструментів у розробці.

Мій досвід — це поєднання інфраструктури, розробки та продуктового мислення, і саме це дало мені змогу побачити проблему трохи ширше. Сучасні команди стикаються не тільки зі швидкістю генерації коду, а й із відсутністю прозорості: складно зрозуміти, як саме цей код з’явився, хто за нього відповідає і чи можна йому довіряти.

У якийсь момент я сформулював для себе просту мету: знайти спосіб зробити AI-розробку більш зрозумілою, керованою і передбачуваною для команд.

За останній рік штучний інтелект змінив розробку швидше, ніж будь-яка технологія до цього. І це змушує переглянути багато звичних речей. Сьогодні розробники все частіше не пишуть код вручну, вони генерують його за допомогою інструментів на кшталт Copilot, GPT або інших AI-асистентів. У деяких командах частка такого коду вже перевищує 50–70%.

Але разом зі швидкістю з’явилась нова проблема — ми перестали розуміти, що саме потрапляє в наш код.

«Сліпі зони»

Поспілкуйтеся з будь-яким керівником відділу розробки, який використовує агентів ШІ у своїй команді, і ви почуєте одні й ті самі запитання:

• Хто написав цей код? — код, автором якого вказано «[email protected]», може бути на 100% згенерований ШІ. Заголовки «Co-Authored-By» ненадійні. Більшість агентів їх не додають.
• На що ми витрачаємо кошти? — Рахунки за API Claude сягають 2 тис. доларів на місяць, і ніхто не знає, який розробник або проект спричиняє ці витрати. Використання токенів на рівні команди є невидимим.
• До чого може торкатися ШІ? — Чи повинні агенти ШІ змінювати конфігурації у виробничому середовищі? Логіку обробки платежів? Немає рівня контролю за дотриманням правил.
• Який контекст було втрачено? — Розробник працює з Claude протягом 3 годин, зупиняється і продовжує роботу наступного дня. Контекст сеансу, підказки та міркування зникли.

Чому Git — це замало

Git чудово справляється з відстеженням змін. Але він ніколи не призначався для відстеження намірів. Ось як виглядає стандартний вивід команди git blame для коду, написаного штучним інтелектом:

Перший результат не містить жодної корисної інформації. Другий же точно вказує, які рядки написав ШІ, а які відредагувала людина. У цьому й полягає різниця між тим, щоб діяти наосліп, і тим, щоб мати повну картину.

Як повинен працювати продукт, який я хочу реалізувати

Він виступає посередником між вашим агентом ШІ з кодування та git. Це не нова система контролю версій — це рівень атрибуції, який робить git сумісним із ШІ.

Коли розробник використовує будь-який агент ШІ для кодування, git-хуки спрацьовують автоматично. Командний інтерфейс (CLI) визначає, який агент працює, зчитує транскрипт сеансу та записує метадані у git-нотатки. Ніякого ручного тегування, ніяких змін у робочому процесі. Все просто працює.

Відтворення сеансу: перегляд усіх підказок та рішень

Кожен сеанс кодування ШІ фіксується від початку до кінця: підказки, які дав розробник, файли, до яких торкнувся ШІ, точні відмінності для кожної підказки, використання токенів, вартість та модель. Коли щось ламається у виробництві, ви бачите не лише те, що змінилося, а й чому це змінилося.

Прозорість витрат: ви будете знати, куди йде кожен долар

Коли ваша команда використовує 5 різних агентів штучного інтелекту у 20 репозиторіях, витрати на API швидко зростають. Наша ідея відстежувати витрати за сеансом, за моделлю, за розробником та за репозиторієм. Більше ніяких несподіваних рахунків.

Новий рівень управління версіями

Згадайте, що GitHub зробив для git. Git вже існував. Він був потужним. Але тодішня модель git-workflow погано масштабувалась для більшості команд. GitHub додав рівень співпраці — запити на злиття, рецензування коду, завдання, CI/CD — що зробило git корисним для команд.

Ідея мого продукту робити те саме для кодування ШІ. Git існує. Він як і раніше є основою. Але він був створений для світу, де код пишуть люди. Він буде додавати рівень управління ШІ: атрибуцію, відстеження сеансів, прозорість витрат, забезпечення дотримання політик, аудиторські сліди, усе, що робить git корисним для команд, які використовують ШІ-агентів.

Це нова ера управління вихідним кодом. Не тому, що git не працює, а тому, що спосіб написання коду кардинально змінився, і наші інструменти повинні йти в ногу з часом.

Що далі

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

• Об’єднання сеансів — автоматичне з’єднання сеансів, що тривають після перезапуску агентів та нічних перерв;
• Координація роботи декількох агентів — відстеження випадків, коли кілька AI-агентів одночасно працюють над одним і тим самим кодом;
• Панелі моніторингу в режимі реального часу — пряма трансляція сеансів із відстеженням витрат за кожним токеном;
• Звіти про відповідність вимогам — генерація доказів SOC 2 та ISO 27001 одним кліком.

Я планую зробити цей інструмент назавжди безкоштовним для індивідуальних розробників. Немає обмежень на репозиторії, сеанси чи агентів. Якщо ви використовуєте ШІ для написання коду, ви повинні знати, що саме він пише.