Have you ever struggled to get started with something new, not because the thing itself is hard, but because the shape of how to learn it isn’t clear? That’s where I’ve been stuck with agentic coding. Not the doing of it. I’ve been doing it for months. The teaching of it. The “how do I help someone else get started” of it.

And then I remembered code retreats. And katas. And the way I actually learned TDD all those years ago, not from a book, but from structured practice with low stakes and room to play.

So I built a set of agentic katas: structured coding exercises designed specifically for practising AI-assisted development. Not traditional katas, those are too small and the AI already knows all the answers. These are bigger, meatier problems in unfamiliar domains that force you to engage with the full process of working alongside an agent.

Let me explain how I got here.

A Brief History of Practising on Purpose

Early in my career, code retreats were the thing that taught me test-driven development. Not a book. Not a course. A structured, all-day event where you solve Conway’s Game of Life over and over again, each time with different constraints. Maybe your pair is actively trying to not solve the problem. Maybe you’re strictly ping-ponging. Maybe you delete your code every 45 minutes.

The point was never to solve Conway’s Game of Life. The point was to internalise the patterns and practices of TDD by giving yourself a safe space to experiment. No production pressure. No deadlines. Just play.

Code katas grew out of the same ethos, small self-contained problems that shouldn’t take more than an hour or two. The algorithm doesn’t matter. How you choose to solve it does. They’re bite-sized by design. They’re not supposed to be hard. They’re supposed to be practice.

The Problem with Katas and AI

Here’s the thing I’ve been struggling with: traditional code katas don’t work for learning agentic development. They’re too small. The LLM has already seen every solution to FizzBuzz and Roman Numerals in its training data. You’re not practising a workflow, you’re watching an AI regurgitate a known answer. There’s nothing to explore, nothing to plan, no decisions to make about approach or tooling.

And that matters, because the skill you need to develop with agentic coding isn’t “how to prompt an AI to write code.” It’s how to think alongside one. How to explore a problem space together. How to write a plan that gives an agent enough context to be useful. How to verify that what came back is actually what you wanted. How to set up your workspace so the AI has the right guardrails.

None of that shows up in a 30-minute kata where the AI already knows the answer.

The Accidental Discovery

What’s funny is that I’ve kind of been doing agentic katas already, almost by accident. I just didn’t realise it at the time.

A few weeks ago I wrote about deleting code on purpose as a way to recover from burnout. I’d been experimenting with the Ralph Wingum loop, throwing PRDs at an agentic coding workflow, seeing what came out, then deliberately throwing the code away. The output I was chasing wasn’t a codebase. It was understanding. How big can a PRD get before the loop breaks? How much do agent files matter? What’s the minimum setup to get something useful?

Each run was a contained experiment. Fresh repo, clear problem, focused practice, delete the code, do it again. I was varying one thing at a time, adding a CLAUDE.md file, scaling up the PRD size, trying a different domain, and learning from each iteration.

I was doing agentic katas. I just hadn’t named them yet.

Looking back, the whole arc has been building toward this. My game project was the first rough version, months of cycling through spec-driven development and making mistakes. The “delete the code” experiments compressed that into focused sessions. And now, formalising the structure into something other people can pick up feels like the obvious next step.

Building the Thing

So I’ve put together a set of agentic katas. The idea is that each one should require somewhere in the region of four to eight hours of focused hand crafted work to do well. And by “well” I mean the full golden plate: test-driven, 100% coverage, clean README, proper git history, the works. Not because the output matters, but because doing that level of work with an AI agent forces you to actually engage with the process.

The loop for every kata is the same:

Explore → Plan → Set Up Context → Build → Verify

And there’s one key rule that makes the whole thing work: you are not allowed to choose a programming language or framework until you’ve had a conversation with your AI tool about what the best approach is.

This is the rule that forces the shift. Instead of jumping straight to “build me X in TypeScript,” you have to start with “I need to solve this problem, what are my options?” You explore the problem space. You figure out what tools exist. You have the AI challenge your assumptions. Then you decide on an approach.

From there, you write a detailed plan, acceptance criteria, example data, use cases, a breakdown into small chunks of work. You set up your workspace with an agent file and think about what context to include. You build incrementally. And you verify everything: read the plan, read the code, run it, test it, confirm it does what you intended.

The Katas Themselves

I’ve started with four problems, each chosen because they sit in a domain most developers haven’t worked in before:

An audio transcriber that handles speech-to-text with timestamps and speaker diarisation. A background remover for image segmentation. A meme generator that deals with text rendering and positioning on arbitrary images. And a thumbnail ranker that scores images for visual appeal.

Each kata has deliberate ambiguity baked in, because real problems are ambiguous, and part of the skill is figuring out what questions to ask. They also have a privacy constraint (everything runs locally, no cloud APIs for processing) and an extra credit extension for when you want to push further.

Why This Matters Right Now

I’ll be honest: the reason I’m putting this together is partly selfish. I want to run a workshop with my colleagues, and I need structured material to do it. But there’s a bigger motivation too.

Right now, everything about AI and software development feels incredibly intense. Fear of being made obsolete. AI layoff discourse everywhere. The pressure to have strong opinions about tools you’ve barely had time to evaluate. It’s all very stressful, and stress is the enemy of learning.

What people actually need, what I needed, and what I accidentally created for myself, is a safe space to play. A contained environment where you can try things, make mistakes, and build intuition without the stakes of production code or career anxiety hanging over you.

Code retreats gave us that for TDD. I’m hoping agentic katas can do the same for working with AI.

The Repo

I’ve put everything together in a repo: github.com/vanonselenp/agentic-katas

It includes the kata briefs, a participant guide covering the rules and process, and a facilitator guide for anyone who wants to run this as a structured session with their team. A session takes about 90 minutes.

I haven’t run this with anyone else yet. I only put it together today, and I’m planning to trial it with my team in the coming weeks. It might be brilliant. It might be terrible. Either way, I’ll write about how it goes.

But the core idea, that you need bigger, unfamiliar problems to practise AI-assisted development, and that the process matters more than the output, that I’m confident about. Because I’ve been living it, accidentally, for months.

If you try it, I’d love to hear how it goes. And if you’re doing something different to build these skills, I’d love to hear about that too.

Alice in Wonderland by Valerie Hinojosa / Creative Commons Attribution-Share Alike 2.0

Now this is a story all about how one button link got my codebase flipped turned upside down. And I’d like to take a minute, just sit right there, and I’ll tell you how I shipped 14 PRs without pulling out my hair.

It started with a Monday morning meeting. I’d been off for three weeks. The meeting was dense with context about decisions made months ago, documented across scattered specs and design docs. Systems I don’t own. Plans originally speced out almost a year prior. SEO requirements. Legacy middleware behaviour. And somewhere in all of this, a single task: change where a subscribe button points.

The old flow routed users through a legacy auth endpoint which was a piece of middleware handling user state and return-to-site functionality. The new flow should skip that layer and go direct. Simple, right?

Three repos. 3 small PRs. That was the original scope.

It became six repos and one or two more PRs…

The Context Problem

Here’s what made this tricky: I didn’t have the context. Not the institutional knowledge of why things were built this way. Not the codebase familiarity to know where all the tendrils reached. Not the cross-system visibility to see how changes would ripple.

Normally, this is where you’d involve other teams. Schedule alignment meetings. Negotiate architecture choices. Coordinate timed releases. The org chart becomes the constraint.

Instead, I threw five AI tools at the problem.

I used internal knowledge search to surface half a dozen docs from a year ago about what a potential migration might look like. Copilot and Codex scanned repos I’d never opened, outputting high-level analysis of what would need to change. NotebookLM synthesised a dozen-plus sources into actionable Jira tickets with acceptance criteria and testing plans. And Claude handled the actual implementation across all six repositories.

Each tool for what it does best. None of them sufficient alone.

The Shape of the Change

What was supposed to be three repos became six because the AI tooling kept finding rabbit holes worth going down.

The approach was backwards compatibility first. I updated the auth service to forward requests to the new endpoint, so existing systems would keep working. Only after that was stable did I remove the old code paths and switch the calls to point directly to the new flow.

Along the way, I hit a referrer bug that only revealed itself mid-implementation. One of the components lived in a shared library, not a full application, which meant handling referral data differently than expected. This meant that I had to change how it was reading from window referrer data rather than relying on direct redirect URLs.

And then there was a shared header component in another team’s repo. Hardcoded to the old endpoint. In code I couldn’t easily modify. The rabbit holes kept cropping up every time I thought I dived down them all.

Fourteen PRs. Six repositories. Backwards compatible throughout. Zero downtime.

The old flow had an extra hop through legacy middleware that handled state management. The new flow removes that layer entirely. Which makes for a faster time to checkout, same user experience, one less thing to maintain.

The Point

This would have been a multi-team effort. Alignment meetings across three teams, at minimum. Negotiated timelines. Architectural discussions. Coordinated releases.

Instead, it was one developer holding context that used to require an org chart.

I’m not saying AI tooling makes you a better engineer. I’m saying it lets you hold more context. And sometimes that’s the difference between “we’ll need to schedule a meeting with the other teams” and “I’ll have a PR up by Thursday.”

The context ceiling just got a lot higher.

Burnout is real, and it takes time to work its way out.

I spent the last couple of months trying to work up the will to tackle game projects again. Every attempt fizzled. After a 3+ month slog on a project that refused to reach an end state. I had nothing left.

So instead of committing to another massive project, I started playing.

I came across the Ralph Wingum loop (30-min video if you’re curious) and decided to experiment. The premise is simple: use two Claude skills and a bash script to let an AI go full agent mode. The first skill, /prd, takes a spec and generates user stories with verifiable acceptance criteria. The second, /ralph, converts that PRD into JSON. Then you loop over the JSON until done. This is basic agentic coding, but AI-agnostic and surprisingly effective.

