Puzzle-oriented programming
I was involved in playing1 thinky puzzle games some time ago. It affected me so much that even my meme phrase “Tech Battle Advanced” was borrowed from Icely.
A good rule among puzzle designers is this:
A good puzzle should have a unique solution.
Yesterday, I was asking Deepseek and omp to build a IRCv3 server out of whatever.
The first Zig version worked. When I asked it to port the Zig code to Civet, the ported version no longer worked. Some information must be lost in translation.
Other than discovering a new CAP theorem…

That’s when I realized that, wait, we do not actually need to provide the computer a program. We only need to provide it a puzzle whose solution is a program.
“In theory”
To show you what I mean, here are the IRCv3 extensions we need to provide in order for the IRCv3 server to be feature-complete:
- TK
- TK
Our job as a puzzle-oriented programmer is to encode the facts above as a machine-readable puzzle, so the machine can verify a solution that it finds.
If we want to be lawful, we must add additional constraints so that the solution the machine finds is unique.
Even if we don’t, any solution found by the solver is still to-spec. We shall call this still very much defined behavior.
“In practice”
> time python solver.py
[TK: big number] solutions found.
Report generated: TK.html
[TK: timing info]
Excellent! This is the Enterprise-grade AI solution we need!
This biblically correct heisen-to-spec is now reachable at irc.1a-insec.net. Feel free to play with it! Please don’t spam :)
For more information, read its source code.
I also tried to make one, to no avail.↩︎