Akka testet KI-Portierung in 65 Open-Source-Projekten mit 9,41 Milliarden Tokens

Das Experiment lief 99,3 Stunden und verbrauchte 9,41 Milliarden Tokens. Mit dieser Rechenleistung testete Akka, wie gut KI-Agenten Open-Source-Software portieren, wenn strukturierte Spezifikationen sie anleiten.

Spezifikationsgetriebene Portierung im großen Maßstab

Laut InfoQ analysierte Akka alle 65 Projekte in einer ersten Tranche. Das Team erstellte Spezifikationen und implementierte bis zu 10 Prozent der Oberfläche jedes Projekts. Danach wählte es anhand der Systemeigenschaften 10 Projekte für die vollständige Umsetzung aus. Die Delivery-Pipeline durchlief Erkundung, Spezifikation, Portierung, Benchmarking und Verbesserung. Claude übernahm zusammen mit Akka Specify Implementierung, Tests und Review. Diese Struktur erlaubte es dem Team, Fehlerstellen in der Migrationspipeline zu isolieren. Sie machte sichtbar, wo die Automatisierung erfolgreich war und wo Menschen eingreifen mussten. Der Prozess war kein einfaches Suchen und Ersetzen. Er war eine komplexe Aushandlung zwischen der Logik des Originalcodes und den neuen architektonischen Vorgaben der Zielumgebung.

Die Ergebnisse fielen gemischt aus, aber deutlich.

Akka meldete in 57 der 65 Portierungen eine Verbesserung bei Codezeilen oder Performance. Zugleich räumte das Unternehmen Lücken in den Kontextdateien bei Entscheidungen über Komponentengrenzen hinweg ein. Das deutet darauf hin, dass KI einzelne Komponenten bewältigt. Am Verständnis des Gesamtsystems scheitert sie, solange präzise, typisierte Verhaltensdefinitionen fehlen. Die Qualität der Spezifikation zählt mehr als die rohe Modellleistung. Teams, die eine KI-gestützte Modernisierung erwägen, sollten das beachten. Wer klare Verhaltensvorgaben definiert, bekommt in der ersten Runde bessere Implementierungen, als wer sich allein auf die Fähigkeiten des Modells verlässt. Für Engineering-Leiter, die in Migrationsplänen Tempo und Zuverlässigkeit abwägen, ist dieser Befund wichtig.

„Strukturierte Spezifikationen mit Behauptungen, Belegen und typisiertem Verhalten verbesserten die Implementierungen im ersten Durchlauf“, heißt es im Bericht.

Modelleffizienz und Kosten

Die Modellwahl beeinflusste Tempo und Kosten. Laut dem InfoQ-Bericht brauchte Sonnet im Schnitt 61 Minuten pro Portierung, Opus 120 Minuten. Opus verbrauchte jedoch rund 40 Prozent weniger Tokens. Höhere Effort-Einstellungen steigerten den Verbrauch, ohne die Effizienz durchgängig zu verbessern. Dieser Zielkonflikt zeigt die wirtschaftliche Realität, wenn Frontier-Modelle große Codemengen migrieren.

Kommentatoren auf LinkedIn merkten an, dass kleinere Modelle die Spezifikation genauer befolgten. Größere Modelle neigten zum Improvisieren. Aaditya, den InfoQ zitiert, schrieb: „Das Verhalten des kleineren Modells passte zu Modernisierungsarbeiten, die er beobachtet hatte: Das kleine Modell folgt der Spezifikation, während ein größeres Modell improvisiert.“ Diese Beobachtung deckt sich mit den Token-Daten. Vorgaben können bessere Ergebnisse liefern als rohe Leistungsfähigkeit. Für Unternehmen ist das größte verfügbare Modell nicht immer die beste Wahl, wenn eine Migration kosteneffizient bleiben soll.

Für Teams, die Budgets planen, liefert diese Zahl einen Anhaltspunkt.

