Source Authorship Forensics

Luna Chess Engine — was it written by a human or generated by AI?

A full-source investigation of github.com/spunc595/luna-chess-engine.

Author [redacted] (Spunc595) Language Rust (100%) Scope 11 files · ~2,500 LoC Analyzed 2026-07-09 Method source read + git history + build + runtime test
Verdict · AI-Generated — developer-confirmed

Essentially certain: the source was AI-authored, then published after an unchecked AI cleanup pass.

The code text was produced with an AI assistant — Google Gemini, per un-scrubbed citation markers — and published largely as-is. The architecture and chess logic were designed and directed by a chess-literate developer (every algorithm chosen is correct and standard); the visible debris entered during a late, unchecked AI cleanup-and-translation pass rather than careful hand-authorship. The developer has since publicly confirmed this account — see the update below.

Confidence: Very High — multiple independent, mutually corroborating proofs.

Update · 2026-07-09 · Developer response

The developer has publicly confirmed this analysis.

After the report circulated, the repository's author (“Spunc595”) responded publicly, accepted the verdict, and explained how it happened. Luna, he says, is a hobby passion project whose architecture and chess logic he designed himself. New to Rust, he used an AI assistant (Gemini) as a coding co-pilot — and, just before release, asked it to refactor his files and translate all his comments into fluent English. Working quickly through the GitHub web UI, he blindly copy-pasted those AI-“cleaned” outputs.

That final pass is where the debris came from: the [cite] markers, the conflicting version numbers, the orphaned uci.rs (an AI-refactored file he uploaded but never wired into main.rs), and the wrong “HalfKA” label (an AI boilerplate placeholder he failed to catch). Calling it “a massive, embarrassing lesson in repository hygiene,” he said he will wipe the repository, remove the dead code, and fix the warnings so it reflects the clean engine he intended.

Net: the forensic verdict holds, and the developer's candid account fills in the human side the artifacts alone couldn't show — he directed the design; an unchecked, last-minute AI cleanup produced the mess.

·Evidence at a glance

Nine signals, ranging from a literal copy-paste artifact to structural incoherence.

#SignalWhat it provesWeight
1147 leftover [cite: N] markers in commentsText pasted verbatim from a Gemini response, uncleanedSmoking gun
2Every commit is a GitHub-web "Add files via upload"No local development; files authored elsewhereStrong
3Orphaned duplicate uci.rs (never compiled)Files generated in isolation, never integratedStrong
4Four conflicting version numbersAssembled from separate generations, unreconciledStrong
5"HalfKA" label on a network that isn't HalfKALeftover AI placeholder that doesn't match the actual networkStrong
6Duplicated PST + Zobrist codeCopy-paste from separate promptsMedium
7Tutorial-grade comment on every trivial lineCharacteristic AI narration styleMedium
8Italian identifiers + fluent English commentsGeneration/translation layer, not one human handSupport
9Leftover Italian "todo" notes in cargo.tomlAssistant's paste-instructions left in verbatimSupport

1The smoking gun — leftover AI citation markers

The source contains 147 stray [cite: N] tags appended to code comments — an artifact of Gemini's grounded output. No human types [cite: 10] at the end of a Rust comment.

/// Periodically checks (every 2048 nodes) if time has run out.[cite: 10]

Each file carries its own citation number, indicating each was produced in a separate AI turn.

FileMarker countCitation #
src/tt.rs35[cite: 6]
src/search.rs32[cite: 10]
src/zobrist.rs27[cite: 12]
src/nnue.rs26[cite: 5]
src/evaluation.rs17[cite: 4]
src/uci.rs10[cite: 5]
Total147
Tell within a tell: src/book.rs has zero markers and a different comment voice (emoji, terser style) — likely a different session or the one lightly hand-edited file.

2Git history — no development, only uploads

All 30 commits were made through the GitHub web UI. Not one is a local commit from real coding — no incremental building, no bug-fix commits, no branches.

Commit message patternCountMeaning
"Add files via upload"4Bulk paste of generated files
"Delete X.rs"~15Wholesale file replacement
"Create / Update README.md"~7Web-UI text edits
"Update main.rs"1Single web-UI edit

3 · 4Incoherence — an orphan file and version chaos

src/uci.rs is a complete second UCI implementation that is never used: main.rs implements the loop inline and never declares mod uci;, so the file is excluded from compilation entirely. The two disagree on nearly every parameter.

Parametermain.rs (live)uci.rs (dead)
Engine nameLuna_Hybrid_7.2Luna 0.6 …HalfKA
Author string[redacted][redacted]
Default hash256 MB64 MB
Time mgmttime / 25time / 30
Default depth1264
Search modelsynchronousthreaded
LocationVersion
README.mdv1.0.0
src/main.rs7.2
src/uci.rs0.6
cargo.toml0.6.0

5 · 6A leftover placeholder label and copy-paste duplication

uci.rs advertises "NNUE HalfKA," but nnue.rs is a plain 768-input network (12 pieces × 64 squares) with no king-relative features. Real HalfKA is king-bucketed with ~45,000 features — the label is a leftover AI placeholder that was never corrected.

Duplicated itemCopy ACopy B
Piece-Square Tablesevaluation.rsmovegen.rs (verbatim)
Zobrist hash routineboard.rs::get_hashzobrist.rs::hash_board

Build result

It compiles cleanly — and the compiler independently confirms the dead-code findings.

Toolchain : rustc 1.97.0 (x86_64-pc-windows-msvc)
Command   : cargo build --release
Result    : SUCCESS — 0 errors, 8 warnings, 19.75s
Binary    : target/release/luna.exe (257,024 bytes)
#Compiler warningLocationConfirms
1method hash_board never usedzobrist.rs:62Duplicate Zobrist
2methods clear / new_search never usedtt.rs:53,63Dead TT "aging"
3methods conta_pezzi / genera_mosse unusedboard.rs:284,537Dead code
4field pst_val never readboard.rs:211Dead field
5variant Bound::None never constructedtt.rs:6Dead code
6fn OpeningBook::new never usedbook.rs:15Dead code
7value assigned to val never readevaluation.rs:108Sloppiness
8variable beta need not be mutablesearch.rs:156Sloppiness
Dead feature shipped in the README: tt.rs::new_search() — which bumps the generation counter for entry aging — is never called by the live binary. So the "Transposition Table with aging support" the README advertises does nothing; the generation stays at 1 forever.

Runtime test — does it actually play?

Fed a standard UCI handshake, the binary searches and returns a legal, sensible move. Despite the messy authorship, the engine genuinely works.

MetricResult
UCI handshakeOKreadyok returned
Search depth reached9 plies in ~1 second
Node rate~2.5 million nodes/sec
Best moveb1c3 (Nc3) — legal, sensible
PV legalityAll principal-variation lines legal
OverallFunctional — plays real chess
Startup banner (mixed Italian/English — another tell):
"NNUE: Attiva e carica!" · "Luna Engine v7.2 - Istruita Ready"

Bottom line

Human-conceived and human-directed; AI-authored source. A chess-literate developer designed the engine, used an AI (Gemini) to help implement it and then to "clean up" and translate it before release, and uploaded the output largely as-is. The algorithm choices are all correct and the binary compiles cleanly and plays legal chess — and the un-scrubbed citation tags, four conflicting version numbers, an orphaned source file, a dead advertised feature, and a leftover placeholder label all trace to that final, unchecked cleanup pass. The developer has since publicly confirmed this account and committed to cleaning up the repository.