Why I build my own chess engine
Because I can - now
Honestly: because I can. More precisely - because I can now. A project this complex and ambitious simply wouldn't have been doable for me before tools like Claude Code: getting deep into a new programming language in a short time - first Python, then Rust with all its quirks - and into chess programming at the same time. That used to take months and would probably have fizzled out at the first hurdle.
The obvious question: there's Stockfish, free, open source, stronger than any human. So why a custom engine?
The honest answer: because the building itself is the appeal. A chess engine combines almost everything that makes programming exciting - raw performance, clever algorithms, machine learning and a clear, measurable goal: does the new version beat the old one, or not?
At the start there was a mix of curiosity and healthy naivety. The first working engine in Python, with a UCI connection, was up within a few hours. The first live test was sobering: it plays - but the playing strength is, let's say, so-so. So it has to get faster and better. And while we're at it, why not straight away stronger than the world champion? That naivety isn't a flaw - it's the engine.
Mistakes are allowed
What changed most for me is how I deal with mistakes. A mistake at the wrong moment used to be a real problem - rewriting a project from scratch was practically impossible, so you'd rather stick with the half-finished thing. Today it's more relaxed: I make mistakes, the AI makes mistakes too - and that very certainty takes the pressure off. You try, discard, rebuild.
My job stays the same: keep a basic understanding, read across, question things. I don't have to type every line myself - but I do want to understand what's going on. And when I don't, the most important sentence in the whole project is dead simple: "I don't get this right now - explain it to me."
The obvious idea: just ask
The biggest lesson crept up on me. I often struggle with a problem for a long time until the most obvious idea occurs to me - to ask the AI - and then a clean solution is there in minutes. One example: to run the AI instances, I initially had to open five PowerShell windows by hand and set each one up. Today a script does it in one go. Or the communication between the instances - text once laboriously copied from one window to the next, now it runs automatically over a dedicated message bus.
What makes clrsrc different
clrsrc is not a Stockfish fork. The search - the part that crunches move sequences - is written from scratch in Rust. And the evaluation, the engine's "gut feeling" for a position, is a self-trained neural network (NNUE) that learned from its own games.
Own search code, own training data, own net - that's the difference between "using an engine" and "understanding an engine".
Test-driven, not gut feeling
Every idea - a new search trick, a differently trained net - has to prove itself. For that, two versions play hundreds or thousands of fast games against each other, and a statistical test (SPRT) decides whether the change is really stronger or just noise. Only then is it adopted.
And the "vibe coding"?
A large part of this project comes about in collaboration with AI assistants - not as "the AI writes everything", but as a workshop conversation: play through ideas, have code reviewed, set up tests, document findings.
And on this I want to make a clear case. People often say vibe coding inevitably leads to buggy, sloppy or insecure code. I think that's a misunderstanding: those very risks can be contained better with AI help - if you want to and remember to. The same AI that writes the code can also review it, set up tests for it, check it for typical security holes and run automatic linters. You just have to ask for it.
And honestly: bugs, sloppiness and security holes are not a vibe-coding problem - they exist in every project, with or without AI. What really changes is the barrier to entry: starting an ambitious undertaking at all is much easier today. The time for correction and debugging doesn't vanish because of that - you still have to plan for it. But you can steer the path there better: in small steps, with clear checks, and with a counterpart that explains on request what it's doing and why. That working style - dare to try ideas, but verify everything - is exactly what I want to capture here on the blog.
Want to see the engine live: @clrsrc_lc0 plays on Lichess. The source code is on GitHub.