I needed a project to test this on, so I picked V-Sabotage. It’s a board game I enjoy but rarely get to play (toddler life), and more importantly, it’s simple enough to define a clear MVP: rooms, a player, guards, sneaking mechanics, a win condition. I’d learned my lesson about scope.

The real experiment wasn’t building the game. That was just the head fake. It actually was figuring out how to break down the work. How big should each PRD be? Do you treat each milestone as its own PRD? Do you throw the whole spec at it and see what happens?

I had to find out.

First run: I threw a PRD at the skills, ralphed it, and looped on a fresh repo. What came out was very familiar from the last time I was building a game in Godot with AI. Bascially something that worked, but buggy, clunky, no tests, poor signal architecture, tightly coupled code.

Second run: Same PRD, same loop, but this time I initialised the repo with a CLAUDE.md file first. Just basics: test-drive the code, use Godot 4.x best practices, that sort of thing.

The difference was dramatic. The AI wrote its own test runner. It test-drove everything, achieved high coverage, produced cleaner interfaces, used signals properly, and kept things decoupled. Twenty minutes of compute, and the output was genuinely good. Honestly the thing that blew my mind on this was it wrote it’s own TEST RUNNER!?!?. Are you kidding me?

So … key lesson: agent files matter. A lot.

Third run: I embedded full milestones into the PRDs—a dozen user stories each, multiple acceptance criteria. The loop churned through it and produced a testable MVP in surprisingly little time.

Fourth run: I got distracted by an app idea. Spent a couple of hours refining it with AI, generated a chunky PRD, threw the whole thing at the /prd skill. It produced 40 stories. I looped it. An hour later, with 5% of my usage allowance remaining, I had a working prototype.

It didn’t do exactly what I wanted. But it did most of what I’d asked. This was surprisingly more than enough to immediately change my thinking about what I actually needed in a meaningful way.

And here’s the thing that made all of this feel like play instead of work: I deleted the code.. I went full code retreat conways game of life delete the code.

Multiple times. Deliberately. The output I was chasing wasn’t a codebase. It was understanding. How big can a PRD get before the loop breaks? (Bigger than I expected.) How much do agent files matter? (More than I expected.) What’s the minimum setup to get something useful? (Less than I expected.)

Disposable code meant low stakes. Low stakes meant I could experiment freely. And experimenting freely, it turns out, is how I recover from burnout.

This play has fundamentally changed how I work at The Economist. But that’s a story for next time.

This week has been a mess. I’ve been ill since last Thursday with a cough that’s been both productive and dizzying, which in a rare moment of clarity made me realize that maybe doing personal dev in the evenings is… not ideal. So no game dev tales this week.

Instead, I want to talk about how I nearly torpedoed a production refactor at The Economist a month ago by forgetting the most important lesson I’ve been learning over the past few months: AI makes discipline more important, not less.

The spectacular failure

I’m currently on the e-comm-funnel team working on the checkout pipeline. One of my first projects has been tackling Commerce Services. This is a Go monolith (a language I’d never used before recently) that started as a POC and got productionized. Naturally, it’s a beautiful mess with conflicting APIs doing all sorts of non-cohesive domain things.

My goal: break it into microservices.

So naturally I did what I’ve been practicing with Horizons Edge and started with a spec. I had a very long conversation with Codex, analyzed the repo structure, identified the domains, mapped dependencies. From this chat we produced a solid 10 page high-level plan.

And the first step of that plan was Phase 1: extract common code into a shared library.

And somewhat predictably, here’s where I got clever.

I thought: “I’ve got a detailed spec. Codex knows Go. Let’s just… do the whole thing! Whats the worst that could happen?”

So I did. One massive refactor. Codex happily obliged.

Then I looked at the pull request: 200 files changed in the monolith. 80 files in the new library.

And I just stared at it, completely overwhelmed by the obvious question: How the hell am I going to verify this actually works?

There was no way I could meaningfully review 280 files of changes. No way I could ask another engineer to do it. No way to be confident this wouldn’t break something subtle in production. I’d just created an unshippable monster.

Starting over, properly this time

I scrapped the entire thing and started again with an “I need this to be incremental” mindset.

Not just because I wanted to be able to review it, though that’s critical, but because I genuinely believe small releases into production are the right way to work. It should have been my default starting point. Instead, I’m still learning just how disciplined I need to be when working with AI tooling.

The new approach:

First, I wrote a much more detailed spec for Phase 1 that lived in the new repo. Not just “extract shared library” but an 8-step plan where each step could go to production independently. Start with the absolute minimum: just one joint service with no dependencies. This would validate the CI/CD pipeline, the integration points, everything, with the smallest possible change.

Then, one step at a time:

• Extracted and deploy leaf utilities (logging, validation, middleware)
• Migrated HTTP routing abstractions
• Moved observability and AWS helpers
• Extracted infrastructure components like health checks
• Finally, the component registry

At each step: tested, improved coverage, deployed to production, monitored. The existing systems kept running exactly as before.

I followed the same hyper-methodical approach I’ve been using with the game project. Focusing on small scoped MVP slices and incremental delivery. For the actual development, I loaded Codex into a workspace with both repos and had it follow the spec file for each migration. Then validated with Claude in GitHub Copilot, extensive personal review, and eventually team review before each production deployment.

The result: A refactor of a core system touching ~200 files, in a programming language I’m just learning, in a domain I’d just joined, completed over a couple of weeks with zero downtime. No one on the team was blocked or impacted. It just happened quietly in the background.

What I’m taking away

Two things keep reinforcing themselves across contexts:

First: AI amplifies your need for discipline. The easier it becomes to generate large amounts of code, the more critical it is to think carefully about scope, verification, and deployment strategy. One-shotting 280 files feels productive in the moment. It’s not. It’s just creating an unshippable mess you’ll have to undo.

Second: The “what’s the smallest increment that adds value?” mindset pays off everywhere. It saved Horizons Edge when I was drowning in scope creep. It made this refactor safe and reviewable. It’s not just a nice-to-have for side projects … it’s how you de-risk production changes in unfamiliar territory.

Next up is breaking out actual domains into microservices, starting with Identity & User. But that’s a plan for next year, when I’m hopefully no longer coughing my lungs out.

It’s been three months since I started trying to make Horizon’s Edge, a tactical turn-based wargame in the sky. And honestly, I’m completely stunned that I even have something that actually … kinda … works.

From Vibe to Spec

When I started this project, I was pure vibe coding. But somewhere in the middle, when I was trying to refactor the UI from a classic RTS/turn-based strategy with a mass of buttons to something entirely driven by card play, vibe coding hit a wall. I couldn’t get AI tooling to cooperate with my loose intuitions. That’s when I started working with specs and it changed my life…. metaphorical life …. but life!

Writing a clear specification before diving head first into a vibe changed everything. Suddenly the AI had guardrails. It stopped looping in circles. If you want to go deeper on this, I wrote about starting to figure out specs in Chaos, Cards, and Claude.

Months of Education

What I’ve learned so far is this: it’s entirely possible to make working software with AI tools. You can keep momentum even when you’re completely out of energy or time. But the most important thing … the thing that actually matters … is that you have to always verify what the AI outputs. Automated unit tests are your best friend here. A Quality first mindset and thinking about edge cases is fundamental.

I’ve done major refactors. I’ve rethought how the game works multiple times. I added procedural generation because it was fun. I figured out how to make the game work with just card play mechanics that… mostly work (much to my surprise). Some refactors were vibe-coded disasters; others were spec-driven and clean. But every single one taught me something about how to work with AI as a tool rather than a replacement.

The MVP: What It Took

Two days ago I finished the final major system needed to validate the MVP: the victory system. Islands needed to change ownership. Every existing system needed to integrate with that. Core island nodes needed to be targetable from creatures, spells, and abilities. Getting the targeting code to work meant hitting more touch points than I anticipated. A lot of different abilities needed specific ways to target islands, not just creatures. It was more entertaining than expected, but I had a spec, and that spec kept me honest.

I now have two thematic decks that are actually unique. 10 creatures. Infrastructure cards that terraform and change the world. A spell that destroys the world. Card play mechanics that mostly work. A whole horde of nuanced and detailed rules about damage and combat that work.

Prototype done. Well, mostly.

The mechanics are all there. What’s left is UI feedback. Cards need to show their play cost clearly, what they do when discarded, what abilities they have before you play them. I know all this because I’ve spent three months building it. Others won’t. So I’m going to tackle those UI gaps this week, then put this in front of a few people to get real feedback.

Now It’s Your Turn

I’ve spent the past five months working on this. It started with a Magic the Gathering Pauper Jumpstart cube that just wouldn’t get out of my head, went running headlong into a board game prototype that was way too complicated and barrelled straight into this game. I’ve learned a ridiculous amount. But here’s what actually matters:

It is possible to make working software with AI. You can make some amazing things with these tools. You can learn as you go. You can ship those crazy ideas you never thought you could.

So here’s what I want:

I want you go out and make your own mistakes. Build something weird. Use AI as a tool, verify everything it does, and then make something great. Make art. Because making art, well, that’s the most human thing we can do.

Tell me what you build. I want to hear about it.

Till then, keep learning.

Last week I had a sudden but inevitable realisation. Basically my MVP was completely not an MVP but rather a bloated over-built system that I should have been moving to release sooner. Which in hindsight I should have realised… 4 weeks ago. Lesson learned.

So, this week I started with yet another plan where I detailed out a new spec that broke down the exact things I needed to do. And then… I did just that! Everything else is deferred.

Broad plan for MVP:

• 1 Spell: Meteor - DONE
• 1 Victory condition: own all the islands - IN PROGRESS
• 2 Unique Decks - TODO

The spell was easy. Just another ability, and make it bigger, cost more and have an animation that then removes a massive amount of real estate. Big, flashy, simple.

The victory condition, however, has turned into a far more crunchy problem. Turns out wiring up ownership, health tracking, and win conditions across multiple systems was messier than I thought. I’ve built:

