ENG | Gomoku (Piškovrky) vibe coding

Can Claude Code write Gomoku?

TL;DR: no.

I tried to write Gomoku / Five-in-a-row / Piškovrky game, which used to be very popular at school during 90s and before entirely using vibe coding using paid Claude code. Not editing a single line of code and trying not to read and understand it … where I failed and I started to get curious and eventually tried to ask about details or question generated code.

My idea was to make architecture with separate server (stores state, verifies moves, talks to two client), client (ncurses text UI, SDL3 + ImGui later) and bot.

Surprisingly after some chat about architecture (in web interface) claude generated 10 project files which I downloaded, reconstructed code structure and compiled. At this point it was just server and bots with different weights. Git repository and installation of claude code in isolated development environment started.

What was the result? In very few iteration I got two bots playing against each other, logging moves to text file and replay with option to view the moves. Matches curiously often ended up by a draw. So I instructed it to write ncurses client. Which it did. Somehow it contained all the functionality needed and it looked reasonable.

Project structure seemed ok. Text client was ok. Server was ok. However bot logic was not. It was quite decent at defense and making five from four or four from three. Nothing else. If it created fork, it failed to use it and was obsessed by blocking player’s/opponent’s two rather than completing own threes even if it had fork with winning move. I’ve spend few hours and maybe half of weekly token limit to make better. But it improvements were rather marginal. Maybe decreasing defensiveness helped slightly.

Conclusion: **As of February 2026, Claude Code / Opus 4.6 model can’t make gomoku.

After commit ++++++++, I pasted all bot source code files to ChatGPT. It said it can’t read files. So I recalled that year ago DeepSeek was rated as highly capable model. However at that time it was always overloaded. It was able to spot some possible errors.

Then I said

> I feel like with defense 0.7 it's not so bad, but it's somehow obsessed with creating or blocking two

….

Conclusion

Claude code was very good at creating initial project, making somewhat reasonable architecture, project structure. It suprisingly succeeded at designing GUI. It almost completely failed at writing bot’s logic. Here it tried random improvements which were marginal.

As project grows, bot burns token faster - especially when it does major refactoring and planning structural changes, it is less successful at keeping context. It can still do it, it is perhaps three to five times more productive than human (prompting may take 10 minutes, actual planning phase 10 minutes of AI work, reading plan few minutes) and it’s cheaper, but … it’s all questionable. AI can design project structure, initial code, but once it stops p

Live demo

Last updated: 2026-02-09 to v2.1

---

Josef Bouše

s AI experimentuji už nějakou dobu v rámci SW vývoje. Claude, Codex, Gemini , gitHub Copilot atp .. Zkusil jsem si s nimi udělat i různé projekty různých velikostí. Vždy stejný výsledek, samozřejmě se to časem zlepšuje (ALE … - vysvětlím na konci) .. Všechny ty projekty měli první dobrý výkop, čím lepší zadání tím lepší výsledek (do jisté kontextové velikosti a složitosti, při složitějším a větším zadání se začíná dříve ztrácet) .. Samozřejmě lze rozdělit velký projekt na menší, řádně mít implementaci, řešit dokumentaci, ale to zase potřebujete k ruce seniora co AI bude využívat.. Nicméně všechny AI začkou kolabovat ve dvou momentech první je když se dostaneme do veliké složitosti, projekt obsahuje XY modulů a napojení, nemluvíme tady o jednoduchém API, co jen vrací dvě tabulky dat a filtruje .. mluvíme tu o náhradě CRM, ERP, CSM a dalších systémů .. AI začíná duplikovat kod, rozbíjet funkční kod a zpomalovat systém (ani už nebudu mluvit o situacích, kdy místo aby vyřešil chybu tak zajistí, že ji build polkne nebo kdy udělá bezpečnostní hrubku na úrovni juniora) .. další bod je když systém běží měsíc a já se k němu chci vrátit, použít starý chat ? často nemožné, mít z původního projektu dobře udělanou dokumentaci pro AI ? pokud ten co používal AI byl bystrý tak možná , ale i tak dokumentace ani historie chatu neobsáhne celý projekt a jak ho kdysi ten agent zamýšlel použít a rozvýjet. Tak nyní jdeme k tomu “ALE” , Ale je cena … Komplexnější a rozáhlejší zadání = více tokenů, rozdělit projekt na více agentů ? = více tokenů , udržovat jeden chat s historií ? = extrémně více tokenů .. A nedejbože když se agent zasekne na jedné hloupé chybě, bude pořád dokola část dlouhý log, posílat k analýze a pálit tisíce tokenů a problém co senior vyřeší za odpoledne on řeší do vyčerpání limitů na kartě. Pokud máte možnost mít lokální pokročilé modely, mít lokální HW za miliony, pak why not, můžete pálit kontext a tokeny jak je libo, ale stejně asi nedosáhnete těch výsledků co očekáváte.. Nejhorší na tom je, že až za rok firma s AI bude chtít zrušit předplatné protože to stálo více než když měli oddělení vývoje tak zjistí, že napravit škody a najmout znovu lidi bude stát daleko víc…