Stories: Original editorial work

Did AI Build the World's Strongest Gomoku Engine? Not Until We Read the Logs
English Content ExperimentPublished translation

Did AI Build the World's Strongest Gomoku Engine? Not Until We Read the Logs

July 20, 2026About 4 min112
디버깅생성형AI실험알파고오목평가환경AIDevSnack AI LabLLMMinimaxRapfi
A digital scene of two AI entities playing Gomoku on a holographic board

Did AI Build the World's Strongest Gomoku Engine? Not Until We Read the Logs

I asked AI to build a Gomoku engine.

It completed a 780-line Minimax engine in just one hour.

Then I made it play against Rapfi, one of the strongest Gomoku engines in existence.

The result was too perfect to believe.


Continued from Part 1

Part 1 established one fact: an LLM by itself is not good at playing Gomoku. It has to read the board as text, and it lacks search algorithms such as Alpha-Beta or MCTS. The result was not surprising.

But I decided to change the question:

If generative AI cannot play Gomoku well, can it build an engine that can?

What happens if AI becomes the developer instead of the player?


1. AI Built the Engine

A digital illustration of AI programming a Gomoku engine

I asked Deepseek v4 Flash to build a Python Gomoku engine using Alpha-Beta Pruning and Iterative Deepening.

In about one hour, it produced a working Minimax engine.

The code structure was cleaner than I expected. It was time to play against Rapfi.

2. First Test — The Result Was Too Perfect

The opponent was Rapfi, one of the strongest open-source Gomoku engines. It uses Alpha-Beta plus NNUE, a neural-network evaluation function, and plays at professional level.

Environment: 15×15 board, black Minimax at depth 4 with a 10-second limit, white Rapfi with a 10-second limit, five games.

Game 1 : Win
Game 2 : Win
Game 3 : Win

Minimax 3–0. It had swept Rapfi.

For a moment, I thought I had built something extraordinary. But it did not make sense. Rapfi is a top engine; a simple pattern evaluator with depth-4 search should not beat it. I checked the logs before trusting the result.

3. First Problem — NNUE Was Disabled

The logs showed that Rapfi had not loaded its NNUE weights.

The cause was the file-format handling in the AI-generated code. Rapfi can decompress LZ4 internally, but the code treated the file as a normal compressed archive and decompressed it in advance. Rapfi then tried to decompress it again, failed, and ran with NNUE disabled.

Without NNUE, Rapfi falls back to a classical evaluation function. Its playing strength had dropped significantly.

Request a fix → AI edits the code → run the match again.

Game 1 : Win
Game 2 : Win
Game 3 : Lose

Minimax won 2–1. It was still ahead. Something was still wrong.

4. Second Problem — The Ghost Stone

A ghost stone floating over a Gomoku board with a red debugging error marker

The logs contained another suspicious pattern:

Rapfi played invalid move G8
Rapfi played invalid move J8
Rapfi played invalid move K7

Rapfi appeared to play on occupied positions. At first I suspected a Rapfi bug. Following the logs led to my own engine instead.

I showed the logs to the AI and asked it to find the cause.

The cause was missing timeout cleanup.

Minimax's Alpha-Beta search places a stone virtually, then removes it while searching:

for row, col in moves:
    board.grid[row][col] = color
    value = self._alpha_beta(...)
    board.grid[row][col] = Board.EMPTY    # not executed after timeout

When a timeout exception occurred, Board.EMPTY was never executed and the stone remained on the board forever. Because of this ghost stone, Rapfi made a legal move, but the Python board already contained a stone there and reported an "invalid move." Rapfi was unfairly marked as the loser.

The AI found the cause and fixed the code itself. The solution was three lines:

try:
    value = self._alpha_beta(...)
finally:
    board.grid[row][col] = Board.EMPTY

Request a fix → AI edits the code → run the match again.

5. The Proper Result

At last, the normal result appeared.

Minimax (depth 4, 10 seconds) vs Rapfi (NNUE, 10 seconds) — five games

GameWinnerTurnsNote
1Rapfi22L5 five-in-a-row
2Rapfi22Same sequence
3Rapfi22
4Rapfi22
5Rapfi22
TotalRapfi 5–022 turnsInvalid moves: 0

Minimax was deterministic because its random seed was fixed, so all five games followed the same sequence.

Turn  1: ● Minimax  H8
Turn  2: ○ Rapfi    G7  [5.0s]
...
Turn 22: ○ Rapfi    L5  [5.0s] 5-in-a-row!

6. Summary

StageStatusResultCause
Stage 1Rapfi NNUE disabledMinimax 3–0AI-generated LZ4 handling
Stage 2Ghost-stone bugMinimax 2–1Missing timeout cleanup in AI-generated code
Stage 3All bugs fixedRapfi 5–0Correct result

AI implemented the normal code path quickly. But edge cases such as file-format compatibility and exception cleanup required a human to inspect the environment and logs with it.

When a result looks too good, inspect the environment.

If performance suddenly doubles, a developer's first thought should not be "Am I a genius?" It should be "Did something break?" This experiment made that habit feel concrete.

7. The Real Start

Now the task is no longer fixing bugs. It is time to make the engine stronger.

Can the AI-built Gomoku engine win even one game against Rapfi?

That experiment continues in the next part.


Experimental engine: Deepseek v4 Flash (OpenCode)
Opponent engine: Rapfi by dhbloo (github.com/dhbloo/rapfi)
Hardware: NVIDIA DGX Spark (ARM64, Grace ARM CPU, 128GB RAM)
Full code: planned for a future open-source release
DevSnack AI Lab — not a channel that merely consumes AI, but a lab that experiments with it. Failures and iterations are recorded too.

This English page is part of DevSnack's English Content SEO/GEO Experiment. The Korean source remains the canonical editorial origin for this pilot.

Open the Korean source →