Akka testuje portowanie z AI na 65 projektach open source, zużywając 9,41 mld tokenów

Eksperyment trwał 99,3 godziny i zużył 9 410 000 000 tokenów. Akka przeznaczyła tę moc obliczeniową na sprawdzenie, jak dobrze agenci AI radzą sobie z przenoszeniem oprogramowania open source, gdy prowadzą ich ustrukturyzowane specyfikacje.

Portowanie oparte na specyfikacjach na dużą skalę

Według InfoQ Akka przeanalizowała wszystkie 65 projektów w pierwszej partii. Wygenerowała specyfikacje i zaimplementowała do 10% powierzchni każdego projektu. Następnie wybrała 10 projektów do pełnej implementacji na podstawie cech systemu. Zestaw narzędzi przechodził kolejno przez odkrywanie, specyfikację, portowanie, testy porównawcze i ulepszanie. Claude wraz z Akka Specify zajmował się implementacją, testowaniem i przeglądem. Taka struktura pozwoliła zespołowi wyodrębnić punkty awarii w procesie migracji i pokazała, gdzie automatyzacja sobie radzi, a gdzie potrzebna jest interwencja człowieka. To nie była prosta operacja znajdź i zamień, lecz złożone negocjowanie między logiką oryginalnego kodu a nowymi ograniczeniami architektonicznymi środowiska docelowego.

Wyniki były mieszane, ale znaczące.

Akka odnotowała poprawę liczby linii kodu lub wydajności w 57 z 65 portów. Firma zauważyła jednak, że w plikach kontekstu wciąż brakowało informacji o decyzjach międzykomponentowych. To sugeruje, że AI radzi sobie z izolowanymi komponentami, ale ma trudności z całościowym rozumieniem systemu bez precyzyjnych, typowanych definicji zachowania. Jakość specyfikacji ma większe znaczenie niż sama moc modelu. Zespoły rozważające modernizację wspieraną przez AI powinny to wziąć pod uwagę. Wysiłek włożony w zdefiniowanie jasnych ograniczeń zachowania daje lepsze implementacje w pierwszym przejściu niż poleganie wyłącznie na możliwościach modelu. To ustalenie jest istotne dla liderów inżynierii, którzy w planach migracji godzą szybkość z niezawodnością.

„Ustrukturyzowane specyfikacje z twierdzeniami, dowodami i typowanym zachowaniem poprawiły implementacje w pierwszym przejściu”, czytamy w raporcie.

Wydajność modeli i koszt

Wybór modelu wpływał zarówno na szybkość, jak i na koszt. Według raportu InfoQ Sonnet średnio potrzebował 61 minut na port, a Opus 120 minut. Opus zużył jednak około 40% mniej tokenów. Wyższe ustawienia wysiłku zwiększały zużycie, nie poprawiając konsekwentnie wydajności. Ten kompromis pokazuje ekonomiczną rzeczywistość korzystania z modeli frontier do masowej migracji kodu.

Komentujący na LinkedIn zauważyli, że mniejsze modele ściślej trzymały się specyfikacji. Większe modele miały skłonność do improwizacji. Aaditya, komentujący cytowany przez InfoQ, napisał: „Zachowanie mniejszego modelu odpowiadało pracom modernizacyjnym, które obserwowałem, gdzie mały model trzyma się specyfikacji, a większy może improwizować”. Ta obserwacja zgadza się z danymi o zużyciu tokenów. Ograniczenia mogą dawać lepsze wyniki niż sama zdolność. Dla zespołów korporacyjnych wybór największego dostępnego modelu nie zawsze jest optymalną strategią w opłacalnych projektach migracyjnych.

Dla zespołów zarządzających budżetami te dane dają punkt odniesienia.

Jeśli portujesz stary kod, jakość specyfikacji może zdecydować, czy zaoszczędzisz czas, czy zmarnujesz moc obliczeniową. Liczba 9 400 000 000 tokenów to twarda liczba, wokół której można planować. To nie jest trywialny koszt, nawet dla dużego przedsiębiorstwa.

Zarządzanie open source w erze AI

Eksperyment odbywa się na tle zmieniających się norm w bezpieczeństwie i utrzymaniu open source. 1 października Google zawiesiło zgłaszanie podatności produktów do swojego Programu Nagród za Podatności w Oprogramowaniu Open Source. Zrobiło to z powodu napływu nieprawidłowych raportów generowanych przez AI, według Tom's Hardware. Program nie wznowi działania do pierwszego kwartału 2 027 roku. Ten ruch pokazuje obciążenie, jakie treści generowane przez AI nakładają na systemy moderowane przez ludzi.

Podobnie Anil Madhavapeddy, profesor na Cambridge, przekonywał w artykule omawianym przez InfoQ, że agenci AI zakłócają tradycyjne ujawnianie podatności. Opisał, jak sondy pojawiły się w logach jego serwera kilka minut po tym, jak otworzył PR naprawiający podatność. „Wygląda na to, że nasze procesy bezpieczeństwa muszą się niejako odwrócić”, napisał. Czas między ujawnieniem a wykorzystaniem się skraca, bo agenci AI potrafią generować exploity z ograniczonych wskazówek.

Te kwestie zarządzania nie są abstrakcyjne. Dotyczą tych samych projektów open source, które agenci AI mają teraz portować i utrzymywać. Jeśli AI potrafi pisać kod, potrafi też znajdować błędy. Wyzwanie polega na odróżnieniu pomocnej automatyzacji od złośliwego lub niedbałego generowania. Eksperyment Akka próbuje rozwiązać to pierwsze. Raporty Google i Cambridge ilustrują to drugie.

Infrastruktura i narzędzia

Rozwój wspieranego przez AI programowania zmienia też infrastrukturę wokół open source. GitHub udostępnił ReviewBench, otwarty benchmark do przeglądu kodu przez AI, 5 października. Według bloga GitHub benchmark wykorzystuje 219 publicznych pull requestów w 19 językach. Powstał na wzór ponad 100 000 000 rzeczywistych pull requestów. Ma zapewnić rygorystyczną, powtarzalną metodologię oceny agentów przeglądających kod.

Tymczasem Reflection AI udostępniło Beam, model o otwartych wagach z 501 000 000 000 parametrów łącznie, 5 października. Według Semafor Beam jest pozycjonowany jako „koń roboczy” do kodowania i zadań agentowych. Wymaga trzy do czterech razy mniej mocy obliczeniowej niż porównywalne modele otwarte. Wydanie odzwierciedla trend w stronę wydajnych modeli o otwartych wagach, które można wdrażać lokalnie lub w suwerennych systemach AI.

Te narzędzia tworzą nowy stos do rozwoju open source.

Masz modele (Beam, Sonnet, Opus), benchmarki (ReviewBench), procesy (Akka Specify) i wyzwania bezpieczeństwa (zawieszenie programu VRP Google). Ekosystem dojrzewa, ale robi to pod presją. 9 410 000 000 tokenów zużytych przez Akka przypomina, że to nie jest darmowy obiad. To proces intensywnie korzystający z zasobów, który wymaga starannego zarządzania.

Wniosek dla inżynierów jest jasny. AI potrafi portować kod, ale potrzebuje struktury. Potrafi przeglądać kod, ale potrzebuje benchmarków. Potrafi znajdować podatności, ale potrafi też nimi zalewać. Kierunek open source nie dotyczy tylko tego, kto pisze kod. Dotyczy tego, jak go weryfikujemy, zabezpieczamy i utrzymujemy w erze syntetycznego generowania.