Czy agenci AI potrafią nawigować w kodzie Ruby?
Współczesne modele sztucznej inteligencji radzą sobie z pisaniem kodu w języku Ruby zaskakująco dobrze. Pojawia się jednak kluczowe pytanie: czy potrafią one skutecznie poruszać się po istniejącej, złożonej bazie kodu? W scenariuszu, w którym inżynier planuje modyfikację centralnego modelu danych, agent musi zidentyfikować wszystkie miejsca zależne od tej zmiany, zanim nieumyślnie doprowadzi do awarii systemu.
Przeprowadzone testy na 13 rzeczywistych projektach oraz 5 różnych modelach AI pokazują wyraźny podział. W przypadku małych, przejrzystych bibliotek (gemów), standardowe narzędzia agentów, takie jak przeszukiwanie plików czy polecenia powłoki, są wystarczające. Jednak w dużych aplikacjach agenci często odnajdują jedynie ułamek zależności, błędnie uznając audyt za zakończony. Sytuacja zmienia się diametralnie, gdy agent otrzyma dostęp do strukturalnej mapy bazy kodu.
Wpływ mapy strukturalnej na skuteczność
W testach porównano działanie agentów w dwóch trybach: podstawowym (wykorzystującym standardowe narzędzia) oraz rozszerzonym o mapę strukturalną (trwały graf symboli, połączeń i relacji frameworkowych). Wyniki pokazują, że dostęp do mapy znacząco poprawia tzw. „cited recall”, czyli zdolność agenta do wskazania precyzyjnej lokalizacji w kodzie, którą inżynier może zweryfikować.
Największy zysk odnotowano w najtrudniejszym obszarze: identyfikacji zależności. Modele, które miały trudności z odnalezieniem powiązań poprzez polimorficzne asocjacje czy usługi, dzięki mapie strukturalnej zyskały znacznie wyższą skuteczność. Co istotne, nawet słabsze modele, takie jak Devstral (24B), dzięki mapie osiągały wyniki porównywalne z liderami, co sugeruje, że mapa skutecznie kompensuje ograniczenia pamięci roboczej modelu.
Gdzie mapa staje się niezbędna?
Analiza wyników w zależności od wielkości projektu ujawnia wyraźną granicę. Projekty przekraczające 2500 plików odnotowały wzrost skuteczności o co najmniej +0.25, podczas gdy w mniejszych repozytoriach zysk był minimalny.
W dużych systemach, takich jak GitLab (ponad 36 tysięcy plików), ręczne przeszukiwanie kodu przez agenta jest nieefektywne. W takich warunkach mapa pozwala na natychmiastowe rozwiązanie zależności, które w innym przypadku pozostałyby niewidoczne dla standardowych metod wyszukiwania. Z kolei w przypadku znanych frameworków, takich jak Rails, modele często polegają na swojej „pamięci” z procesu uczenia. Jednak nawet tam, w kwestii wewnętrznych mechanizmów kompilacji zapytań, których nie opisano w tutorialach, mapa strukturalna drastycznie poprawiała precyzję wskazań.
Koszty i efektywność
Wprowadzenie mapy strukturalnej nie zawsze oznacza wyższe koszty tokenów. W zależności od modelu, zużycie tokenów rozliczeniowych zmieniało się w różny sposób:
Warto zauważyć, że w przypadku dużych projektów, niewielki wzrost zużycia tokenów jest marginalnym kosztem w porównaniu do uniknięcia krytycznej awarii produkcyjnej spowodowanej pominięciem zależności w kodzie.
Transparentność benchmarku
Aby zapewnić wiarygodność wyników, testy oparto na rygorystycznych zasadach:
Dla użytkowników chcących przetestować to rozwiązanie we własnym środowisku, dostępne jest narzędzie Sense, które pozwala na wygenerowanie mapy strukturalnej lokalnie, bez przesyłania danych na zewnątrz. W małych projektach różnica może być niezauważalna, jednak w rozbudowanych aplikacjach różnica w jakości audytu kodu jest zazwyczaj znacząca.
