I Built a Video Game. The Domain Wasn't the Constraint.

TL;DR

• Domain expertise used to be the moat. It isn’t anymore, and that changes which problems are worth chasing.
• Three skills replaced it. Tried-and-true engineering architecture, engineering processes applied to AI cycles, and fluency with AI tools that change every few weeks.
• I tested the hypothesis on the cleanest domain I could find. Video games. A field I have never worked in, never studied, and had no opinions about.
• The thesis held, with one honest limit. The three skills get you to a working product. Human craft (UX, audio, art) is what makes a product sing. If I weren’t bootstrapping, I’d be hiring for that layer.
• Cribbage with a metalayer. Kerrberry Games on Steam in a week or two. This post is about the test, not the game.

---

A few months ago I had never built a video game. In a week or two I’ll be playing one with friends, and Kerrberry Games is heading to Steam.

This post is not about the game. It is about a hypothesis I wanted to test, and what happened when I ran the experiment.

The hypothesis. In 2026, domain expertise is no longer the moat it used to be. Not because expertise stopped mattering, but because three other skills moved in front of it. If you have those three skills, and you have ideas, you can walk into a domain you know nothing about and ship something real.

I wanted to test that, so I picked the cleanest domain I could find. Video games. A field I have never worked in, never studied, never had reflexive opinions about. If the three skills carry across, they should carry across here.

The Three Things That Replaced Domain Expertise

The skills are not new. The combination is.

Tried-and-true engineering architecture. Knowing how to break a system into pieces that have one job, communicate through clear interfaces, and can be reasoned about without reading every line. This is the timeless one. It is the same skill that mattered in 1996 and matters now. Nothing about AI changed it. Everything about AI made it more important. When the code is being typed by something that does not know where the boundaries should be, the boundaries have to live in your head and in your spec.

Engineering processes applied to cycles with AI. This is the bridge. The processes themselves are not new either. Specs before code. Tests as the contract. Tight feedback loops. Pattern-matching on prior bugs and encoding the lesson into the guardrails. What is new is applying that discipline to a development cycle where the typing is being done by something that does not push back unless you make it. I have written about this in I Was Wrong About AI, You’re the Broker, Not the Builder, and How to Tell If You’re Using AI Well. All three posts circle the same point. The discipline that used to live in your hands when you were typing now has to live in the spec and the tests. If it does not live somewhere, it does not live anywhere.

AI tool fluency. This is the one with no shelf life. The tools change every few weeks. Plan mode arrived, then subagents, then MCP servers, then persistent memory, then better web fetch, then long-context modes for big codebases. The way I work today is not the way I worked in January, and it will not be the way I work in August. Staying fluent is its own discipline. The people treating these tools as static are already behind the people treating them as a moving target. The gap will widen.

Why a Video Game

This started while I was between client engagements. Unemployed in the most literal sense. I had time, and I wanted to use it to push my AI skills further than I could push them on a client project, where someone else’s domain and someone else’s timeline always shape the work.

So I picked a domain where I had no muscle memory. Video games. No prior pattern recognition. No reflexive opinions about what good looks like. The cleanest possible test of whether the meta-skills actually carry, or whether they only carry when you also have the domain knowledge backing them up.

It started as a proxy. A learning exercise. I did not intend to ship anything. I intended to find out what broke.

Then it got achievable. Then it got fun. Then my aspirations grew. That arc happened over weeks, not at the start. The minute I could see the finish line, the experiment turned into a project, and the project turned into a product.

What the Test Looked Like

The shape of the work was the same shape it would have been for a client.

Pick a game that did not exist on the market. A simple turn-based card game (a cribbage variant) with a metalayer that makes it more replayable than the rules alone suggest. Spec the thing out. Research the framework landscape. Come to a recommendation. Execute against the plan aggressively.

There was an onboarding cost. Learning how to actually run and test the thing in a new toolchain. Building up a stash of memories about where the framework’s quirks live so I would not hit them twice. UI is its own discipline and was the part that asked the most of me. None of that surprised me, and none of it was the AI’s fault. It was me learning a new neighborhood.

There was also an over-engineering moment late in the project. I caught myself bolting something onto the game that did not need to be there. The game was already good. The addition was making it weird. I cut it. That kind of mid-flight scope correction is exactly what the planning discipline is supposed to catch, and it did. Late, but it did.

I am in the final twenty percent now. UI refinement. The game itself works.

Where the Thesis Bends

I want to be honest about a part of this I have been thinking about a lot.

The three skills get you to a working product. They do not get you to a great product. Not by themselves. Great products are touched by humans who care about craft. UX that makes the right thing feel like the only thing. Visual design with a point of view. Audio that knows when to sit back and when to step forward. None of those are skills I have. If I were spending money on this project the way I would spend it on a client project, I would be hiring people for those layers, not prompts.

I am not, because I started this as a learning exercise and I am still bootstrapping it. So I leaned on AI for the design, the audio, the art. Not because I think it is the right answer. Because it was the answer that fit the budget of a thing I was not sure was going to ship.

If you take one thing from this post and you are a builder, take this. The meta-skills replace the need for domain expertise to start. They do not replace the human craft that makes finished work feel finished. If you have something at stake, hire for the parts of the work that have a soul.

What This Means

The constraint moved.

If you are sitting on an idea and the thing keeping you from chasing it is that you do not know the domain, that constraint is looser than it used to be. The three skills are learnable. The ideas are the part that comes from you.

Kerrberry Games on Steam in a week or two. If you like cribbage, keep an eye out.

And if you run a business and you have a problem you have been told needs a specialist to solve, that conversation is worth having again. The specialist part of the answer is doing less work than it used to. The structure of the answer is doing more.

---

David Kerr is the founder of Kerrberry Systems. He builds custom software for businesses that want a partner, not a vendor. Find him on LinkedIn or GitHub.