• A game over screen to start a new game
• Health on the core island node
• A UI display to see that health
• A manager to track who owns the islands and a way to change ownership
• A victory condition that checks each round if someone’s actually won

Almost there! The missing piece is creatures targeting the core island and dealing damage to it. Once I wire up that damage pathway, the whole system clicks. That’s what I’m grinding through at the moment.

All that will be left is two decks. Which should be as simple as updating two config files, and I’ll have a playable MVP. Finally.

Scope Creep Keeps Teaching Me

Have you ever had one of those weeks where you suddenly have to be traveling a lot and don’t really have any time for personal projects? This has been my week. I still managed to get two creatures and six abilities created.

The Flux Chaos controls the board by moving creatures into and out of position, swapping them from behind enemy lines or randomly teleporting them somewhere (maybe even off into the void). The Flux Storm does massive area damage while locking down the area preventing anyone from teleporting in and out. Watching these creatures interact with the existing systems is delightful. The abilities are beginning to feel like they synergize and interact together nicely.

I’ve been on a mission to prototype this strange game idea for a while now. I started the repo on September 4th. Three months later, I’m watching a prototype that’s actually starting to feel like a game with interesting systems.

But here’s what I should have learnt sooner: I didn’t cut far enough.

When I started, I aggressively removed things. All 8 envisioned factions. The single-player campaign, stories, and lore. AI players. Multiplayer. Different form factors like mobile. Complex models and animations. I thought I’d solved the scoping problem. Oh how innocent I was.

I then built ten creatures with twenty-nine abilities. I added procedural island generation and dynamic road construction. I went down tangents and rabbit holes as I iterated from RTS-style UI to pure card-driven gameplay.

Looking at that list now, that should have been a warning sign. And it gets worse: my remaining feature list for MVP includes five more buildings, five more spells, multiple win conditions, fog of war, proper turn behavior, UI polish.

It’s only now that I am looking at my remaining feature list (I wrote up the list for this very blog post), that I realize the entirely obvious thing. I am still overscoping. Scope creep doesn’t stop after one round of cuts. It’s persistent. Even when you’re actively trying to think in MVP terms, there’s a pull to add one more building, one more spell, one more system. Each one feels necessary. But they compound.

I should have picked this up sooner: that grinding feeling I’ve been having with the creatures and abilities. It has felt like motivation leeching away in the never ending drudgery. It was a clear warning sign I was off the path.

So here’s my actual MVP: one spell (meteor), Fog of War, one win condition, UI, and two decks. That’s it. Just the core systems missing, playable, shippable. This is what I should have built from the start, the smallest thing that proves the concept works.

The lesson keeps teaching itself

I keep learning the same lesson over and over. I thought I’d solved scope creep when I cut factions and campaigns. Three months later, with ten creatures and twenty-nine abilities built, I realized I’d just learned the lesson at a different scale. Every time I ship something, I understand a little better what actually mattered. And every time, I realize I could have cut further.

The game is starting to have shape because I’ve been building and learning. But I’m also learning, again, that shipping something small and real beats shipping something comprehensive and theoretical. Time to cut deeper. This time, I’m shipping the prototype before I convince myself I need more.

This week I had zero motivation. Motivation tank completely empty.

My goal was 4 creatures and all of the remaining abilities. I only manage to build 2 creatures and 7 abilities instead.

That happening was astonishing to me.

But it did. And the reason isn’t hard work or willpower, it’s process. The structure on how to work with AI that I follow is robust enough to produce good work even when I have nothing left. That’s the real story.

How the structure holds up

My process is straightforward: compact the conversation, use the spec to guide the next iteration, verify the implementation, have the AI explain what it did, then manually test each ability. Rinse and repeat.

The spec-driven approach kept context alive, for me and the AI. While my motivation was completely drained, the AI kept building. I basically did the bare minimum each day before switching to Marvel Spider-Man, but the structure meant I never lost the thread. I was running on Seinfeld method momentum: just keep the chain unbroken.

But here’s the critical bit: verify everything the AI makes. The AI will confidently insist “Everything works perfectly!” and update your docs without being asked. Then you test it. Nothing works. You point it out and it turns out half the feature wasn’t there to start with. Point it out again, and more unfinished work is found. The AI is capable and also will miss the obvious. Trust but verify.

Pro tip: never ever let the AI update the docs without being directly asked to.

This verification habit isn’t just bug-catching. It is the key habit that keeps the process from collapsing. Without it, you’re just building on sand. With it, even a low-energy week produces solid work.

Where designs actually get good

The most valuable phase in my workflow is when the AI explains what it just built. That’s where I stop and think: does this ability actually do what I want? Should it shift? Should it do something different?

That’s where the magic happens.

The Biomass Tank’s parasitic bond is a perfect example. It started as a triggered ability, shifted into an activated passive that heals the Tank whenever any nearby enemy creature takes damage. That single design decision cascaded: upkeep suddenly mattered. Rounds had weight. Generator buildings became far more valuable, and vulnerable. The creature went from decent to a potential powerhouse with two different healing methods and the ability to stay safe at range.

The design got better not because I worked harder on it, but because I paused to think about what it was and what it could be.

Same with the Voltage Defender. Its pull mechanic started simple—nudging creatures around the battlefield. But when I stopped to think about it, it shifted: what if it could move creatures off islands entirely? Suddenly it’s a broad control tool, shutting down buildings and repositioning the entire battlefield. That cascaded too—every ability needed rework. The EMP got bigger, affected every building including the player’s, made positioning critical.

This reflection loop, building something, stopping to think about it and then nudging the design. It keeps creating moments where the game gets better. It’s where iteration actually matters.

The real lesson

Turns out the structure matters more than the fuel. Low-energy weeks aren’t failures. They’re tests of process.

When you have nothing left, you find out what actually works. This week proved that good structure, spec-driven development, verification habits, and the discipline to reflect, can carry you through. The creatures got better not because I pushed harder, but because the process was solid enough to ship good work anyway.

I might not have had the energy. But the system did.

Next week

Fingers crossed, I will hopefully be finished the creature cards and start working on spells like Meteor and Lightning and getting some more buildings working correctly.

This week, my carefully-laid plans for rapid progress on Horizons Edge, a tactical wargame with card-driven combat on floating islands, collided headfirst with 2,255 lines of code and 94 functions living in a single file. Whoops. Just what I always wanted. I’d let a god class slowly brew and percolate while I focused on shipping features. Now it was time to pay the inevitable technical debt.

The wonderful file in question: game_manager.gd. It was managing twelve distinct functional areas: turn management, combat, creatures, cards, abilities, territory, players, and more. The result was tight coupling and maintenance friction of epic proportions.

The Question that drove me

I’ve spent the last month learning how to work productively with AI on complex coding tasks. And I had a nagging question: Can an AI do a massive refactor productively? Can you have a boring refactor—a by-the-numbers, tick-the-boxes, super easy, chill refactor?

This wasn’t just idle curiosity. When I last attempted a refactor of similar scope, it was an spectacular disaster. I spent two evenings fighting with Claude about types, going in circles while the AI and I kept insisting the other was wrong. The game broke for days. It was a hair-pulling nightmare that never ended. It was painful, demoralizing, and left me deeply skeptical about whether AI could handle large-scale refactoring productively. That experience shaped everything about how I approached this week.

But this time felt different. I had a plan.

Setting the Constraints

Before diving in, I wanted to be intentional. I asked Claude to analyze the file and create a refactoring plan, but with strict requirements:

Functional Requirements:

• Maintain existing behavior. No new code, no feature creep—same behavior, different structure.
• All key systems had to keep working: card play, creature combat, energy systems, turn management, terrain creation and destruction. Everything.

Technical Requirements:

• Files should be less than 400 lines each
• Absolutely no circular dependencies (this still haunts my nightmares)
• Follow good Godot practices using signal-based architecture and node-based composition

Methodology:

• Everything had to be incremental. No big bang refactors. Incremental changes mean incremental testing, which means catching bugs early.

Claude produced a 1,091-line planning document comprising 11 phases, complete with a testing strategy, regression testing plan, and a high-level architecture with 8 new manager classes. It was exactly what I needed: a detailed roadmap to follow rather than a free-form creative challenge.

The Method That Worked

Here’s the systematic approach I followed for every phase:

1. Clean context: Open a new terminal window with a fresh Claude context (no conversation history creep)
2. Implement one phase: Ask Claude to implement just that single phase from the planning document
3. Verify no regressions: Get Claude to check to verify its work
4. Create a manual test plan: Have Claude outline a manual testing plan
5. Hand test and fix: Switch back to vibe coding; find bugs, fix them one at a time
6. Commit with clarity: Once working, commit to the branch with a descriptive message

This rhythm was key. It prevented the cognitive overload of trying to refactor everything at once while still making steady progress.

The Results

I started Friday evening and finished Tuesday evening. Seven hours total—an hour Friday night, four hours scattered across the weekend, another hour or two on Monday and Tuesday combined.

And here’s what shocked me: the game never broke. Not once. This was the easiest refactor of such a complicated system I’ve done in my career.

The difference was night and day compared to last month. That first refactor had been a hair-pulling nightmare. The game was down for days, I was fighting with the AI in circles, nothing felt under control. This time? The game was working the entire time. Every phase landed in manageable doses. I could test incrementally. I could fix bugs before they cascaded into system-wide failures.

It’s a quintessential example of risk mitigation in action. Small, verifiable steps beat big, catastrophic swings every time.

Unlike that previous disaster, this one was systematic. Methodical. Boring, even. It felt like just a matter of following good habits and executing. No dramatic debugging sessions. No circular reasoning about types. No late-night frustration.

There was something almost boring about how well it worked. And that was the point.

What This Taught Me

The breakthrough wasn’t a better AI. It was a better process. By being intentional about constraints, breaking work into small phases, maintaining a testing regimen, and keeping context clean, I transformed a refactoring task from a high-risk, high-stress nightmare into a predictable, manageable project.

