Dlaczego w ogóle śledzić wkład AI?
Wraz z upowszechnieniem asystentów programistycznych pojawił się nowy problem: repozytorium pokazuje jedynie autora commita, a nie to, że duża część kodu powstała przy pomocy AI. Trudno wtedy odpowiedzieć na pytania o pochodzenie fragmentów kodu, jakość poszczególnych agentów czy wymagania compliance. Rozszerzenie git-ai (Git AI) powstało właśnie po to, aby w sposób precyzyjny i powtarzalny śledzić linijki wygenerowane przez modele AI w standardowym przepływie pracy Git.
Czym jest git-ai (Git AI)
Git AI to otwartoźródłowe rozszerzenie Gita, działające jako cienka nakładka na binarkę git. Narzędzie jest zaprojektowane jako “Git-native”: nie wprowadza nowego serwera ani centralnej bazy, lecz zapisuje metadane o autorstwie AI w notatkach Gita (git notes) powiązanych z hashami commitów. Rozwiązanie działa lokalnie, offline, a dane o promptach i autorstwie nie opuszczają maszyny dewelopera.
Kluczową cechą Git AI jest podejście multi-agentowe. Narzędzie nie zakłada jednego „oficjalnego” asystenta – potrafi rozróżniać wkład różnych agentów i modeli (np. różnych wersji tego samego narzędzia), dzięki czemu zespół może realnie porównywać ich efektywność w tym samym repozytorium.
Integracje z agentami i IDE
Git AI udostępnia komendę instalującą hooki dla wspieranych agentów, tak aby to one explicite zgłaszały swoje zmiany. Dla dewelopera oznacza to brak dodatkowych kroków w codziennej pracy – integracja odbywa się na poziomie IDE lub CLI agenta.
| Agent / IDE | Śledzenie autorstwa | Zapisywanie promptów | Uwagi |
|---|---|---|---|
| Cursor > 1.7 | tak | tak | automatyczne hooki git-ai |
| Claude Code | tak | tak | wsparcie natywne |
| GitHub Copilot (VS Code) | tak | tak | poprzez rozszerzenie i hooki |
| Inne agenty | zależnie od integracji | zależnie od integracji | można dodać przez rozbudowę hooków |
Jak działa mechanizm checkpointów i notatek
Git AI funkcjonuje jako proxy dla polecenia git: to git-ai znajduje się na ścieżce $PATH, przechwytuje wywołania i deleguje je do właściwego Gita, dodając przy tym logikę śledzenia AI. IDE i agenci nie muszą zmieniać zachowania – dla nich wszystko wygląda jak zwykłe wywołanie git.
Podstawą są tzw. checkpointy. Agent wywołuje git-ai checkpoint zanim zapisze zmiany na dysku, aby oznaczyć dotychczasowe edycje jako „ludzkie”. Następnie, po wygenerowaniu kodu, wywołuje checkpoint z nazwą agenta (np. git-ai checkpoint cursor-gpt-5). W ten sposób Git AI może przypisać konkretne linie do konkretnego agenta wraz z kontekstem promptu, który doprowadził do ich powstania.
Przy commicie Git AI pakuje historię checkpointów i transkrypcje promptów do notatek Gita (np. w referencji notes/ai). Dodatkowo modyfikuje domyślne git fetch / git push, aby te notatki były synchronizowane razem z historią repozytorium.
Najważniejsze komendy git-ai
git-ai stats [<commit-sha>] [--json]– pokazuje statystyki autorstwa dla commita, w tym udział linii wygenerowanych przez AI oraz ludzi.git-ai blame <plik>– rozszerzona wersjagit blame, która oprócz autora pokazuje także to, czy linia pochodzi z AI, oraz z jakiego agenta/modelu.git-ai install-hooks– konfiguruje integracje z obsługiwanymi agentami i IDE, tak aby zaczęły raportować checkpointy.
Metryki jakości kodu AI
Ponieważ Git AI wie, które linie wprowadził dany agent i jak potoczył się ich los w historii repozytorium, może obliczać metryki przydatne do porównywania modeli. Przykładowo:
| Metryka | Co mierzy | Przykładowe zastosowanie |
|---|---|---|
| Local Accepted | Stosunek linii AI, które trafiły do commita, do wszystkich linii wygenerowanych lokalnie przez agenta. | Ocena, jak wiele propozycji deweloper akceptuje zamiast odrzucać. |
| PR Accepted | Procent linii AI, które przechodzą przez code review i trafiają do gałęzi głównej. | Porównanie agentów pod kątem akceptacji przez zespół. |
| Prod Halflife | Średni czas, po którym połowa linii danego agenta zostaje zmodyfikowana lub usunięta w produkcji. | Ocena trwałości i jakości kodu w dłuższym okresie. |
Praktyczne zastosowania w zespołach
- Audyt i compliance – możliwość pokazania, które fragmenty systemu powstały z udziałem AI, może być wymagana przez regulacje lub wewnętrzne polityki firmy.
- Porównywanie agentów – metryki akceptacji i „półokresu życia” kodu pozwalają świadomie wybierać i konfigurować narzędzia AI.
- Lepszy code review – recenzent widzi od razu, ile w danym pliku pochodzi z AI oraz ma dostęp do oryginalnych promptów, co ułatwia zrozumienie intencji zmian.
- Zarządzanie długiem technicznym – łatwo wyszukać starsze fragmenty generowane przez AI i podjąć decyzję o refaktoryzacji lub ponownym wygenerowaniu na nowszym modelu.
Ograniczenia i pułapki
Warto pamiętać, że nie wszystkie typy edycji są dziś śledzone idealnie. Podpowiedzi z klasycznego IntelliSense czy proste uzupełnienia tabulatorem są zazwyczaj traktowane jako edycje „ludzkie”. Git AI skupia się na wyraźnych interakcjach z agentem (prompt → wygenerowany blok kodu). Obecnie mierzone są głównie dodania linii przez AI – usunięcia nie zawsze wchodzą do statystyk. Dodatkowo notatki Gita mogą zostać utracone przy niektórych operacjach przepisywania historii (np. rebase wykonywanym poza środowiskiem z Git AI), jeśli nie zadba się o ich przeniesienie.
Podsumowanie
Git AI / git-ai proponuje praktyczny standard śledzenia kodu generowanego przez AI, który nie wymaga zmiany dotychczasowego workflow w Git. Dzięki wykorzystaniu git notes, mechanizmu checkpointów oraz integracji z popularnymi agentami, zespoły mogą wreszcie mierzyć realny wpływ narzędzi AI na bazę kodu – od lokalnych zmian, przez pull requesty, po długoterminową trwałość w produkcji.
