Source Authorship Forensics

Rudim — human-written, or AI-generated?

A source-level read of znxftw/rudim v3.0.5, contrasted with Stockfish — and with the AI-generated Luna engine as a control.

Author Vishnu Bhagyanath (znxftw) Language Rust Scope ~8,600 LoC · 605 commits · 20 releases Strength ~2,600 CCRL Analyzed 2026-07-10 Method source read + git history + release/testing signals Stockfish similarity Strong →
Verdict · Human-Written

A legitimate, iteratively-developed engine in the Stockfish tradition.

Every signal that marks a repository as AI-dumped is absent here; in its place is the unmistakable fingerprint of expert, test-driven, incremental engine development — 605 local commits, Elo-measured releases, a trained network, and code that shows genuine engineering depth. The author documents the work on his own dev blog and runs it as rudim-bot on Lichess.

The only AI involvement is disclosed, bounded, and human-supervised: a Copilot account authored 4 of 605 commits as reviewed pull requests, and Dependabot bumps dependencies — an assistant on discrete tasks, not the author of the codebase.

Confidence: High — process history and code substance agree.

Companion piece: this is the same forensic lens applied in the Luna engine analysis — a repository that was AI-generated. Rudim is effectively the control group: what real human engine engineering looks like, in the repo and in the code.

·Evidence at a glance

Signals of authentic human authorship, strongest first.

#SignalWhat it showsWeight
1605 local commits with conventional prefixes (feat:/fix:/optz:)Sustained, disciplined, incremental developmentDecisive
2Commits are SPRT-style one-idea patches; releases quote Elo deltasA real test-driven engine-tuning workflow — cannot be fakedDecisive
3Truly incremental NNUE accumulator (add_1_sub_1, add_1_sub_2, add_2_sub_2)Deep understanding of NNUE engineering, not a plausible facsimileDecisive
4Own training infra: deps/bullet submodule, datagen.rs, train.rs, a networks repoThe author trained the net he shipsStrong
5// TODO: tune notes throughout the searchA human's working shorthand mid-experimentStrong
6Real tests, benchmarks, multi-job CI, named human contributorsMaintained software project, not a one-shot uploadStrong
7Zero [cite:] markers or other AI residueNo un-scrubbed generated textSupport

1The development process

The git history is the clearest tell. Placed beside Luna, the contrast is total.

DimensionLuna (AI-generated)Rudim (human)
Commits30, all GitHub-web "Add files via upload"605, local, conventional-commit discipline
Commit contentwholesale file replacementone-idea patches: "history maluses", "gravity history", "refine NMP conditions", "add_2_sub_2 accumulator for castling"
Releasesversions that contradict each other20 tags, each with measured Elo gain (e.g. +61.4 Elo v3.0.5 vs v3.0.4)
AI residue147 [cite:] markersnone
Contributorsone handlenamed author + human contributors + disclosed bots
Dead codeorphaned uci.rs, dead "aging"clean modular tree, real tests/ & benches/

2The code itself — two tells no AI first-draft produces

Metadata can be staged; substance is harder. Two things stand out.

(a) Tuning notes in the hot path. The search is dotted with // TODO: tune beside pruning margins (reverse-futility, futility, NMP conditions). That's the working shorthand of someone running tuning experiments one parameter at a time — not explanatory prose an assistant emits.

(b) A genuinely incremental NNUE accumulator. Rudim implements the full efficient-update family on a cache-aligned accumulator — the reason NNUE is called efficiently updatable:

#[repr(C, align(64))]
pub struct Accumulator { pub state: [i16; ACC_SIZE] }

add_1_sub_1(add, remove, net)          // quiet move: 1 piece leaves, 1 arrives
add_1_sub_2(add, rem1, rem2, net)      // capture:    mover arrives, 2 removed
add_2_sub_2(a1, a2, r1, r2, net)       // castling:   king + rook both move
The decisive contrast with Luna: Luna recomputed the entire accumulator from scratch on every evaluation, looping over all pieces — the naive placeholder an AI produces when it recognizes the shape of NNUE but not the engineering. Rudim does true per-move-type incremental updates, exactly as Stockfish does. That difference is the difference between understanding NNUE and imitating it.

3Compare & contrast with Stockfish

Rudim shares Stockfish's DNA and culture, at a solo-developer scale.

Where it resembles Stockfish
Modern search: ID + aspiration, PVS, LMR, NMP, futility / reverse-futility, check extensions, quiescence, two-tier TT
Move ordering: SEE, MVV-LVA, killers, history (gravity + maluses), counter-moves, hash/PV
Incremental NNUE accumulator with per-move-type updates
SPRT / Elo-driven development (the Fishtest ethos)
Magic bitboards, Zobrist hashing, perft tests
Where it differs (scale, not authenticity)
Rust, ~8.6k LoC, one primary author vs C++, hundreds of contributors over decades
Relies on compiler auto-vectorization (native/AVX2) vs hand-written AVX2/AVX-512/NEON intrinsics
Compact (768→256)×2→1 perspective net vs bucketed HalfKAv2_hm
~2,600 CCRL vs the strongest engine in the world (~3,600+)

None of the differences bear on authorship — they're the expected gap between a talented individual's project and a decades-long collective effort. What matters is that rudim is built the way real engines are built.

Bottom line

Rudim is a legitimate, human-authored competitive chess engine in the Stockfish tradition — the same algorithmic toolkit and the same test-driven culture, scaled down to one talented developer, with normal, disclosed AI/bot assistance on the margins. If Luna was the cautionary tale of AI output pasted unreviewed, rudim is the counterexample: authentic human engine engineering, visible in both the repository's history and the substance of its code.