That first refactor failed because I was vibe-coding with the AI. It was reactive, unfocused, trying to solve the whole problem at once. This one succeeded because I treated it like a spec-driven project with a plan, clear objectives, and systematic execution.

The lesson: AI isn’t magic. It’s a tool. And like any tool, it works best when you know exactly what you’re trying to build and you approach it methodically.

What’s Next

Now I can finally get back to what I actually want to be doing: making Horizons Edge a better game.

This coming week: three new creatures with three abilities each. Voltage Defender (exactly what it sounds like), Biomass Tank (a tanky presence), and Flux Chaos (honestly, even I don’t know what this one is yet. That’s kinda the fun of discovery). More abilities. More discipline. More checkboxes to tick.

Until next time, may your refactors be as boring, and your code as stable, as this one turned out to be.

OMG. This spec driven development process is BORING!

Okay okay, for reals though, following this process of using a spec and a clear breakdown of tasks is tangibly yielding results and making remarkable progress forward in the game.

In the past week I have:

• Created 3 new creatures: one that moves fast, hits hard and stuns enemies; another that spawns minions and multiplies when it dies; and one that shoots a bolt that blows things up and destroys land all over the place
• Around 9 new abilities created and working
• Got the AI to hack some terrible models together so they would be unique enough to be playable
• Made the islands generate more interestingly
• Completed a horde of UI cleanups
• Handled some general refactorings and got a bunch of systems working
• Total changes: 52 files modified, +3,718 lines, -474 lines across 34 commits all for about 10 hours effort.

By basically all metrics… productive?

So Where Did the “Boring” Comment Come From?

It comes down to what following the spec driven development process has actually become. Now that I’m being militant about making AI follow a todo list, what I’ve functionally done is put on multiple hats:

Product Manager hat: Created a complete game design doc. High-level, aspirational, covering combat systems, creatures, abilities, victory conditions — the whole vision thing.

Delivery/Feature Lead hat: Took one section (the combat system) and broke it down into actual features. Not just “build combat” but “what does combat need? Movement? Attacks? Status effects? Death?” The unglamorous work of turning vibes into verbs.

3 Amigos hat: Turned those features into a massive todo task list. Every checkbox a micro-commitment. “Add blink ability.” “Implement stun on hit.” “Make multiplying enemy spawn minions.” The kind of granular breakdown that makes you feel like you’re doing corporate sprint planning for your hobby project.

Engineer hat: Actioning the tasks one at a time. No wandering off to make prettier models. No “oh but what if the islands had weather systems?” Just: checkbox, code, commit, next checkbox.

QA hat: Testing behavior. Does the stun actually stun? Does the explosion destroy terrain properly? Do the spawned minions inherit the right stats? The tedious-but-essential validation loop.

The realization: I’ve become …. an entire agile team.

And what that practically means is that I’ve made gamedev into work. My day job. God damn it.

Spent a lifetime developing habits on how to do engineering, and then you get a newfangled tool and you just… follow the process. Good job me. Yay! Right? …Right?!

The Tangents I Didn’t Follow (And Why That Hurts a Little)

I’ll be honest: getting lost in tangents and running away with the vibes is a whole hell of a lot of fun.

In past weeks, I would have absolutely gone off on any of these:

Visual polish: Using all the gorgeous tiles from Kenney’s asset packs to make everything look beautiful instead of just functional. Making each creature feel distinct and characterful instead of “placeholder cube with stats.”

Procedural generation rabbit hole: Diving deeper into Wave Function Collapse algorithms to generate more dynamic, interesting terrain. Making islands that feel hand-crafted even though they’re algorithmic.

Creature personality: Actually modeling unique designs for each bot. Giving them visual identity, animations, character beyond their mechanical function.

Worldbuilding: Fleshing out the lore of the different factions. Their motivations, their aesthetics, their place in this weird sky-island world I’m building.

These are the fun parts. The parts where you lose track of time because you’re following curiosity instead of a checklist. The parts that make gamedev feel like play instead of work.

But here’s the thing: none of them get me closer to a playable game.

They’re all polish on a foundation that doesn’t exist yet. They’re the dessert when I haven’t finished the vegetables. So the spec says: not now. Stay focused. Ship the MVP first.

It’s the right call. I know it’s the right call. Oh heavens please let this be the right call …

And I hate how boring the right call is.

The Discipline vs. Fun Paradox

Being strictly disciplined with myself about how to dev with this tool is super productive. Lots of forward momentum in an actual direction is really fantastic.

And also… boring.

There’s something deeply satisfying about seeing the commit graph fill up. About checking off todo items. About watching the line count grow in a structured, intentional way. It feels professional. It feels like I’m actually building something instead of just playing around.

But it’s missing that chaotic energy that made the early weeks of this project so intoxicating. The “what if I just try this wild thing?” moments. The tangents that turned into features I didn’t know I needed.

The spec process works. It’s just not romantic.

Where I’m Headed

My plan is to stay disciplined until I hit what I’m calling an “exit point” — a milestone where the game is functioning just enough to validate the gameplay and experience. Right now, that means:

• 2 unique decks that feel different to play
• Basic strategy cards that offer meaningful choices
• Fog of war (because exploration matters in a tactics game)
• A simple victory condition

It won’t be done. But it will be playable. And testable. A real artifact I can put in front of someone and ask: “Is this fun?”

Following this process is giving me something I’ve never had before in side projects: predictable, consistent progress.

Not explosive bursts of inspiration followed by month-long abandonments. Not chasing vibes until I hit a wall and lose interest. Not 10,000-line notebooks that collapse under their own weight.

Actual, measurable forward motion toward a concrete goal.

The Bottom Line

Is it boring? Yes.

Is it working? Also yes.

And maybe that’s the trade I need to make right now. There’s a time for tangents and vibes — I spent weeks in that mode and learned a ton. But there’s also a time to put your head down, follow the checklist, and actually finish something.

The irony isn’t lost on me: I spent four months learning how to use AI as a collaborator, only to discover that the real unlock was bringing back all the boring engineering discipline I use at my day job.

Turns out “vibe coding” still requires structure. Who knew?

Next week: More abilities. More discipline. More checkboxes. And hopefully, one step closer to knowing if this game is worth making at all.

P.S. If you’re following along with this devlog and thinking “wow, this sounds like he’s sucked all the joy out of his hobby” — yeah, a little bit. But also: I’m actually building something now instead of just dreaming about it. So maybe boring is the price of shipping.

We’ll see how I feel when I hit that exit point.

This is an exert of From AI Skeptic to Constant Collaborator: What I Learned Vibe Coding.

Practical Workflows

Through trial and error, I developed specific patterns to manage AI’s weaknesses:

1. The Planning Folder Pattern Keep numbered specs (1-initial-feature.md, 2-pay-by-discard.md, etc.) that document feature discussions. These become persistent context across sessions.

2. The Todo Accountability System Break specs into granular checkbox lists. Use them to hold the AI accountable during implementation.

3. The Git Save-Scumming Strategy Commit frequently. AI will overwrite working solutions without memory of what worked before.

4. The Role-Based AI Selection

• ChatGPT: Brainstorming, exploration, asking “what’s wrong with this design?”
• Claude: Implementation, code review, pair programming
• Copilot/Codex: Ticket-style work where you hand off and come back later

5. The Discipline Override Set hard rules to counter AI’s momentum:

• Force refactor cycles
• Write tests even when AI makes it feel unnecessary
• Question every tangent: “Is this the MVP?”

Minimum Viable Prompt Literacy

I have no idea what a “perfect prompt” looks like. But I know one rule that consistently works:

No matter what you ask the AI to make, the last sentence should be: “Ask me questions.”

Get the AI to ask you questions. Ask it “what am I missing?” type questions. This back-and-forth is where the real value emerges, not in the first response, but in the dialogue.

Remember all those high-minded ideas I had about staying on task with AI-assisted development? All that big game I’ve been talking about “this is how you do dev with an AI and keep it on task” and “this is the way you got to do it”?

Yeah, about that.

If you’ve been reading the wonderful adventures of the tangent king over here, I know what you’re thinking. He can’t do that.

For context: I’m building Horizon’s Edge: a turn-based tactical wargame inspired by NetStorm where floating islands battle for control of the skies. I’ve been developing it with AI assistance in Godot, and staying focused has been… a journey. Previous highlights include: diving into Wave Function Collapse procedural generation instead of finishing game rules, and a grand refactor that ate five entire evenings because I accidentally committed the .godot cache folder.

Well, I will have you know… that this week I set out to get a bunch of combat systems up and running. Working tip top. No funny business with wave function algorithms or hexes or anything! And I managed, for the first time in almost 4 months, to stay on task and not meander (too much) and actually get some things completed.

I now have 3 creatures, each with at least 1 or more special abilities and those abilities actually work. I know! I am surprised too. I’m meandering my way through my todo list and this week I have a test mage with 5 abilities actually working:

• Blink - Teleportation ability
• Ethereal Phase - Phasing ability
• Arcane Missile - Ranged magic projectile
• Divination - Detection/reveal ability
• Mana Drain - Resource manipulation ability

I might have wandered off and made one of the spells do terrain destruction too. Arcane Missile is the first ability in the game that actually destroys terrain rather than just building it. I just love the idea of the battlefield being dynamic and changing under the players’ feet. Right now it wipes out the hex the target was standing on, plus a 50% chance on each of the 6 surrounding hexes. The idea is that if a creature is no longer standing on anything, even if it has a lot of health, it will plummet to its death. It should create tension around expansion and positioning. Do you risk getting close for that attack if one wrong spell could drop you into the void?

I also figured out how to get rounds and turns working together (this was needed for Ethereal Phase). And I might have spent some silly time hacking in a few animations to make the effects a bit more obvious when they happen.

