GPT-5: Können KI-Codierungsagenten sich selbst verbessern?
Das Konzept der KI-Selbstverbesserung ruft oft Bilder von Maschinen hervor, die das menschliche Verständnis übertreffen – eine Vorstellung, die häufig mit Bedenken hinsichtlich der KI-Sicherheit verbunden ist. Die Untersuchung, wie große Sprachmodelle (LLMs) ihre eigene Leistung verbessern könnten, bietet jedoch eine fundiertere Perspektive. Diese Untersuchung befasst sich mit der „Inferenzzeit-Selbstverbesserung“, einem Szenario, in dem Modelle, ohne dass ihre Kern-Gewichtungen aktualisiert werden, ihre Effizienz bei bestimmten Aufgaben steigern könnten. Dies unterscheidet sich von der „Trainingszeit-Selbstverbesserung“, die sich auf algorithmische Fortschritte oder Datenoptimierung während des Modelltrainings konzentriert. Für die meisten KI-Ingenieure, die hauptsächlich als Benutzer und nicht als Trainer mit Modellen interagieren, stellt die Fähigkeit von Modellen, ihre eigene operationale Effektivität zur Inferenzzeit zu verbessern, ein vielversprechendes Forschungsgebiet dar.
Die Kernidee konzentriert sich darauf, Codierungsagenten als Kanäle für LLMs zu nutzen, um Wert aus ihrem eigenen internen Wissen oder „latenten Räumen“ zu ziehen. Um dies zu untersuchen, wurde ein experimenteller Ablauf entwickelt: Zuerst wurde das Modell aufgefordert, eine Reihe von Tools zu erstellen, von denen es glaubte, dass sie seine Produktivität steigern würden; als Nächstes versuchte es eine Aufgabe unter Aufsicht mit diesen Tools; schließlich reflektierte es, wie die Tools verfeinert werden könnten. Dieser Prozess wurde hauptsächlich mit GPT-5 getestet und mit Opus 4 verglichen.
Erste Ergebnisse zeigten, dass GPT-5 hervorragend darin war, Entwickler-Dienstprogramme zu generieren. Es zeigte sich jedoch ein signifikantes Paradoxon: Das Modell lehnte es oft ab, genau die Tools zu verwenden, die es erstellt hatte. Wie GPT-5 nach einer Aufgabe offen sagte: „Ich bin ehrlich – ich brauchte keines davon.“ Diese Beobachtung traf bei mehreren Tests zu, einschließlich Vergleichen mit anderen führenden Modellen wie Gemini 2.5 Pro und GPT-4.1, wobei Opus 4 sich durchweg als einziger mit GPT-5 vergleichbarer Performer erwies.
Zwei spezifische Tools wurden ursprünglich vom menschlichen Experimentator in Auftrag gegeben. Das erste war ein fortschrittlicher Aufgabenmanager, der für parallele Codierungsagenten entwickelt wurde. Da mehrere KI-Instanzen oft in separaten Entwicklungsumgebungen arbeiten, wurde ein robustes System benötigt, um Änderungen zu verfolgen, Abhängigkeiten zu verwalten und potenzielle Konflikte zu kennzeichnen – eine Herausforderung für Menschen, die zahlreiche Pull-Requests lesen. Die Lösung von GPT-5 für diesen Aufgabenmanager war bemerkenswert ausgeklügelt und umfasste Write-Ahead-Logging (WAL) für gleichzeitige Schreibvorgänge, einen Abhängigkeitsgraphen zur Aufgabenpriorisierung und einen Append-Only-Event-Stream, um alle Agenten mit Schlüsselwörtern wie impact_conflict synchron zu halten. Opus 4 produzierte ebenfalls einen funktionsfähigen Aufgabenmanager, dem jedoch die umfassenden Benachrichtigungs- und Synchronisierungsfunktionen fehlten.
Das zweite angeforderte Tool war ein „Code-Qualitätsstandards-Playbook“. Dies zielte darauf ab, Codebase-Heuristiken zu formalisieren, indem bestehende Tools wie ESLint für Linting und Typüberprüfung genutzt wurden, während auch benutzerdefinierte Regeln oder sogar maßgeschneiderte Tools für qualitativere Standards (z. B. schlanke Controller oder indizierte Datenbankspalten) zugelassen wurden. Der Markdown-basierte Plan von GPT-5 für dieses Playbook wurde als nuancierter als der von Opus 4 angesehen und bot einen gründlichen Ansatz zur Analyse und Strukturierung von Codequalitätsregeln über verschiedene Codebases hinweg.
Der aufschlussreichste Teil des Experiments bestand darin, die Modelle zu fragen, was sie dachten, sie bräuchten, um produktiver zu sein. Nachdem sie eine Beschreibung einer Software-Engineering-Aufgabe erhalten hatten, schlugen sowohl GPT-5 als auch Opus 4 eine Reihe von Tools vor. GPT-5 konzipierte seine Tools als schlanke Befehlszeilen-Dienstprogramme, darunter doctor für Umgebungsprüfungen, code-map für die Repository-Indizierung, csearch für die Symbolsuche und impact, um Aufgaben anzuzeigen, die mit geänderten Dateien verknüpft sind. Opus 4 hingegen schlug Tools mit beschreibenderen, anthropomorphen Namen vor, wie „Context Analyzer“, „Cross-Platform Test Generator“ und „Bug Pattern Recognition Engine“, die als Standard-Python-Skripte implementiert wurden. Während beide Modelle in ähnliche funktionale Richtungen konvergierten, war der Ansatz von GPT-5 prägnanter und auf Dienstprogramme ausgerichtet, während der von Opus 4 seinen Tools einen breiteren, aufgabenorientierteren Umfang zu verleihen schien.
Um den praktischen Nutzen dieser selbstgenerierten Tools zu bewerten, wurde eine komplexe Aufgabe zugewiesen: die Migration einer bestehenden Flask-Monolith-Anwendung (smol-podcaster) zu einem FastAPI-Backend mit einem Next.js-Frontend, komplett mit TypeScript, Tailwind/ShadCN-Styling, modularisierter Backend-Logik und umfassenden Tests. Sowohl GPT-5 als auch Opus 4, mit Zugriff auf ihre erstellten Tools, waren fast in der Lage, die Migration in einem einzigen Versuch abzuschließen, wobei nur geringfügige menschliche Unterstützung zur Behebung von Python-Abhängigkeitsproblemen erforderlich war. Die resultierenden Anwendungen waren voll funktionsfähig, obwohl GPT-5 das ursprüngliche Design beibehielt, während Opus 4 eigene Designänderungen einführte.
Entscheidend ist, dass beide Modelle auf die Frage, ob sie während dieser anspruchsvollen Migration ihre benutzerdefinierten Tools verwendet hätten, negativ antworteten, abgesehen von Tools, mit denen sie bereits von Natur aus vertraut waren. GPT-5 führte dies darauf zurück, dass Laufzeit-/Umgebungsprobleme schneller direkt zu beheben waren und ein Mangel an „repo-weiten Refactoring oder Diagnosen, die von benutzerdefinierten Tools profitieren würden“ in diesem Durchlauf – eine überraschende Behauptung angesichts der Art der Migration. Die Begründung von Opus 4 sorgte für weitere Klarheit: Das Modell teilte effektiv mit, dass es die Tools auf der Grundlage seines vorhandenen Wissens gebaut hatte, aber als es mit der eigentlichen Aufgabe konfrontiert wurde, fand es es effizienter, einfach seine inhärenten Fähigkeiten zu nutzen, anstatt externe Tools aufzurufen.
Diese Beobachtung stimmt mit früheren Diskussionen in der KI-Community überein, die darauf hindeuten, dass Modelle schnell lernen können, Tools zu vermeiden, wenn sie während ihres Betriebsprozesses frühe Fehler erleben, oder dass ein umfangreiches „Gerüst“ für Agenten unnötig werden könnte, wenn Modelle skalieren. Obwohl die zugewiesene Aufgabe anspruchsvoll genug war, um für einen Menschen ein mehrstündiges Unterfangen zu sein, stellt sich die Frage, ob komplexere Aufgaben Modelle dazu zwingen könnten, ihre benutzerdefinierten Tools zu verwenden.
Zusammenfassend lässt sich sagen, dass aktuelle große Sprachmodelle eine bemerkenswerte Fähigkeit zeigen, anspruchsvolle Entwickler-Tools zu entwerfen, ihre Neigung, diese Tools bei komplexen Codierungsaufgaben zu verwenden, jedoch begrenzt bleibt. Dies deutet darauf hin, dass das Erreichen einer echten „Inferenzzeit-Selbstverbesserung“ bei Codierungsagenten mehr als nur die Tool-Erstellung erfordern könnte; es könnte robustere Durchsetzungsmechanismen oder weitere Fortschritte in der Art und Weise erfordern, wie Modelle neue Fähigkeiten internalisieren und integrieren. Für die absehbare Zukunft besteht ein pragmatischer Ansatz darin, Modelle zur Verfeinerung regelbasierter Entwicklungstools (wie ESLint-Regeln oder automatisierte Tests) zu nutzen und dadurch menschengesteuerte Arbeitsabläufe zu verbessern, anstatt sich ausschließlich darauf zu verlassen, dass Modelle ihre eigenen Kreationen spontan zur Selbstverbesserung übernehmen.