I used to have more ideas for personal projects than time to do much with them. That hasn’t entirely changed, but AI has made it much easier to get beyond thinking about something and into trying a version of it.
KJ’s Games, KJ’s Counter and this website are where I’ve been working out what that looks like in practice. I use ChatGPT to explore ideas and Codex for substantial implementation work, then spend time with what comes back. It isn’t one fixed process, and I’ve found that different kinds of work need different amounts of direction.
Sometimes the brief needs work first
A conversation often starts with something fairly loose: a tool I’d like to have, an awkward bit of a game, or a page that doesn’t sound quite like me. Talking it through helps me separate the thing I actually need from the extra features that have already started attaching themselves to it.
For a defined change, I try to give Codex enough context to work sensibly: the repository, the behaviour I’m after, what needs to stay intact and how to check the result. Useful documentation helps here too, particularly when I return to a project after working on something else. I don’t want the next task to depend on remembering a decision from several conversations ago.
Sometimes it’s better to try something
Stillwater Array was a different experiment. I knew I wanted a desktop-first game I’d enjoy, but I deliberately left the shape of it open and let Astra explore. My plan was to play what it made, then guide the direction from there.
That gave me a much better basis for feedback than trying to specify every part of an unfamiliar game in advance. I played it through, liked the first version and was happy for it to go live and grow over time. The expanded view was one of the first things I wanted changed, which led to a centred modal and further focus fixes before release.
I wouldn’t use that degree of freedom for every task. Counter’s collection and privacy boundaries, for example, needed to be explicit from the start. The useful question is how much room a particular piece of work can safely have, rather than whether every prompt follows the same template.
Using it is part of reviewing it
A successful build is a good start, but it doesn’t tell me whether an interface is comfortable to use. Scrambled’s answer input and shifting feedback needed another pass once I was looking at the sequence of playing. Stillwater raised questions about readable tides, blocked actions and returning to a saved game.
Writing needs the same sort of review. Each sentence on a page can be perfectly reasonable while the whole thing sounds as though it’s introducing itself again every few lines. Reading it in place, alongside the cards and headings around it, is often what reveals the problem.
I also try to be precise about what has actually been checked. A retention function working when invoked manually doesn’t prove that its daily schedule has run. A game completing an automated expedition doesn’t prove it’s enjoyable. For larger changes, a record of the work, tests and remaining uncertainties helps me review the result without relying on a confident-sounding summary.
What I contribute
Codex writes substantial amounts of code, tests and supporting documentation. I don’t want to describe that as implementation I typed out by hand. My contribution is deciding what to pursue, providing context, reviewing the choices and working out what to keep or change once I can use it.
That’s the part I find interesting. I can move between a project idea, a working version and a considered improvement much more readily than before, but there’s still plenty of judgement involved. The aim isn’t to accumulate more generated code; it’s to make things I’m glad exist and can continue looking after.
I’m exploring the same approach for planning, documentation, content processing and repeatable delivery checks. Some of that is still experimentation. KJ’s Games and KJ’s Counter are the more concrete examples of where it has taken me so far.