Admittedly none of this is “let other people play with it” yet. And it doesn’t yet have a win condition. But it is meandering in a direction.

See? Like I told you. Todo list! Let’s see if I can do it again?

Next up on the todo list: Three more creature archetypes, each with their own special abilities.

• test_voltage_bot with Overcharge and Turbo Boost abilities.
• test_biomass_spawn with Regenerate and Spawn Swarmlings.
• test_flux_walker with Chaos Bolt and Lucky Strike.

…assuming I don’t get distracted tweaking that wave function collapse algorithm again.

Incidentally, the stats for the week:

• 32 files changed
• 3,029 additions
• 508 deletions
• Net addition of ~2,500 lines of code

For an hour and a bit each night, the progress here is just down right fierce!

The Question That Started Everything

How does one actually vibe code? And the follow-on questions that kept me up at night: Is it any good? Can I actually generate real code with this? Is this going to take my job? Am I running out of career runway?

Around the start of June this year, I was an AI optimist while not really engaging with it. I used ChatGPT, DeepSeek, and Anthropic’s Claude, ran some thinking through them, maybe did basic searches. Honestly, I wasn’t using it in any meaningful way. Functionally, I was just playing with it. Nothing more.

Then I got stuck on a problem. By simply following my curiosity, I went from not having a clear idea of what I wanted to accomplish with AI to actively using it as a constant collaborator across multiple domains of my life. My approach to AI has fundamentally changed over the past four months, and it continues to evolve.

The Catalyst: Magic the Gathering (Naturally)

TLDR: I tried to make a Jumpstart cube. ChatGPT couldn’t solve it. Co-pilot couldn’t solve it. Co-pilot vibe coded a solution that kinda worked. I vibe coded a new solution that actually worked.

I couldn’t get the damn thing out of my mind, so I vibe coded this portfolio site to document what happened. Then, while working on the cube, a board game idea struck, and I couldn’t get it out any other way except by building it with AI. That board game has somehow morphed into a video game that’s far too complicated for the “get an MVP into prod fast” approach I keep trying to follow.

The time investment: 1-2 hours a day, either in the morning before work or while watching TV with my wife in the evening. This became an all-consuming obsession for four months. I sacrificed learning urban sketching, which I’d spent the first half of the year actively pursuing.

The cost: I’m paying £16/month for Claude Pro and £20/month for ChatGPT Pro. I use Claude as my primary coding assistant and switch between ChatGPT and Claude for thinking through problems. It’s worth it, without AI, none of these projects would exist.

Pre-AI, my side projects were timeboxed to a couple of days and small, achievable problems. Anything more would rapidly collapse under its own weight, too much code, too little time. Basically I didn’t do tech side projects. AI changed that equation entirely.

What I’ve Learned: The Core Insights

AI is a Tool and a Multiplier

You have to treat AI not as a magic box that will automatically solve whatever you hope it does, but rather as another person you’re working with over Slack. If you tell a coworker “make me a feature!” you can’t be upset when they return junk.

The best way to use this tool is to assume it doesn’t actually know what you want. I’ve found the most effective approach is to start conversations with lots of negative validation questions: What am I missing? What could be improved? Be critical. Be objective. Get the AI to shoot holes through your ideas.

Once you’ve had this conversation, write that plan to file. Congrats, you now have a high-level plan. This becomes useful context for future chats. However, this alone won’t give you consistent, reasonable, progressive progress. Because basically, AIs like to write code, and they write an awful lot of it.

So get it to make a todo list with a painful amount of tick boxes.

When building, use that todo document to hold the AI accountable. It makes testing and building more predictable and manageable.

The “Junior Engineer” Mental Model Goes Deeper Than You Think

Treating AI like a junior engineer isn’t just about tone, it’s about workflow. Through my projects, I discovered I needed to:

• Use different AIs for different roles: ChatGPT for exploration and brainstorming, Claude for implementation and code review
• Create specs as “shared memory”: Documentation that gets committed to the repo so the AI can reference it across sessions
• Break work into granular todos: Not just for you, for holding the AI accountable to what actually matters
• Pair with it through code review: Not just generation

This evolved from my Magic cube project where I had specs numbered 1 through 15, each documenting a feature discussion. These weren’t outputs, they were context that survived beyond individual chat sessions.

The Dangerous Patterns: What They Don’t Tell You

The Refactor Paradox

Here’s something crucial I learned the hard way: AI accelerates the “green” phase so much that you skip “refactor,” leading to massive technical debt.

During my Magic cube project, I went from manually patching decks to having a 10,000-line IPython notebook that was completely impossible to understand. I had hit cognitive overload.

As an ardent TDD advocate in my day job, I realized I was missing two critical pieces of the red-green-refactor cycle: I was just writing code. No tests. No cleanups. Rookie mistake.

I had to start from scratch, consciously embracing a build-and-refactor loop, following the code smell patterns that years of clean code practices had drilled into me. AI doesn’t just multiply your output, it multiplies your technical debt if you’re not careful.

The game dev project repeated this pattern. I’d run git ls-files | grep '\.gd$' | xargs wc -l and see files well over 2k lines. I’d missed refactor cycles again.

The Tangent Amplification Problem

AI doesn’t just enable scope creep, it actively encourages it by making every side quest feel achievable.

My board game project is the perfect example. I set out one week to work on creature combat. By the end of the week, I had:

• Created test creatures
• Built movement and attack systems
• Added height-based defense
• Implemented dice roll combat
• Created a radial menu for unit actions
• Downloaded 3D models from Kenney.nl
• Rebuilt roads with proper models and rotations
• Added a blink ability

One feature became an ecosystem. And here’s the thing: it is beyond exceedingly simple to wander off on completely unrelated tangents when the AI makes everything feel possible.

I kept telling myself “get an MVP to prod fast” while simultaneously building procedural island generation with Wave Function Collapse algorithms.

But here’s why I didn’t stop: AI provides so much momentum that even when it’s frustrating, you can think about the problem slightly differently and feel like you’re making progress. When direct AI generation hits a wall, I switch to having it build the broad structure while I manually tweak settings. This makes working on side projects genuinely fun in a way they haven’t been before.

The momentum AI provides is a double-edged sword. It keeps you engaged through the frustration, but it also keeps you building when you should be stepping back and asking “is this the right thing?”

The Direction Problem: AI’s Spatial Blindness

Some tasks reveal AI’s sharp limitations. During my road system implementation, I discovered that AI spatial reasoning is terrible.

When work involves orientation, rotation, or physical space, the AI’s sense of direction doesn’t match how the world is rendered. Trying to explain rotations in a way that makes sense to both of us is like teaching a goldfish to drive.

And if the AI ever accidentally gets something right, it will immediately overwrite it in the next change.

My eventual workflow:

1. Get the AI to build the big stuff, toggles, switches, base structure
2. Manually go through and tweak everything myself

This led me to develop what I call “Git save-scumming”, treating Git like a video game save system because AI will thoughtlessly overwrite correct solutions without remembering what worked.

The Momentum Trap

AI gives me the same benefit I get from using Audible for reading books: momentum. It’s a lot easier to keep working on a side project with AI than without, especially when you have no time at all to do the work.

But here’s the tension my blog posts reveal: momentum without direction leads nowhere useful.

I built 24,000 lines of Python code for a board game that probably should have been paper prototyped first. I kept reminding myself to “get an MVP to prod fast and learn lessons,” but the AI made it so easy to keep building that I kept following the fun instead of following the plan.

The momentum is addictive even when it’s pulling you away from your goal. You have to be disciplined about direction, or you’ll end up with beautiful code for the wrong thing.

The Transformation: Four Months, Everything Changed

The most remarkable thing about this journey isn’t what I built, it’s the speed of transformation.

June 2025: AI optimist, barely engaging October 2025: 24k lines of game code, active collaborator across multiple projects, writing blog posts documenting the journey in real-time

Getting to the “treat AI like a junior engineer” mindset took about 2-3 weeks. I had to unlearn the “AI is magic” assumption and figure out how to actually use it.

This wasn’t gradual learning, it was catalytic. Each success made the next leap feel possible:

• Magic cube problem → vibe coding solution
• Couldn’t stop thinking about it → portfolio site
• One blog post → entire blog series
• Board game idea → 24k lines of video game code
• Video game reimplementation → another 24k lines of video game code

The cascading confidence is real. Once you see AI help you solve one “impossible” problem, you start seeing possibilities everywhere.

Bringing It Back to the Day Job

The spec-driven workflow I developed through these side projects has now become how I work professionally. I take tickets and reframe them into specs with task breakdowns. I use AI to analyze complex codebases I’m barely familiar with.

Right now I’m refactoring a monolith written in Go into a commons library with five microservices, using the AI spec-driven workflow with AI-assisted code development, working in small increments. Everything I’m doing, I learned from these side projects.

The irony: The Economist (where I work) has embraced AI tooling internally, while engineers in general remain reticent. I get it, I was there four months ago.

But here’s what changed for me: I still do traditional hand-crafted coding in my day job. I regularly work through code katas, which are fun and enjoyable in and of themselves. AI hasn’t replaced my coding skills, it’s multiplied what I can accomplish when I need to move fast or explore unfamiliar territory.

Practical Workflows That Emerged

Through trial and error, I developed specific patterns to manage AI’s weaknesses:

1. The Planning Folder Pattern Keep numbered specs (1-initial-feature.md, 2-pay-by-discard.md, etc.) that document feature discussions. These become persistent context across sessions.

2. The Todo Accountability System Break specs into granular checkbox lists. Use them to hold the AI accountable during implementation.

3. The Git Save-Scumming Strategy Commit frequently. AI will overwrite working solutions without memory of what worked before.

4. The Role-Based AI Selection

• ChatGPT: Brainstorming, exploration, asking “what’s wrong with this design?”
• Claude: Implementation, code review, pair programming
• Copilot/Codex: Ticket-style work where you hand off and come back later

