Warum ich eine eigene Schach-Engine baue
Weil ich es kann - jetzt
Ehrlich gesagt: weil ich es kann. Genauer - weil ich es jetzt kann. Ein so komplexes, ambitioniertes Projekt wäre für mich vor Werkzeugen wie Claude Code schlicht nicht machbar gewesen: sich in kurzer Zeit so tief in eine neue Programmiersprache einzuarbeiten - erst Python, dann Rust mitsamt seinen Eigenheiten - und gleichzeitig ins Thema Schachprogrammierung. Das hätte früher Monate gekostet und wäre wohl an der ersten Hürde versandet.
Die naheliegende Frage: Es gibt Stockfish, kostenlos, open source, stärker als jeder Mensch. Warum also eine eigene Engine?
Die ehrliche Antwort: weil das Bauen selbst der Reiz ist. Eine Schach-Engine vereint fast alles, was Programmieren spannend macht - knallharte Performance, clevere Algorithmen, maschinelles Lernen und ein klares, messbares Ziel: Gewinnt die neue Version gegen die alte, oder nicht?
Am Anfang stand eine Mischung aus Neugier und gesunder Naivität. Die erste funktionsfähige Engine in Python, mit UCI-Anbindung, stand nach wenigen Stunden. Der erste Live-Test war dann ernüchternd: Sie spielt - aber die Spielstärke ist, sagen wir, solala. Also muss sie schneller werden und besser. Und wenn schon, warum nicht gleich besser als der Weltmeister? Diese Naivität ist kein Fehler - sie ist der Motor.
Fehler dürfen sein
Am meisten verändert hat sich für mich der Umgang mit Fehlern. Früher war ein Fehler im falschen Moment ein echtes Problem - ein Projekt komplett umzuschreiben war praktisch unmöglich, also blieb man lieber beim Halbfertigen. Heute ist das entspannter: Ich mache Fehler, die KI macht auch Fehler - und gerade diese Gewissheit nimmt den Druck heraus. Man probiert, verwirft, baut neu.
Meine Aufgabe bleibt dieselbe: Grundverständnis behalten, querlesen, in Frage stellen. Ich muss nicht jede Zeile selbst tippen - aber ich will verstehen, was da passiert. Und wenn ich es nicht verstehe, ist der wichtigste Satz im ganzen Projekt ganz simpel: „Das verstehe ich gerade nicht - erklär es mir."
Die naheliegende Idee: einfach fragen
Die größte Lektion kam schleichend. Oft mühe ich mich lange mit einem Problem ab, bis mir die naheliegendste Idee kommt - die KI zu fragen - und dann steht in Minuten eine saubere Lösung. Ein Beispiel: Für die KI-Instanzen musste ich anfangs fünf PowerShell-Fenster von Hand öffnen und einzeln einrichten. Heute erledigt das ein Skript auf einen Schlag. Oder die Verständigung zwischen den Instanzen - früher Texte mühsam von einem Fenster ins nächste kopiert, heute läuft sie automatisch über einen eigenen Nachrichten-Bus.
Was clrsrc ausmacht
clrsrc ist kein Stockfish-Fork. Die Suche - der Teil, der Zugfolgen durchrechnet - ist von Grund auf in Rust geschrieben. Und die Bewertung, also das „Bauchgefühl" der Engine für eine Stellung, ist ein selbst trainiertes neuronales Netz (NNUE), das auf eigenen Partien gelernt hat.
Eigener Such-Code, eigene Trainingsdaten, eigenes Netz - das ist der Unterschied zwischen „eine Engine benutzen" und „eine Engine verstehen".
Testgetrieben statt Bauchgefühl
Jede Idee - ein neuer Suchtrick, ein anders trainiertes Netz - muss sich beweisen. Dafür spielen zwei Versionen hunderte oder tausende schnelle Partien gegeneinander, und ein statistischer Test (SPRT) entscheidet, ob die Änderung wirklich stärker ist oder nur Zufall war. Erst dann wird sie übernommen.
Und das „Vibe Coding"?
Ein großer Teil dieses Projekts entsteht im Zusammenspiel mit KI-Assistenten - nicht als „die KI schreibt alles", sondern als Werkstattgespräch: Ideen durchspielen, Code gegenlesen lassen, Tests aufsetzen, Befunde dokumentieren.
Dafür will ich ausdrücklich eine Lanze brechen. Oft heißt es, Vibe Coding führe zwangsläufig zu fehlerhaftem, unsauberem oder unsicherem Code. Das halte ich für ein Missverständnis: Genau diese Risiken lassen sich mit KI-Hilfe sogar besser eingrenzen - wenn man es denn will und daran denkt. Dieselbe KI, die den Code schreibt, kann ihn auch gegenlesen, Tests dazu aufsetzen, auf typische Sicherheitslücken prüfen und automatische Prüfwerkzeuge durchlaufen lassen. Man muss es nur einfordern.
Und ehrlich: Fehler, Schludrigkeit und Sicherheitslücken sind kein Vibe-Coding-Problem - die gibt es in jedem Projekt, ob mit KI oder ohne. Was sich wirklich ändert, ist die Einstiegsschwelle: Ein ambitioniertes Vorhaben überhaupt anzufangen ist heute viel leichter. Die Zeit fürs Korrigieren und Debuggen verschwindet deshalb nicht - die muss man weiterhin einplanen. Aber man kann den Weg dorthin besser steuern: in kleinen Schritten, mit klaren Prüfungen und mit einem Gegenüber, das auf Nachfrage erklärt, was es gerade tut und warum. Genau diese Arbeitsweise - Ideen wagen, aber alles überprüfen - will ich hier im Blog festhalten.
Wer die Engine live sehen will: @clrsrc_lc0 spielt auf Lichess. Der Quellcode liegt auf GitHub.