Zwei Nächte A/B-Tests: Was lokale Dev-Modelle lehrten

Der erste Eintrag. Ein Laborbericht, kein Werbetext. Wir lassen lokale Sprachmodelle Software-Tickets abarbeiten und wollen wissen, was wirklich funktioniert. Die Kernfrage für diese Runde war einfach: Lohnt sich der „Thinking"-Modus des Entwickler-Modells? Zwei nächtliche A/B-Kampagnen auf dem NVIDIA DGX Spark haben uns klare Antworten und eine unbequeme Erkenntnis über die Grenzen kleiner Modelle gegeben.

Was wir versucht haben

Unser Setup ist eine strikte Pipeline. Jedes Ticket durchläuft drei Stufen: Das Entwickler-Modell (ein 27B-Reasoning-Modell, Qwopus) schreibt Code und Tests. Eine Sandbox führt die Tests aus. Ein unabhängiges QA-Gate („quinn", gleiches Basismodell, Thinking an) prüft das Ergebnis gegen die Akzeptanzkriterien.

Der „Thinking"-Modus bedeutet, dass das Modell vor der Antwort eine interne Denk-Kette erzeugt. Das kostet Zeit, soll aber Qualität bringen. Um das zu prüfen, haben wir in der Nacht auf den 23.07. die Kampagne K03 gefahren und direkt danach K04 als Validierung.

Was passierte: Die echten Zahlen

Baseline A: Thinking an

Als Ausgangslage diente eine echte Ticket-Kette von 5 Kleinst-Tickets für eine Web-App. Das Ergebnis war enttäuschend. Wir zählten 22 Entwickler-Versuche, im Schnitt 55 Minuten pro Versuch, rund 4 Stunden pro Ticket. 41 % der Versuche waren Leerläufe: Das Modell dachte rund 60 Minuten nach und lieferte am Ende Nichts. Zusammen verbrannte das Zeitbudget von 9,4 Stunden für reines Nachdenken ohne Ergebnis.

K03: Die Nacht-A/B-Kampagne

Wir fuhren K03 auf einer identischen 3-Ticket-Suite. Drei Kandidaten im Rennen:

• Kandidat B (nothink): Gleiches 27B-Modell mit abgeschaltetem Thinking. Ergebnis: 12,5 Minuten im Schnitt pro Versuch, NULL Leerläufe, die gleiche Trefferquote pro Versuch wie die Baseline.
• Kandidat C (30B-MoE): Ein kleineres, schnelleres Modell. Nur rund 3 Minuten pro Versuch, aber strukturell kaputt. Es lieferte teils gar keine lauffähigen Tests und Import-Fehler. Als Solo-Entwicklung war es zu schwach.
• Ergebnis: Beide Kandidaten schafften 1 von 3 Tickets.

Die Konsequenz am Morgen

Die Daten sprachen für sich. Wir stellten die Entwickler-Rolle produktiv auf nothink um und erhöhten das Versuchs-Budget von 3 auf 5. nothink-Versuche sind billig, also können wir es uns leisten, mehr zu werfen. Das QA-Gate behält Thinking bewusst bei – dort zahlt sich das Nachdenken aus.

K04: Validierung der neuen Config

Am selben Tag fuhren wir K04 mit der neuen Konfiguration. Die Ergebnisse bestätigten die Hypothesen, zeigten aber auch die harten Grenzen:

• Ticket t3: In K03 mit 2 Versuchen durchgefallen. In K04 ging es im ERSTEN Versuch durch. Das größere Budget fängt Streuung ab.
• Ticket t1: Eine komplette Web-App „from scratch" nach Originalauftrag. Scheiterte in JEDER Konfiguration. nothink mit 5 Versuchen (75 Minuten), nothink mit 4 Versuchen und sogar eine finale „Thinking-Reparatur-Runde" (48 Minuten) ließen exakt dieselben 3 Tests rot.

Das Problem bei t1 war nicht die Reasoning-Tiefe. Das From-scratch-Projekt war strukturell am Auftrag vorbei gebaut – nur 13 von 37 erwarteten Tests liefen überhaupt.

Lehren aus dem Labor

Aus den beiden Nächten und den Kampagnen-Daten ziehen wir vier klare Lehren. Ehrlichkeit geht vor.

1. Thinking kauft keine Qualität, sondern Wartezeit Bei einem 27B-Modell in der Entwickler-Rolle führt der Thinking-Modus zu Leerlauf-Ruminationen. Das Modell denkt sich fest, statt Code zu schreiben. Die 9,4 verbrannten Stunden in der Baseline waren reiner Zeitdiebstahl.

2. Mehr billige Versuche schlagen wenige teure Retry-Tiefe 5 rettet mittlere Tickets. Wie Ticket t3 in K04 zeigt, fängt ein größeres Budget an Versuchen die normale Streuung ab. Billige nothink-Versuche zu wiederholen, ist effektiver als teure, nachdenkliche Versuche.

3. Der Hebel liegt im Ticket-Zuschnitt, nicht in der Modell-Config Große From-scratch-Aufträge sind für diese Modellklasse unlösbar. Ticket t1 war ein strukturelles Desaster, egal welche Config wir wählten. Arbeit muss additiv in Kleinst-Tickets zerlegt werden, die auf bestehendem Code aufbauen. Wenn das Modell auf etwas aufbauen kann, funktioniert es. Wenn es von Null anlegen muss, verliert es den Faden.

4. (Meta) Automatisierung funktioniert Beide Kampagnen liefen vollautomatisch nachts durch (04:30-06:08 und 07:33-11:26), inklusive Selbst-Aufräumen. Wir haben die Firma genau dafür gebaut: Damit die Maschinen die Nachtschicht machen und wir am Morgen nur noch die Daten auswerten müssen.

Fehlschläge wie Ticket t1 sind kein Grund zur Verzweiflung, sondern Content für den nächsten Versuch. Wir wissen jetzt, wie wir die Tickets zuschneiden müssen. Nächste Nacht geht es weiter.