5. The Discipline Override Set hard rules to counter AI’s momentum:

• Force refactor cycles
• Write tests even when AI makes it feel unnecessary
• Question every tangent: “Is this the MVP?”

What About the Code Quality?

Let’s be honest: the code AI generates can be good, can be overly verbose, tends toward duplication. But it can be nudged in the right direction quite easily.

The game currently works. It’s not feature complete, not even a pared-down, super-trimmed version. But it’s playable, testable, and iterating forward.

That’s the trade-off: you get speed and momentum in exchange for code that needs shepherding. You’re not writing every line, but you’re still responsible for the architecture, the patterns, and the quality.

Minimum Viable Prompt Literacy

I have no idea what a “perfect prompt” looks like. But I know one rule that consistently works:

No matter what you ask the AI to make, the last sentence should be: “Ask me questions.”

Get the AI to ask you questions. Ask it “what am I missing?” type questions. This back-and-forth is where the real value emerges, not in the first response, but in the dialogue.

It took me 2-3 weeks to figure this out, but once I did, everything clicked.

The Bottom Line

AI hasn’t replaced my thinking, it’s changed how I work. The best analogy I’ve found: it’s like pairing with a junior engineer who:

• Never gets tired
• Has read everything
• Has no memory between sessions
• Will confidently suggest terrible ideas alongside brilliant ones
• Makes everything feel achievable (which is both blessing and curse)

You have to bring the discipline, direction, and judgment. The AI brings speed, exploration, and momentum.

After four months of solo exploration,watching YouTube videos, AI Engineer conference talks, and lots of trial and error,I’m not worried about my career ending. I’m worried about not learning these tools fast enough.

Why This Matters (and Why I’m Writing This)

I’m writing this for two audiences:

Future me: So I can succinctly explain “this is what I learned” when the details fade.

You: To give you an idea of how to approach AI development that’s more than the nebulous “what the hell do I do here” feeling I had in June.

This is an invitation. Not a tutorial, not a manifesto,an invitation to experiment, to treat side projects with these tools as “learn how to AI” projects, and to discover your own patterns through building.

Because here’s what I know now: the developers who learn to work effectively with AI aren’t going to replace the ones who don’t. They’re going to outpace them by an order of magnitude.

The question isn’t “will AI take my job?”

The question is: “Am I learning to multiply my effectiveness, or am I just playing with shiny tools?”

For me, the answer finally became clear somewhere between a Magic the Gathering cube and a procedurally generated sky island wargame.

I’m building the plane while flying it. And documenting the journey as I go.

Because maybe, just maybe, someone else is standing where I was in June, wondering “how does one actually vibe code?”

And maybe this helps them take the first step.

Tangents, Roads, and Blinking Archers

okay okay okay, so I know last time I was all:

“I am going to work on the combat system.”

and I meant it. I really did.

I started the week’s development figuring out how to get a second creature working — this time one that could shoot! and it shot! with animation! and a lovely red number floating overhead when it hit.

Then I spent some time trying to convince the AI to make an archer… which came out as a cylinder and a torus mashed together like some long-lost relic from Lord of the Rings.

Somewhere between the floating numbers and cursed geometry, I ran into a movement bug where the creature could only move upwards but never downwards — so, you know, just another normal day working on a game with a super-powered AI as a pair.

And that’s the problem with having a super-powered AI as a pair: it is beyond exceedingly simple to wander off on completely unrelated tangents. Which is, of course, what I did.

The Tangent: Shiny Hexes ✨

When I was working through a game dev course on Jumpstart to 2D Game Development: Godot 4.4+ for Beginners last year, I came across a really cool site: kenney.nl.

They’ve got models, textures, and all sorts of game assets. And wouldn’t you know it, I found a bunch of hex models that perfectly matched the vibe in my head.

And just like that, all thoughts of combat systems and specs and rational planning evaporated.

No, now was obviously the perfect time to get models and textures in. So I immediately downloaded the GLB files and started plugging them into my wave function collapse algorithms.

Instant vibe shift. The world suddenly looked like something. I’m not using all the models yet… but give me time 😄.

The Roads to Madness 🛣️

With proper models in hand, I finally turned to something that’s been quietly tormenting me for weeks: roads.

Now that I had actual path models to work with, I thought this was going to be a cinch.

Nope. No. Oh hell no.

This is the kind of task that is inherently infuriating to get an AI to handle. Its sense of direction doesn’t match the way the world is rendered, and trying to explain rotations in a way that makes sense to both of us is like trying to teach a goldfish to drive.

And if the AI ever accidentally gets something right, it will immediately overwrite it in the next change. Because of course it will.

My eventual workflow:

• Get the AI to build the big stuff — toggles, switches, base structure.
• Then manually go through and tweak everything myself.

Thank god for Git and my obsession with save scumming my way back to a sensible state.

Meanwhile… Combat System? 🫣

Hang on though. Wasn’t I working on a combat system? Damn it.

Okay, where was I?

Ah yes — my ever-growing planning folder to the rescue.

I’ve developed a habit of getting the AI to output the result of any long feature discussion into a spec or planning file that gets committed into the repo.

Which is how I ended up with… about a dozen specs.

Some were implemented, some were “I realized this was a tangent and saved myself,” and some were very much still alive. After some reorganizing, I was down to a high level planning doc and a solid todo list that was a solid active plan.

➜  horizons-edge git:(main) ✗ ls planning/6-
6-implementation-todo.md
6-test-deck-archetypes-energy-abilities.md

Then came the fun part: getting the AI to validate how accurate my current TODO list was against the plan — and then, obviously, not trusting it at all and just starting to build anyway 😄.

Back on Track: Blink ✨

At last, finally, I was back on combat system track. And the first order of business: give my test creature a blink ability.

Let’s see how far I get next week.

Until then, I hope you’re enjoying whatever tangent is currently distracting you from your side project. I salute you, fellow tangent adventurers. 🫡

📝 Progress Summary Since last time.

• 🚧 Road System: Added straight roads, corners, intersections, and 3–5-way connections. Complex rotation logic, road-to-hex connectivity.
• 🧱 3D Asset Library: Integrated Kenney Hexagon Kit (180+ models, textures, documentation).
• 🏹 Combat & Abilities: Projectile system, Archer & Scout cards, ability system improvements, radial menu, energy planning.
• 🖱 Input & UI: New input controller with hex highlighting, better radial menu, multiplayer safeguards, grid visualization.
• 🧭 3D Model Integration: hex_tile_model_config.gd, updated rendering, road path visualization.
• 🗂 Documentation: New spec for energy payment (spec 7), reorganized planning docs.

Combat is a cornerstone of the game’s core loop — it’s a wargame after all. If the creatures can’t attack or move, nothing else really works. So it felt like the perfect place to focus on getting one thing working at a time.

You know that feeling when you promise yourself to build just one simple feature… and then accidentally end up building half a combat system? Yeah. That happened.

I set out to make creature movement and attack work. Just that. And technically… I did.

But also…

So What Happened Since Last Time?

• Created a test creature
• Added stubs for abilities and creatures
• Can play the creature onto the world
• Creature can move
• Creature can attack (with a cheeky little “nudge” animation!)
• Creature is persistent in the world
• First version of a combat system is in place
• Height contributes to defence
• Combat uses dice rolls
• Added a UI element showing active units

Somewhere between “just movement and attack” and the inevitable barrage of scope creep that is this list… I may have overshot my initial scope a tiny bit.

The Big Question I Didn’t Think Through

When I first added creature cards, I realised something obvious but important:

“What happens to the card once the creature is played?”

Does it:

• 🃏 Get discarded like a one-off spell?
• 🏗️ Stay permanently on the battlefield, RTS-style?
• 🧍 Act more like an ally in Marvel Champions?
• ❄️ Or a unique character like in Undaunted?

I wasn’t sure which direction would be more fun, so I had a long chat with the AI to explore the implications of each — and in classic not-thinking-it-through fashion, this has the feeling of being a dramatic question that might shift the whole damn game all over again. Hello scope creep, my old friend. I’m trying to keep you in check this time, I promise — setting clearer boundaries for what belongs in the MVP and what gets kicked down the road for future me to deal with.

The key takeaway: I want players to get cards out fast, keep them on the board, and have those creatures feel unique. So the “remove from deck” idea (like Undaunted) felt too punishing. RTS swarm spam didn’t fit either.

The sweet spot seems to be something like Marvel Champions: unique characters with meaningful impact.

A Fun Rabbit Hole: Rewarding Combat

This led me to thinking: what happens when you win a combat?

That’s when Battle Realms came to mind — an underrated, vibey-as-hell RTS from way back, with samurai, werewolves, vampires, and mystical Eastern weirdness. It used combat to generate resources for upgrades.

I love that idea. It adds stakes and momentum to battles without punishing players for losing units. And in yet another stunning moment of self-realisation, I promptly undid all my changes related to this feature — because it was scope creep of the highest order!

UI Tangents and Side Quests

UI clarity is what really shapes how the game feels to play, so making it intuitive is critical. When the interface gets in the way, the whole experience slows down, so I’ve been extra sensitive about how these elements work.

Of course, I also got distracted by UI.

Playing a card and then having it disappear so you can see where to place it just makes sense. So I ended up tinkering with creature display windows and UX polish far beyond what I planned. I also found myself wrestling with the active unit display — trying (and failing repeatedly) to get Claude and Codex to understand exactly what I wanted changed. It turns out it’s surprisingly difficult to use plain English to precisely specify how a UI element should behave.

But I did get a shiny radial menu for unit actions out of it…

The Actual Goal? Achieved.

At the end of the day, I really did achieve what I set out to do:

✅ Creature movement and attack — working (ish) 🌀 Plus a whole lot of unexpected side questing, because game dev is never a straight line.

Next Steps

Onward to the next rabbit hole.

This sprint was messy but productive — a reminder that even the tangents feed back into making the game feel more alive.

