GPT-6.1 Sol im ersten schweren Test: sauberer Merge, zu wenig Scope-Disziplin
Nach den ersten Eindrücken zu GPT-6.1 Sol wollte ich wissen, wie sich das Modell bei einer Aufgabe schlägt, an der man sich verheben kann. Ich habe Sol 6.1 einen unangenehmen Merge gegeben und Claude Opus 5.5 als Prüfer danebengesetzt. Die Kurzfassung: Der Merge selbst ist gut gemacht. Von der Laufzeit ging aber der größere Teil in Testfehler, die schon vorher da waren und mit dem Merge nichts zu tun hatten.
Kurzfazit
Sol 6.1 arbeitet gründlich und sorgfältig, hat aber zu wenig Scope-Disziplin. Es repariert, was ihm unterwegs auffällt, statt es zu melden. Die Fixes waren korrekt, gehörten aber nicht zum Auftrag.
Der Auftrag
Das Ticket T-2042 sollte eine sechs Tage alte Arbeit ins Ziel mergen: die Optimistic-UI-Umsetzung aus T-1561. Optimistic UI heißt, die Oberfläche zeigt eine Änderung sofort an und gleicht sie erst danach mit dem Server ab. Das macht die App spürbar schneller, berührt aber viele Stellen im Code.
Das Ziel hatte sich in diesen sechs Tagen stark verändert, rund 600 Dateien. Dadurch gab es 12 Konfliktdateien, also Stellen, an denen beide Seiten denselben Code unterschiedlich geändert hatten und jemand entscheiden muss, was gilt.
Sechs Tage klingen nach wenig. In meinem Setup ist das viel: Mehrere Agenten arbeiten parallel in eigenen Git-Worktrees, also getrennten Arbeitskopien desselben Repos, und mergen laufend zurück. Sechs Tage entsprechen dadurch eher sechs Wochen in einer klassischen Entwicklungsumgebung. Genau deshalb war das ein guter Test: Ein Merge dieser Größe verlangt Verständnis für beide Seiten, nicht nur das Auflösen von Konfliktmarkern.
Wie ich geprüft habe
Sol 6.1 lief als Umsetzer, Opus 5.5 als Prüfer. Ich setze für Prüfungen bewusst ein Modell eines anderen Anbieters ein, weil es andere Fehler findet als das Modell, das den Code geschrieben hat. Opus 5.5 hat den Merge-Diff gelesen, die Commits danach einzeln eingeordnet und die Testläufe nachgefahren.
Was gut lief
Die Qualität des Merges hat mich überzeugt. Die Konflikte sind sauber gelöst, und zwar so, dass beide Seiten erhalten bleiben: die Optimistic-Marker aus dem alten Branch und die neue Zielspur aus dem aktuellen Stand, dazu die zwischenzeitlich gewachsenen Bereiche AGC und Cloud. Das ist der schwierige Teil eines solchen Merges. Die bequeme Lösung wäre, an solchen Stellen eine Seite zu nehmen und die andere still zu verlieren.
Die Prüfung war eindeutig: Typecheck grün, rund 1.900 gezielte Tests in den betroffenen Bereichen grün. Für einen Merge dieser Größe wäre etwa eine Stunde Arbeit angemessen gewesen. Diesen Teil hat Sol 6.1 geliefert.
Wo die Zeit hinging
Nach dem Merge hat der Agent noch rund zwei Stunden an vier weiteren Commits gearbeitet:
- Drei instabile Tests, also Tests, die mal grün und mal rot sind, ohne dass sich der Code ändert.
- Ein echter Bug im PlanPanel, einer Komponente, die mit dem Merge nichts zu tun hat.
Keiner dieser Fehler stammt aus dem Merge. Sie waren vorher schon da. Dazu kamen vermutlich mehrere Läufe der vollen Testsuite auf der VM, und jeder dieser Läufe kostet Zeit und Rechenleistung.
Hat sich der Agent verrannt? Teilweise. Die Fixes sind korrekt, das hat Opus 5.5 bestätigt. Der Bug im PlanPanel war sogar ein echter Fund. Aber der Auftrag lautete „merge T-1561 ins Ziel”, nicht „räum die Testsuite auf”. Sol 6.1 hat Fehler repariert, statt sie zu melden.
Warum das ein Problem ist, auch wenn die Fixes stimmen
Man könnte sagen: Zwei Stunden für vier korrekte Fixes, wo ist der Schaden? Der Schaden liegt woanders.
Der Auftrag wird unscharf. Ein Merge-Commit sollte genau das enthalten, was der Merge braucht. Mischen sich fremde Fixes hinein, wird der Branch schwerer zu prüfen und schwerer zurückzurollen, falls doch etwas schiefgeht.
Die Kosten werden unplanbar. Ich verteile Tickets mit einer Vorstellung davon, was sie kosten. Wenn ein Agent ein Vielfaches der geplanten Zeit braucht, weil er unterwegs aufräumt, stimmt die Rechnung nicht mehr. Bei einem Modell wie Sol 6.1, dessen Hauptargument der Preis pro Aufgabe ist, wiegt das doppelt.
Parallele Arbeit kollidiert. In meinem Setup arbeiten mehrere Agenten gleichzeitig. Repariert einer nebenbei etwas, an dem ein anderer gerade sitzt, entstehen genau die Konflikte, die ich mit getrennten Tickets vermeiden will.
Was ich daraus mitnehme
Sol 6.1 meint es gut. Das Modell sieht einen roten Test und will ihn grün haben, auch wenn er nicht zu seiner Aufgabe gehört. Das ist eine sympathische Eigenschaft, aber in einem Agenten-Setup eine teure. Ich habe zwei Wege, damit umzugehen.
Den Scope härter prompten. Ich schreibe künftig ausdrücklich in den Auftrag, was innerhalb und was außerhalb liegt. Bei Sol-Läufen ergänze ich einen festen Baustein:
Scope: Nur der Merge von T-1561 ins Ziel.
Fehler, die schon vor dem Merge bestanden (rote oder instabile Tests,
Bugs in nicht berührten Dateien): melden, nicht beheben.
Tests: nur die betroffenen Bereiche, die volle Suite höchstens einmal am Ende.Den Fund trotzdem nutzen. Dass Sol 6.1 die instabilen Tests und den PlanPanel-Bug gefunden hat, ist wertvoll. Ich will den Fund, nicht die Reparatur im falschen Ticket. Gemeldete Fehler landen bei mir als eigene Karte und werden dort sauber abgearbeitet.
Das Muster ist nicht neu. Leitplanken für Agenten, also feste Grenzen dafür, was ein Agent tun darf, sind ein eigenes Thema; ich habe es im Lexikon-Artikel zu Guardrails für Agenten ausführlicher beschrieben. Neu ist, wie deutlich Sol 6.1 diese Grenze braucht. Bei OpenAI selbst passt das ins Bild: Der Release-Bericht weist für Sol 6.1 mehr „unwanted persistence” aus als für Astra, also die Neigung, über den eigentlichen Auftrag hinaus weiterzumachen. Diesen Wert habe ich in meinem ersten Eindruck noch als Zahl notiert. Jetzt habe ich ihn in der Praxis gesehen.
Wie ich Sol 6.1 jetzt einordne
Sol 6.1 läuft auch in Codex, OpenAIs Coding-Umgebung, und übernimmt damit die Rolle, die früher spezialisierte Coding-Modelle wie GPT-5.3-Codex hatten. Nach diesem Test sehe ich es so:
- Für klar umrissene, schwierige Coding-Aufgaben ist Sol 6.1 stark. Der Merge war fachlich auf einem Niveau, das ich sonst von Opus erwarte, zu einem Bruchteil der Kosten.
- Für offene Aufträge ohne harte Grenze setze ich es nicht ein. Ohne klaren Scope arbeitet es weiter, als ich will.
- Als Prüfer bleibt bei mir Opus 5.5 gesetzt. Die Einordnung der vier Zusatz-Commits als „korrekt, aber nicht beauftragt” war genau die Art Urteil, die ich von einem Prüfer brauche.
Nebenbei
Das Titelbild habe ich nicht selbst ausgesucht. So sieht sich Sol 6.1 selbst, wenn man es fragt.
Fazit
Gründlich? Eindeutig. Diszipliniert? Noch nicht. Sol 6.1 hat einen schwierigen Merge sauber gelöst und dabei echte Fehler gefunden. Es hat aber nicht unterschieden zwischen dem, was es tun sollte, und dem, was es tun könnte. Mit einem klaren Scope im Auftrag ist das lösbar. Ohne ihn zahlt man für Arbeit, die man nicht bestellt hat.