# Quick thoughts on AI in Game Dev > Source: > Published: 2026-07-19 01:13:36+00:00 # Quick thoughts on AI in Game Dev Over the last couple of weeks I've been working on two different small games. Both are ideas that have been kicking around in my head for a while and now felt like a good time to work on them. One is an existing project written long before I had a Claude Code subscription. The other had no code written but I had a few files of notes and ideas. After about two weeks working on both I have a few thoughts about strengths, weaknesses and quirks. As some context for how I used AI it was taking fairly small and controlled steps based on a code, play, feedback process. I have very little confidence or desire to setup a loop or goal around a game idea and vibe-code then deal with the result. Neither project is online just yet but I am hoping both will be in the next couple of months. These are both out of working hours projects so I chip away slowly. ## Language Models Love Words One thing I noticed was that Claude would put a lot of text on the screen. This isn't totally unexpected, it's a model designed to output text, but I spent a lot of time pruning back the walls of text added to screens and menus. It took a lot of guard rails to avoid adding more text than was needed. ## Screenshots chew tokens Out of the box Claude would attempt to boot the game (a bevvy app) and take a screenshot to confirm things were working correctly. This was fairly hit and miss even when it worked and it consumed a tonne of tokens. I understand the bias towards verification but had to eventually ask it to stop and just ask me to verify things myself to both save the tokens and pick up on things that were not captured in a single static image. ## Fun is much harder to automate than boring I don't make games for a living, this is deeply in hobby territory. Most of the work-work that I do is creating B2B SaaS products, data science or dev-tools. These work products aren't looking to be fun, they just need to work and ideally have an okay experience. On the other hand, games need to be fun. It is very hard for me to know in advance if something is going to be fun or not when making a change. More than other projects I work on I found myself tweaking things, undoing things, taking wild bets all in order to test whether something 'felt' better in the moment. This was a pretty enjoyable way to be building things. What worked particularly well was talking Claude with building systems and scaffolding that could then be modified and tweaked by me. ## AI Art is still quite bad, making scripted placeholders is pretty good Both the games I am working on have pretty simple graphical requirements. One is based around chess pieces, the other around a deck of cards and some buildings on a map. As a result, it was easy to get Claude to create some scripts to bulk create placeholder images. Cards are just rectangles with a symbol and number on them and chess pieces can be represented well enough with basic shapes. That plus some free CC0 assets from places like [Kenny](https://kenney.nl/assets?ref=elliotcsmith.com) were enough to put 'something' on the screen. Eventually I'll swap those placeholders out for something 'real'. As of today, that 'real' version isn't going to be AI generated images. I still haven't seen a workflow that doesn't land the images squarely in uncanny/obviously-AI valley. More than that, and in line with the 'automating fun' point above, I think getting art style right and consistent in a game is pretty key to it felling right. I don't think that's something I can prompt my way to today. This may mean my games end up with my poorly drawn assets but for whatever reason there's a difference in my mind between AI for code and AI for 'art'. ## Claude Code is not tuned for games Rightly so, the out of the box experience of Claude Code is aligned more with work-work style development than game-dev-on-weekends. What I mean by that is it loves to unit test, comment like crazy and work assuming my repo is going to have a dozen other devs interact with it. After a few cycles it's pretty easy to tweak the project level settings but you can almost sense the bias as you work. I don't know what a Claude Code for game dev would look like but I am sure there are people working on that as a product. If not, and you read this far, go make it and I'll happily test/subscribe.