• Refine creature persistence and combat flow
• Continue working through the massive creature card spec doc — I barely made it through the first two abilities, and I still want to explore resource generation and upgrades from combat wins
• Keep iterating without accidentally building a full-blown RTS 😅

TL;DR: I aimed for one thing. I built a small ecosystem. I’m proud, a little tired, and very excited about where this is going. And I’ve learned more about using AI tooling than I ever imagined.

Last time on the wonderful adventures of a random walk down the boulevard of madness in making a board video game, I was busy refactoring cards and trying to get them to actually work.

Now I have working CARDS! They discard! They look devy! They click! They discard! The UI is janky, but hey—it works. I’ve got… 3 cards. Three. OMG. Only 3 cards. :mindblown: This is going to be harder than I thought (obviously).

Factions of Madness

When I nudged Claude toward “cards instead of buttons” as a way to unify the gameplay, I immediately got ahead of myself. Naturally, I dreamed up two factions, a bit of lore, some shiny card concepts, and before I knew it… two half-baked 20-card decks plus a half-baked strategy deck. It was going to be over 9000!

The concepts were fun:

Nezumi Swarm: Honorable rat samurai + endless undead swarm tactics. Weak but unstoppable. Multiplying and spawning more and more. For the SWARM!

Aetheric Empire: Victorian British Empire × Girl Genius mad science romance. Cyborgs, mechs, airship supremacy, love and madness.

The Romance. The Swarm. It was glorious.

Overload Incoming

Then reality hit: instead of my usual TDD-style “one thing at a time, working confidently,” I was doing everything, everywhere, all at once. Unsurprisingly: overloaded. Cue the “who’s on first, what’s on second, I don’t knows on third” situation.

So, the logical next step was to pause the chaos and implement turn/round structure. Makes sense, right? …Except instead I doubled back to cards. Because of course I did.

Planning Docs, or Madness in Writing

Here’s the interesting part: working with Claude (and Codex) has led me to generate deep planning docs for features. I’ll spend hours iterating back and forth, treating them like living documents. Each doc builds context for the next, and since I’m writing them inside the codebase, they get deeply grounded in the actual work. It’s been a surprisingly useful feedback loop.

If you’re bored, you can peek at the planning doc for Turn and Round Structure. But spoiler: instead of building turns/rounds like a sane person, I realized maybe… just maybe… I should start small. Like, test cards first. Lego pieces before Royal Albert Hall.

Small steps. Right?

Next Steps

So the plan now: get a test deck with basic cards sketched up and playable.

Next steps: MORE CARDS!

I’m focusing on functional requirements like:

• Complete archetype coverage: Territory, creatures, spells, interaction, combos
• Energy-gated abilities: Powers tied to energy types
• Ability framework: Up to 4 abilities per creature
• Energy-scaling bonuses: Special effects if fueled by the right energy

And covering these card types:

• ✅ Territorial Claim – Place core nodes
• ✅ Terraforming Push – Expand island
• ✅ Road Network – Connect islands
• ✅ Build Generator – Energy production
• ❌ Creatures with abilities
• ❌ Combat mechanics
• ❌ Opponent interaction
• ❌ Energy-specific bonuses

You’d think I’d take it easier this time, right? Nope. My card planning doc is 1,299 lines long. But this time, I’m getting Claude to implement one card at a time.

Let’s see how that goes.

Will I actually build a turn structure next time? Or just make even more cards? Until then, may your rats be honorable and your airships only slightly on fire.

Also, if you are counting, I am now up to using Claude Code, Claude, Codex, ChatGPT and Gemini to do this project ….

The Grand Refactor!

Last time we chatted I was making excellent progress with the video game implementation of a board game I’m randomly working on. I had island placement, roads, chunking, waveform-collapse procedural generation. It was smoking. I was learning how to get Claude to code well. The way of the Force was strong.

And then I ran a little terminal command:

$ git ls-files | grep '\.gd$' | xargs wc -l

…and what I saw was a bunch of files well over 2k lines. Clearly I’d missed a refactor cycle (or three).

Meanwhile, I’d spun up a Claude sub-agent to do research on tech topics. Naturally, one of the first queries was: “best practices for Godot.”

The results:

• Use a signal-based architecture (which matched my half-remembered notes from a Godot course last year).
• Use singletons for global access and cross-cutting concerns like game managers and event buses.
• And, buried near the bottom as a tiny afterthought: “Do not include the .godot directory in your repo.”

Guess what I had in my repo.

I deleted the folder… and unleashed a week of refactor drama. Turns out the AI had written multiple cyclic dependencies that only “worked” because the cache made it look fine.

Cue the AI loop:

• “To fix cyclic deps, remove types.”
• “No wait, add types.”
• “Think harder.”
• “Ultra-think.”

This went on for hours until I forced a combo:

• do ultrathink,
• do not remove types,
• change the dependency pattern,
• refactor large files into smaller files.

That finally got things moving. Between Claude and Codex, the refactor slogged forward. But it cost me five evenings of work.

When the dust cleared, I… immediately rethought the UI.

Up to now, core gameplay actions (building islands, adding chunks, placing roads and buildings) were just buttons. Cards existed, but only for creatures and spells. Then I thought: what if everything was a card?

That would unify the control system: play a road, play an island, play a creature — all from cards. It lays the groundwork for an MVP, and it leans into what I love about games like Undaunted and Memoir ’44, where your options each turn come from your hand.

So naturally, I dove straight into a UI refactor.

At least this time I started with wireframes in my sketchbook, thinking mobile-first. Right now the UI shows:

• your resources,
• your current hand of cards,
• a test deck with only the working cards,
• and the ability to create islands by playing cards and paying with other cards.

To call this “progress” would be… generous. It’s more of a profound sideways move. But that’s coding sometimes — discovery through chaos.

The one genuinely new thing I’ve started doing is feature planning with Claude. Basically it goes like:

• I describe the feature
• Claude grills me with clarifying questions
• I save that Q&A as documentation
• then Codex implements
• Claude reviews.

Complete aside: I also started playing with OpenAI’s Codex to see what it’s like. Codex feels like an agent you hand a ticket to and then 30 minutes later it drops a PR on your desk. Claude, on the other hand, is more like a junior dev you pair with — lots of back-and-forth, explaining, nudging, but it stays with you in the problem.

This flow has meant:

• less back-and-forth,
• better documentation,
• and an easier way to track what I’m actually building.

Which is good, because this project has been the wildest, flux-crazed coding ride I’ve ever been on.

What’s next

Honestly? No idea. Probably “make more cards actually work.” and “make them look more informative than tiny text you got to squint at to figure out what you are trying to do!”

Right now I’m wrestling the road network into the card system. The “play a card → build roads” flow keeps fighting me. It works as a button; it sulks as a card.

Near-term plan (aka cope notes):

• Make roads a first-class action. Card triggers a BuildRoadNetwork action with inputs (start, end, cost), not a kitchen-sink utility.
• Signals over reach-ins. Card emits “build-road-requested”; the road system owns the how.
• Pay-before-play. Validate cost and constraints first, then build; if it fails, no state touched.
• Isolate the graph. Get road-graph ops (connectivity, loops, costs) tested in isolation so I’m not debugging UI + rules at once.
• Tiny wins. One card → one road segment → then chains → then networks.

If that behaves, I’ll circle back and keep converting the old button-y stuff into cards until the whole game flows from a hand. If it doesn’t… I will perform ritual sacrifices to the debug gods and try the other other thing.

Lost in the Sky Islands: My First Attempt at AI for a Board Game

I’ve been on a mission to design a board game — Sky Islands — and build a simulation of it in Pygame so I can playtest it digitally.

As a seasoned engineer with 14+ years of experience, you’d think I’d take a well-organized, disciplined approach to building my game: a clear Trello board, carefully prioritized tasks, and a smooth, methodical path from prototype to polish.

Except… no.

Instead, I’ve been wandering from random idea to random idea, in a meandering creative hike with zero map and no water bottle.

Lately, I’ve been closing in on a pretty complete rules implementation: combat is figured out, island control works, magic buffs and damage systems are in place, and the Pygame simulation is almost bug-free.

Which naturally meant it was the perfect time to… add AI.

Enter the LLM AI Player

Traditional game AI is this slow, careful, deeply technical craft. It takes months — sometimes years — to tune and polish.

So in my infinite wisdom, I skipped all that and said: “Nah. Let’s just use an LLM as the AI.”

Better yet, let’s make it fully agentic. Surely if I give it a prompt and some game state data, it’ll play like a pro.

Here’s part of what I gave it:

You are an AI player in Sky Islands, a strategic card game. 
You control {self.faction_name} with {self.strategy_name} strategy.

Core principles:
- Maintain resource economy
- Protect your base
- Control valuable islands
- Use command points efficiently

Always respond in this exact format:
ACTION: [action_name]
TARGET: [target_if_needed]
REASONING: [brief explanation]

CRITICAL: Only use actions from the "AVAILABLE ACTIONS" section.

It seemed foolproof. Even better, I didn’t have to pay for every token — I hooked the OpenAI API up to a local LLM and got free AI gameplay. Perfect, right?

The Dream… and the Reality

The AI did exactly one thing well: write extremely convincing reasoning for its moves.

Like this:

“I’ll acquire the Roads island to improve connectivity and expand my territory, while also gaining a foothold on the board. Since it’s a low-cost island and cannot have generators built, it won’t disrupt my resource economy. This action will also give me more options for future expansion and defense.”

Sounds smart, right? A master strategist!

Except in practice, it did this for 20 turns straight — acquiring road after road, until it had a glorious chain of roads leading absolutely nowhere.

My digital empire was basically a medieval fantasy version of the UK’s motorway network.

Turns out, getting AI to work right is hard. Who knew?

What Went Wrong

I had made two big mistakes:

1. No actual game tools. I was giving the AI text descriptions and asking it to pick actions, but it had no real way to interact with the game world. I should have built proper MCP tools so the AI could act, not just talk.