Wer Altcode portiert, für den entscheidet die Qualität der Spezifikation darüber, ob Zeit gespart oder Rechenleistung verschwendet wird. Mit 9.400.000.000 Tokens lässt sich schwer kalkulieren. Das ist kein geringer Posten, auch nicht für einen großen Konzern.

Open-Source-Governance im KI-Zeitalter

Das Experiment fällt in eine Zeit, in der sich die Regeln für Sicherheit und Wartung von Open Source verschieben. Am 1. Oktober setzte Google die Meldung von Produktschwachstellen für sein Open Source Software Vulnerability Reward Program aus. Grund war laut Tom's Hardware eine Flut ungültiger KI-generierter Berichte. Das Programm soll erst im ersten Quartal 2027 wieder anlaufen. Der Schritt zeigt, wie stark KI-generierte Inhalte von Menschen moderierte Systeme belasten.

Ähnlich argumentierte Anil Madhavapeddy, Professor in Cambridge, in einem von InfoQ aufgegriffenen Artikel: KI-Agenten bringen die traditionelle Offenlegung von Sicherheitslücken durcheinander. Er beschrieb, wie wenige Minuten nach dem Öffnen eines PR zur Behebung einer Schwachstelle Sonden in den Logs seines Webservers auftauchten. „Es sieht für mich so aus, als müssten sich unsere Sicherheitsprozesse gewissermaßen umkehren“, schrieb er. Die Zeit zwischen Offenlegung und Ausnutzung schrumpft, weil KI-Agenten aus wenigen Hinweisen Exploits bauen können.

Diese Governance-Fragen sind nicht abstrakt. Sie betreffen dieselben Open-Source-Projekte, die KI-Agenten jetzt portieren und warten sollen. Wenn KI Code schreiben kann, kann sie auch Fehler finden. Die Schwierigkeit liegt darin, hilfreiche Automatisierung von bösartiger oder schlampiger Generierung zu unterscheiden. Das Akka-Experiment versucht Ersteres. Die Berichte von Google und aus Cambridge zeigen Letzteres.

Infrastruktur und Werkzeuge

Der Aufstieg der KI-gestützten Entwicklung verändert auch die Infrastruktur rund um Open Source. GitHub veröffentlichte am 5. Oktober ReviewBench, einen offenen Benchmark für KI-Codereview. Laut dem GitHub-Blog nutzt er 219 öffentliche Pull Requests in 19 Sprachen. Er ist nach über 100.000.000 echten Pull Requests modelliert. Ziel ist eine strenge, reproduzierbare Bewertungsmethodik für Code-Review-Agenten.

Ebenfalls am 5. Oktober veröffentlichte Reflection AI Beam, ein Modell mit offenen Gewichten und 501.000.000.000 Parametern insgesamt. Laut Semafor ist Beam als Arbeitspferd für Coding- und Agentenaufgaben positioniert. Es braucht drei- bis viermal weniger Rechenleistung als vergleichbare offene Modelle. Die Veröffentlichung folgt dem Trend zu effizienten Modellen mit offenen Gewichten, die sich lokal oder in souveränen KI-Systemen betreiben lassen.

Diese Werkzeuge bilden den neuen Stack für Open-Source-Entwicklung.

Da sind die Modelle (Beam, Sonnet, Opus), die Benchmarks (ReviewBench), die Workflows (Akka Specify) und die Sicherheitsprobleme (die Aussetzung des Google VRP). Das Ökosystem reift, aber unter Druck. Die 9.410.000.000 Tokens, die Akka verbrauchte, erinnern daran, dass das kein kostenloser Weg ist. Der Prozess ist ressourcenintensiv und verlangt sorgfältige Steuerung.

Für Entwickler ist die Lehre klar. KI kann Code portieren, braucht aber Struktur. Sie kann Code prüfen, braucht aber Benchmarks. Sie kann Schwachstellen finden, aber auch in Massen erzeugen. Bei Open Source geht es künftig nicht nur darum, wer den Code schreibt. Es geht darum, wie wir ihn im Zeitalter synthetischer Generierung prüfen, absichern und warten.