Crustik — human-written, or AI-generated?

·Evidence at a glance

Signals of authentic human authorship, strongest first.

1The code has a sense of humour

The single clearest tell is texture no language model produces: jokes and dead experiments left lying around.

// eval.c
// #define ILLEGALMOVE 42 // Answer to the universe

// static uint8_t penaltymap[64] = { 1, 2, 3, 4, ... };   // abandoned experiment, left in

#include "stdio.h"
#include <stdio.h>                                        // included twice — nobody cleaned it up

2The engineering is real, and classical

Underneath the jokes is competent, hand-written engine code — currently a classical evaluation, not NNUE.

The search (search.c, ~1,100 lines) carries the modern move-ordering toolkit: killers, counter-moves, a main history table, capture history, and a pawn-history heuristic bucketed by pawn structure, plus a transposition table, three-fold detection, and a splitmix64 hash mixer. The evaluation (eval.c) is a tapered mid/endgame scheme built on the community-standard PeSTO values and piece-square tables:

int mg_value[6] = { 82, 337, 365, 477, 1025, 0 };   // PeSTO middlegame values
int eg_value[6] = { 94, 281, 297, 512,  936, 0 };   // PeSTO endgame values

NNUE is a stated future goal in the DEVBLOG, and datagen.c already exists to generate self-play training data — the classic classical → NNUE journey that most hobby engines walk. Move generation uses magic bitboards (the 100k-line rook_table.h is generated attack data, not authored code, which is why the raw line count looks enormous).

3Compare & contrast with Stockfish

Crustik shares Stockfish's classical lineage and testing culture, at an early solo-hobby stage.