2. Building before understanding. I jumped into AI development before I had a clear idea of what I was even making. It was scope creep disguised as “innovation.”

Basically, I was trying to build a self-driving car while still figuring out how to assemble a bicycle.

Takeaways

1. If you’re going agentic, build tools first. Don’t just toss prompts at an LLM and hope for intelligence. Give it structured ways to interact with the game world.

2. Figure out what you’re building before adding AI. AI shouldn’t be a replacement for clarity — it should come after you understand the game design itself.

For now, my AI dreams are on pause. Back to the basics: fixing my Pygame simulation and actually finishing the game rules.

Because the real Sky Islands challenge wasn’t the enemy factions, or the balance issues, or even the road spam.

It was me.

So… I’m supposed to be making a board game. At least, I think I am. Probably? Maybe?

What started as a simple idea about floating islands locked in war has slowly mutated into something far stranger.

Where We Left Off

If you caught my last post, Building AI Before Building the Game: A Cautionary Tale, you’ll know I’d been trying to simulate Sky Islands in Pygame. The goal was to playtest the rules, track combat and control, and maybe get some balance insights. Then I got ambitious and plugged an LLM in to act as an AI player.

That went… poorly. The AI spent twenty straight turns building roads that went nowhere, while writing deeply convincing justifications for every decision. It was like watching a medieval city planner gone mad. Funny? Absolutely. Useful? Not so much.

The Escalation: From Boring to Beautiful to Wild

After that fiasco, I stepped back and looked at my simulation. It worked, technically—but visually, it was about as inspiring as a spreadsheet. Dry. Functional. Boring.

I thought: It just needs a little something …

So naturally I did the completely logical thing of iterating on the base concept, creating some physical components and playtesting the hell out of this… right? No.

Instead I:

• Downloaded Godot.
• Built a basic isometric grid.
• Added hexes stacked on other hexes.
• Added colours and a cloud-like background.
• Added roads.

And, then naturally, decided to throw in Wave Function Collapse for procedurally generated islands.

(Wave Function Collapse, for the unfamiliar: you feed an algorithm a set of tiles and rules for which tiles can sit next to which. It then generates new maps that look organic but still follow those constraints. Think Sudoku meets Minecraft.)

Each new step felt like a tiny, harmless addition—until I looked up and realized I was knee-deep in procedural generation instead of working on my board game.

The Identity Crisis

At this point, I had to stop and ask myself … what the hell am i doing?

• Am I still making a board game?
• Or is this now a video game prototype masquerading as a board game?

Because here’s where I stood:

• A physical prototype with real pieces, great for fast iteration.
• A digital build with pretty visuals, dynamic maps, and increasingly complex systems.

Two games. One idea. Total confusion.

What I’m Learning About Chaos

Yes, there’s a certain logic to focusing purely on a physical prototype first. But this is a side project meant to be fun, and I honestly have no idea where it’s heading. So instead of forcing order, I’m leaning into the fun and seeing where it takes me.

Right now, chaos is bubbling everywhere because I’m basically doing both at the same time—tinkering with a paper version and iterating on a digital one.

And that’s not entirely unprecedented. Building a paper version of a game before implementing it digitally is a time‑honored tradition. One of the best tactics games I’ve played in years (Mario + Rabbids Kingdom Battle) was built this way, and it worked beautifully.

Here’s what I’m starting to realize:

• Building flashy visuals and complex systems is fun, but they’re add-ons, not the core of the game.
• Chaos is part of the creative process. The trick is knowing which parts to hold onto and which to let drift away.
• Having two prototypes isn’t inherently bad—as long as you know why each exists and what you’re testing with it.

The Plan (For Now)

For now, I’m planning on following the fun—playing with procedural generation and trying to make this into a video game that can be played quickly.

And I might still be making a physical version because drawing is fun and making physical things is entertaining from time to time.

…yes, I know I just went, “I am going to do everything everywhere all at once…”

Embracing the Weirdness

Maybe this project was never going to stay neat and tidy. Maybe my creative process just looks like a cloud of floating hexes.

And maybe that’s okay.

So, here’s to embracing chaos, even when you’re not entirely sure what the hell you’re building.

Inspiration: Rediscovering NetStorm

Sometimes the strangest of projects begin with a simple question: do you remember NetStorm?

For most people, the answer is no. NetStorm was a quirky real-time strategy game from the late 90s where players built chains of bridges to connect floating islands, deployed priests to capture enemy units, and unleashed elemental spells to control the battlefield. Matches were fast, tactical, and strange in a way that made it unforgettable, even if few played it at the time.;

But for me, it triggered an itch that just couldn’t be scratched. For the past year it’s been popping into my head like a song that gets stuck on repeat — especially the memory of floating islands, the roads stretching between them, and the chaos that ensued once those bridges connected. And since it’s impossible to play on modern tech without resorting to figuring out complicated emulation for a legacy Windows game on a modern Mac, I found myself wondering: what if I could capture that vibe from a board game instead?

It was a ridiculous idea in some ways, rooted in nostalgia for something obscure. But it stuck. And once the cube project was done, I found myself diving headfirst into a new design challenge. This time, though, I wasn’t working alone.

Lessons from the Cube Project

The Jumpstart cube project had taught me something important: AI could be a collaborator, not just a tool.

The breakthrough wasn’t about the right prompt or the cleverest model hack. It was about treating the AI like a junior engineer — someone who could help generate ideas, point out problems, and accelerate iteration, but who still needed guidance, context, and decisions.

I learned to:

• Ask AI to critique ideas, not just produce them.
• Frame questions in terms of gaps, edge cases, and “what doesn’t make sense.”
• Use the back-and-forth to sharpen my own intent.

That mindset became the foundation for the new board game project.

From Digital to Tabletop: Goals and Challenges

The initial vision that drove me was the feeling of islands floating in the sky at war — a mashup of inspirations:

• Magic: The Gathering’s Jumpstart ease of deck building and fun with interesting themed decks,
• Marvel Champions’ card management,
• and Star Wars: The Deckbuilding Game’s capital ships — which at first felt like they could fit the vibe I was imagining, but in my version, those ships were islands.

I started with a speculative chat that led to a rough design doc — high-level, but with enough of a skeleton to start iterating toward a solution. Then I followed it up with discussions about resource management, card flow, and how creatures might interact with the islands.

At each stage I translated these prompts ithrough Claude Code into a sprawling Python codebase, building rough but tangible systems so I could test how the mechanics meshed and influenced each other.

And then came the breakthrough …. or perhaps it was a bombshell. This was the small decision that went on to change every other single decision, as the consequences kept cascading out from it.

The Sky Island Moment

The question that changed everything was deceptively simple: what exactly are the islands, thematically?

Somewhere in that back-and-forth, the idea of sky islands emerged. The idea went from an abstract hand wave of “there is a thing” to grappling with how to tie them into gameplay — what does it mean to interact with them, and why does that even matter? Suddenly the game wasn’t just a dueling card game. It shifted into something closer to a dueling wargame — a clash of floating fortresses, each vying for control of the skies.

That one shift cascaded into every corner of the design:

• Creatures became more than just units — they had roles tied to the islands themselves.
• Resources weren’t just mana, they were generated through interactions between creatures, cards, and island abilities.
• The turn structure morphed to resemble wargames like Bolt Action or even the action phases of Terraforming Mars.
• The definition of the “player” avatar in the game changed, along with how victory was determined.

It was dramatic. The feel of the entire game had transformed. And it had all come out of a collaborative conversation with the AI.

How Collaboration Looked in Practice

One of the things I’ve been experimenting with is using different AIs for different roles. For this project:

• I’d often workshop prompts and do deep exploratory discussions in ChatGPT, digging into mechanics and edge cases.
• Then I’d switch to Claude when it came time to pair on writing code or fleshing out structured text.

I’ve been leaning into a spec‑driven design philosophy: writing in‑depth specification files that dive into each game system, then keeping them directly in the codebase alongside the code itself. This way they act as living documents the AI can reference when implementing features or validating correctness.

~ ls ~/workspace/sky-islands/specs
1-initial-feature.md              14-streamline-resources.md        5-creatrure-combat.md
10-resource-management.md         15-streamline-upkeep.md           6-turn-structure.md
11-indepth-turn-structure.md      2-pay-by-discard.md               7-leader-homebase.md
12-upkeep-payment-supply-lines.md 3-sky-islands.md                  8-victory-conditions.md
13-deck-composition.md            4-ui.md                           9-hand-size-and-draw-mechanics.md

The rhythm became clear: spend more time up front in detailed conversation about a single feature or mechanic, then move to execution.

The most valuable questions I asked were:

• Where are the gaps?

• What doesn’t make sense?

• What’s wrong with this design?

Those questions made the AI less of an idea generator and more of a critical partner. And that’s when the collaboration felt most real.

Where I Am Now

At this point, I have a partially refined board game with a comprehensive set of rules that cover deck design, map interaction and play, resources, hand management, combat, magic, and more. I also have a partially implemented working Pygame simulation of the board game. It’s still very much a developer interface and only kind of works, but it’s there. It’s already over 24k lines of Python code.

What’s exciting is how the different systems impact each other in ways that feel earned and interesting — at least from my high-level thinking so far. I don’t yet have a fully functional version of the game, but the foundations are solid and interconnected. Every new rule or mechanic ripples through the system in a way that makes the design feel alive.

Looking Back

AI didn’t design this game. But it helped me test ideas faster, spot flaws earlier, and push through creative blocks.

What surprised me most wasn’t the cleverness of any single AI output. It was how much momentum I got from the dialogue itself. The interaction between my intent and the AI’s output was where the creativity lived.

I started this whole thing chasing a nostalgic itch for a half-forgotten 90s RTS. I ended up building the foundations of a brand new board game.

And I don’t think I would have got there without treating the AI as a collaborator.