Teil 1: Wie ich versehentlich ein Framework baute
Prolog: Eine Frage, die alles in Gang setzte
Seit meiner Entdeckung von ChatGPT war ich von den Möglichkeiten, die mir KI-Systeme beim Texten und Recherchieren gaben, regelrecht geflasht. Von da an nutzte ich KI-Assistenz beinahe täglich. Früh entdeckte ich die Vorzüge von Perplexity bei der täglichen Recherche, ChatGPT bei der Formulierung und Überarbeitung von Webtexten, BlackboxAI im Rahmen meiner Webentwicklung mit dem CMS Drupal. Doch so richtig begann meine Begeisterung für diese abstrakte Entität mit einer naiven Frage: Wie weit kann man ihr trauen? Wie sehr kann man sich auf sie verlassen? Wie weit kann ich sie belasten?
Von synthetischen Benchmarks, mit denen man die Leistung von LLMs bewertet, wusste ich zu diesem Zeitpunkt noch nichts – und ich wollte es auch gar nicht wissen. Mich interessierte keine Mathe-Olympiade, kein Essay über Kant. Ich hatte KI im Rahmen meiner Arbeit als UX- und Frontend-Designer entdeckt und wollte deshalb wissen, ob sie mir meine Arbeit wirklich erleichtert. Oder ob sie mir nur zusätzlichen Korrekturaufwand auferlegt. Der Zweifel blieb.
Die eigentliche Frage war konkreter: Kann ich dem Ding vertrauen, wenn ich es um Mitternacht Produktionsprobleme lösen lasse? Beantwortet es mir in dreißig Sekunden, wie ich einen Symlink setze, einen Docker-Container deploye, einen alias persistent in .zshrc verankere – oder dreht es sich in seitenlangen Outputs im Kreis, die nach viel aussehen und wenig liefern?
Aber da war noch etwas anderes. Als UX- und Frontend-Designer arbeite ich seit Jahren eng mit Entwicklern zusammen – ich kenne den Aufwand, ich kenne die Abhängigkeiten, und ich kenne die Momente, in denen ich Layouts vereinfachen musste, weil die Ressourcen fehlten, eine simple JavaScript-Funktionalität umzusetzen. KI war für mich von Anfang an auch das: die Chance, in Bereiche vorzudringen, die mir bisher verschlossen waren. Nicht durch lernen, sondern durch Machen.
Das war mein Ausgangspunkt. Kein Forschungsprojekt. Kein geplantes Framework. Ein Experiment, getrieben durch Zweifel – und durch die leise Hoffnung, dass sich meine Fähigkeiten dadurch wirklich erweitern lassen.
Und das Experiment hatte eigentlich ein klar definiertes Ende: Ich würde es testen, meine Antwort bekommen und fertig.
Aber es kam anders.
Phase 1: Der erste Benchmark – und was er zeigte
Die frühen Tests waren schlicht. Lokale Modelle via Ollama auf meiner Consumer-Hardware – dass es neben den großen kommerziellen Diensten auch offene Modelle für den Betrieb zu Hause gab, passte perfekt zu meiner Begeisterung für Open Source. Der Schlüssel hieß Ollama, und ich werde an anderer Stelle noch ausführlicher über meine Erfahrungen damit schreiben. Begeistert installierte ich die lokalen Versionen großer Namen: Llama, DeepSeek, Qwen, Mistral. Doch welches Modell in welcher Größe für welchen Zweck? Gab es eines für alles – oder brauchte ich verschiedene für verschiedene Aufgaben? Und ab wann schlug der Zeitfaktor für die Antwortgenerierung den eigentlichen Nutzen?
Ich erstellte eine Handvoll manuell zusammengestellter Aufgaben aus meinem echten Arbeitsalltag. Kein ausgefeiltes Scoring, kein Judge, kein Leaderboard. Nur: tut es, was ich sage?
Die Ergebnisse waren ernüchternd und faszinierend zugleich. Modelle, die in öffentlichen Benchmarks brillierten, scheiterten an fundamentalen CLI-Aufgaben. Andere, die niemand auf dem Radar hatte – Ministral zum Beispiel –, lieferten verlässlich und schnell. Ich hatte bis dahin noch nie von Ministral gehört. Das änderte sich. Das erste echte Aha-Erlebnis war überraschend simpel: Die Metriken, nach denen die KI-Industrie Modelle bewertet, haben mit meiner Arbeit kaum etwas zu tun.
Später lernte ich, dass es dafür einen Namen gibt: Goodhart's Law – wenn ein Messwert zum Ziel wird, hört er auf, ein gutes Maß zu sein. Ob Pferdestärken, Prozessorleistung oder Megapixel – Benchmark-Ergebnisse werden im Marketing gerne als Qualitätsbeweis verkauft, obwohl sie oft synthetische Szenarien messen, die in meiner täglichen Arbeit nicht vorkommen. DeepSeek V3.2 war das früheste dokumentierte Beispiel in meinem Setup: akademisch stark, in der Praxis 27 Timeouts bei 43 Tasks.
Und statt mein Experiment hier abzuschließen, schrieb ich die ersten echten Test-Assets.
Phase 2: Der Schmelztiegel entsteht
Der Name CrucibleMark kam nicht zufällig. Da LLMs für mich irgendwie theoretischen Blackboxen ähnelten, wollte ich sie von allen Seiten beleuchten, belasten und an ihre Grenzen bringen – um sie besser zu verstehen. In einem Schmelztiegel (engl. Crucible) werden Materialien erhitzt und unter Druck getestet, um sichtbar zu machen, was wirklich in ihnen steckt. Genau das wollte ich mit diesen Modellen tun: sie in einen kontrollierten Kontext legen und beobachten, wie sie sich verhalten – nicht in einer Prüfungssituation, sondern unter Arbeitsbedingungen.
Die Modularität entstand dabei erst später, nicht aus einem Plan, sondern anhand des Bedarfs. Zuerst Code Quality. Später auch CLI Operations. Dann Logical Reasoning, weil ich schnell merkte, dass es einen Unterschied gibt zwischen einem Modell, das den richtigen Befehl kennt, und einem, das versteht warum der Befehl richtig ist. Dann UX Writing, weil ich im Rahmen meiner Tätigkeit täglich Microcopy schreibe und wissen wollte, welches Modell mich dabei wirklich unterstützen kann – und welches nur so tut als ob.
Das Framework wuchs nicht nach einem Masterplan. Es wuchs nach den Fragen, die die Arbeit stellte. Und mit jeder neuen Frage merkte ich: Ich stelle sie bereits anders als noch vor ein paar Wochen.
Phase 3: Das Regex-Problem und der große Bruch
Irgendwo zwischen dem dritten und vierten Modul begann die Grenze des regelbasierten Scorings sichtbar zu werden.
Das ursprüngliche Bewertungssystem kombinierte Keyword-Matching, Regex-Prüfungen und semantische Ähnlichkeitsanalyse. Es war präzise für strukturierte Outputs – Tabellen, Codesegmente, CLI-Antworten mit klarem Richtig-oder-Falsch. Aber es war blind für Qualität und musste bei jedem neuen Modell manuell nachjustiert werden – ein Wartungsaufwand, der mit wachsendem Modell-Pool nicht mehr skalierte. Ein Modell, das technisch alle Keywords traf und trotzdem Nonsense produzierte, bekam einen guten Score. Ein Modell, das die Aufgabe elegant löste, aber anderen Worten wählte, wurde bestraft.
Hermes 3 war das erste Modell, das dieses Problem scharf stellte. Der regelbasierte Scorer hatte es lange positiv bewertet – zu positiv, wie sich herausstellte. CLI-Tasks mit klarer Input-Output-Struktur: 82,7 Punkte. Reasoning über mehrere Denkschritte: 51,3 Punkte. Der Unterschied war da – aber das Scoring-System sah ihn nicht vollständig.
Die Lösung war konzeptuell klar, sobald ich die Frage einmal formuliert hatte: Was, wenn ein zweites, unabhängiges Sprachmodell die Antworten bewertet? Es liest die originale Aufgabe, die Antwort des getesteten Modells und einen Golden Standard – der die ideale Referenzantwort abbildet – und vergibt einen Score mit verpflichtender Begründung. Chain of Thought vor dem Score, nicht danach – eine Erkenntnis, die ich nicht selbst ausgedacht hatte, sondern aus der Forschung lernte. Zum ersten Mal recherchierte ich nicht für einen Text, sondern für ein System.
Das war der Bruch. Der Wechsel vom regelbasierten Hybrid-Scorer zum LLM-as-a-Judge-System.
Die Nacht, in der das Framework entstand
Was in der Theorie einfach klang, war in der Implementierung ein komplexes Engineering-Problem. Und hier passierte etwas, das ich nicht erwartet hatte: Die Zusammenarbeit mit einem KI-Agenten – Claude Sonnet im Agentic Mode – transformierte den Prozess fundamental.
Das Anforderungsdokument entstand in einem langen Gespräch mit Perplexity, die mir als Brainstorming- und Rechercheassistenz sehr wichtig geworden ist. Das Gespräch drehte sich nicht um Implementierungsdetails, sondern um Architektur-Prinzipien, Risiken, Design-Entscheidungen. Die unbequemen Fragen: Was passiert, wenn Judge und getestetes Modell gleichzeitig im RAM liegen? Was passiert bei einem API-Timeout mitten in einem Overnight-Benchmark? Und welche Daten bekommt ein Cloud-Judge eigentlich zu sehen – und was passiert damit? Dass ein Modell wie Claude Haiku als Judge die Outputs seiner Konkurrenten bewertet, ist nicht nur eine Datenschutzfrage. Es ist eine, die ich erst später vollständig durchdacht habe: Was, wenn der Richter aus dem, was er sieht, selbst lernt?
Diese Fragen entstammen nicht einer Spezifikation. Sie entstammen Erfahrung – und wachsender Neugier.
Am nächsten Tag begann ein für mich wegweisendes Experiment: Auf Basis des Anforderungsdokuments schätzte ich den ungefähren Aufwand, den ein Entwickler für die Implementierung benötigt hätte – in Zeit und Geld. Der regionale Stundensatz für freie Entwickler war schnell ermittelt. Das fertige Dokument übergab ich anschließend an GitHub Copilot in VS Code, mit Claude Sonnet 4.6 im Agentenmodus. 15 Minuten später: 15 neue Dateien. 5 modifizierte Dateien. 35 neue Tests. Alle grün. Nach weiteren drei Stunden Feinjustierung lief der Judge. Ein erfahrener Senior Developer hätte für denselben Umfang realistisch 6–8 Arbeitstage benötigt.
Der Preis für die gesamte Implementierung des Judge-Moduls: 2,08 Dollar.
Das ist keine Übertreibung. Das war der Moment, in dem ich verstand, womit ich es hier zu tun hatte. Und er erklärt, warum aus einem kleinen Experiment ein Framework wurde, das mich monatelang – manchmal beinahe obsessiv – beschäftigte. Die Produktivitätsexplosion machte Dinge machbar, die ich vorher alleine nie angegangen wäre. Und es passierte etwas, das ich so nicht auf dem Zettel hatte: Das Werkzeug, das ich gebaut hatte um Fragen zu beantworten, erzeugte schneller neue Fragen als ich alte beantworten konnte. Je mehr das Framework leistete, desto mehr wollte ich testen. Je mehr ich testete, desto deutlicher wurde, was noch fehlte. Aus dem Test wurde ein Projekt – ich hatte es nur noch nicht bemerkt.
Sättigung als nächstes Problem
Mit einem funktionierenden Judge-System und einem wachsenden Modell-Pool stellte sich die nächste strategische Frage fast von selbst: Was passiert, wenn alle Modelle irgendwann bei 95% oder darüber landen? Dann wird der Benchmark zu glatt, zu bequem, zu leicht zu überlisten. Er verliert seine Trennschärfe, seine „Discriminative Power", wie ich inzwischen gelernt hatte.
Die Diskussion darüber führte ich nebenbei mit verschiedenen KI-Assistenten, was an sich schon wieder ein Meta-Kommentar auf das ganze Experiment war. Die Richtung war klar: nicht global härten, sondern modular. Nicht alle Modelle mit denselben schwereren Aufgaben überfordern, sondern die Schraube gezielt anziehen. Der erste Hebel lag auf der Hand: den Judge-Prompt strenger machen und den besten Judge für diesen Zweck ermitteln. Ein pedantischerer Richter drückt die Scores aller Modelle gleichmäßig nach unten, ohne dass auch nur eine einzige neue Frage geschrieben werden muss. Also begann das eigentliche Justieren.
Am Ende stand ein Framework, das weit über den ursprünglichen Plan hinausgewachsen war: sieben Module, ein hybrides Scoring-System, das Instruction- und Reasoning-Score getrennt ermittelt; ein LLM-Judge mit Provider-Abstraktion; ein Leaderboard mit 61 getesteten Modellen in drei Kategorien. Version 3.5.9. Pylint-Durchschnitt 9,15 von 10.
Was als Experiment begonnen hatte, war zu einem Werkzeug geworden. Und ich merkte irgendwann, dass nicht nur das Framework gewachsen war. Aus dem UX-Designer, der das alles aus Neugier begonnen hatte, war jemand geworden, der dieses System nicht mehr bloß bediente, sondern immer besser verstand, immer präziser formte und mit jeder Iteration ein Stück weiter mit ihm wuchs. Am Ende war ich nicht nur der Beobachter des Ganzen, sondern sein Architekt geworden. Aber das Interessanteste stand mir noch bevor.