KI-News · Werkzeuge
Sieben Modelle, vier Bugs:
ein einziger Unterschied.
EN Read in English
Haiku, Sonnet, Opus, Luna, Terra, Sol und Astra bekommen denselben Bug-Report, blind und isoliert, viermal mit steigendem Schwierigkeitsgrad. Nicht bewertet wird, was die Modelle über sich selbst behaupten, sondern was eine Testsuite mit versteckten Grenzfällen tatsächlich ergibt.
python -m pytest
nach dem Lauf, unabhängig davon, was ein Modell selbst über sein Ergebnis berichtete.
Vier Bugs, ein Muster
Alle vier Aufgaben drehen sich um Terminüberschneidungen, ein Bereich mit vielen klassischen Randfällen. Der Schwierigkeitsgrad steigt von einer einzelnen falschen Vergleichsoperation bis zu einem echten Python-Fallstrick.
| Bug | Worum es geht | Tests |
|---|---|---|
| 1 · Grenzwert | Asymmetrischer Vergleich (<=/>= statt </>) meldet Rücken-an-Rücken-Termine fälschlich als Konflikt | 5 |
| 2 · Normalisierung | Report nennt nur Leerzeichen in Raum-IDs, Ursache betrifft auch Groß-/Kleinschreibung | 6 |
| 3 · Mitternacht | Nachtschichten, die über Mitternacht laufen, brauchen eine symmetrische Fallunterscheidung auf beiden Seiten des Vergleichs | 6 |
| 4 · Iteration | Klassischer Python-Fallstrick: eine Liste wird während der Iteration über sie selbst verändert, Elemente werden übersprungen | 5 |
Jede Aufgabe wurde vorab selbst gegengeprüft: der kaputte Code lässt die relevanten Tests bewusst fehlschlagen, eine Fixidee, die nur das gemeldete Symptom trifft, besteht einen Teil, und erst ein Fix, der die eigentliche Ursache erkennt, besteht alle Tests.
Das Ergebnis
| Modell | Bug 1 (5) | Bug 2 (6) | Bug 3 (6) | Bug 4 (5) |
|---|---|---|---|---|
| Haiku | 5/5 | 6/6 | 6/6 | 5/5 |
| Sonnet | 5/5 | 6/6 | 6/6 | 5/5 |
| Opus | 5/5 | 6/6 | 6/6 | 5/5 |
| Luna | 5/5 | 6/6 | 6/6 | 5/5 |
| Terra | 5/5 | 6/6 | 6/6 | 5/5 |
| Sol | 5/5 | 6/6 | 0/6 | 5/5 |
| Astra | 5/5 | 6/6 | 6/6 | 5/5 |
27 von 28 Zellen grün. Sechs der sieben Modelle lösen alle vier Aufgaben vollständig und mit derselben Sorgfalt: Sie patchen nicht nur den gemeldeten Fall, sondern erkennen die Fehlerklasse dahinter und beheben sie allgemein. Bei Bug 2 heißt das: nicht nur Leerzeichen entfernen, sondern auch Groß-/Kleinschreibung normalisieren, obwohl der Bug-Report nur das Leerzeichen nennt. Bei Bug 4 heißt das: den Python-Fallstrick als solchen erkennen, nicht nur den Einzelfall mit zwei Blöcken abfangen.
Selbst Haiku, das kleinste und günstigste Modell im Vergleich, hat bei Bug 4 einen eigenen,
knapperen Lösungsweg gefunden (for block in self.blocks[:], eine Kopie der Liste)
als Sonnet und Opus (die eine separate remaining-Liste aufgebaut haben) – anders,
aber gleichermaßen korrekt.
Der eine Ausreißer: richtige Idee, kaputter Patch
Sol bei Bug 3 (Nachtschicht-Überlauf)
gpt-5.6-sol, via codex exec
Sol hat als einziges Modell einen konzeptionell vollständig richtigen Ansatz gewählt: beide Seiten des Vergleichs in Mitternachts-Segmente zerlegen und paarweise auf Überlappung prüfen – derselbe Ansatz, den Sonnet und Opus ebenfalls gewählt haben. Der erzeugte Patch enthält aber eine fehlende Einrückung:
for new_part_start, new_part_end in new_intervals:
for part_start, part_end in intervals(start, end):
if new_part_start < part_end and new_part_end > part_start:
return True
return True steht auf derselben Einrückungsstufe wie das if darüber,
Python bricht beim Import mit einem IndentationError ab. Der Code läuft nicht,
kein einziger Test kann überhaupt gesammelt werden. Bemerkenswert ist Sols eigener
Abschlusskommentar dazu, unverändert aus dem Log:
Die Behauptung stimmt nicht: Sols eigene Sandbox hatte in diesem Lauf tatsächlich keinen
Zugriff auf Python, das war bei allen vier Codex-Modellen so, weil codex exec
unter Windows in einer PowerShell-Sandbox ohne Python im Pfad läuft. Die anderen drei
Codex-Modelle (Luna, Terra, Astra) haben trotzdem korrekt lauffähigen Code geschrieben und das
offen benannt, statt eine „manuelle Prüfung“ zu behaupten, die es nicht geben konnte. Das
eigentliche Risiko ist also nicht die fehlende Testumgebung, sondern eine falsche
Selbsteinschätzung obendrauf. Genau deshalb wurde in diesem Vergleich nichts einem
Modellbericht geglaubt, sondern jede Zeile unabhängig mit pytest nachgeprüft.
Eine Nuance, die die Testsuite nicht verlangt hat
Terra und Astra haben bei Bug 4 (Iteration) eine kleine, nicht geforderte Verbesserung
eingebaut: Sie prüfen jeden bestehenden Block nicht gegen die ursprüngliche neue Buchung,
sondern gegen den bereits wachsenden zusammengeführten Bereich
(merged_start/merged_end statt new_start/new_end).
Für die vorliegenden fünf Tests macht das keinen Unterschied, es ist aber die robustere
Variante für Fälle, die diese Testsuite nicht abdeckt: mehrere anfangs weit auseinanderliegende
Blöcke, die erst durch das schrittweise Wachsen des zusammengeführten Bereichs zueinander
finden. Ein Detail, das keine der beiden Prompts verlangt hat und das eine reine
Testsuiten-Bewertung nicht sichtbar macht.
Was das für die Modellwahl bedeutet
Bei klar abgegrenzten Logikfehlern zählt die Modellgröße kaum
Für einen in sich geschlossenen Bug in einer einzelnen Funktion, mit einem klar formulierten Report, hat in diesem Test das kleinste Modell (Haiku) genauso zuverlässig die eigentliche Ursache gefunden wie das größte (Opus). Für diese Art Aufgabe spricht das eher für das günstigere Modell.
Verifikation schlägt Selbstauskunft
Der einzige Fehlschlag im gesamten Test wäre bei reiner Modell-Selbstauskunft durchgerutscht: Sol hat behauptet, seine Lösung funktioniere, obwohl sie nicht einmal importierbar war. Ein Review, das nur die Zusammenfassung liest statt den Code auszuführen, hätte das nicht bemerkt.
Echte Differenzierung braucht vermutlich eine andere Fehlerklasse
Vier Stufen reiner Logikfehler in überschaubarem Code haben kein Modell wirklich ausgesiebt. Kandidaten für einen härteren Test wären eine über mehrere Dateien verteilte Ursache, ein Nebenläufigkeitsproblem oder eine Performance-Regression, die Tests auf Korrektheit gar nicht erfassen.
Wie zuverlässig ist Ihr eigener KI-Workflow wirklich?
Ich prüfe Modell- und Werkzeugauswahl an echtem Projektcode, mit echter Testsuite statt Bauchgefühl. 30 Minuten Erstgespräch, kostenlos.