AI Built My Game -- Then the Art Got Weird

Dev Leader Weekly 159

Oct 04, 2026

TL; DR:

AI agents need scoped, reviewable slices
Autopilot still needs experienced checkpoints
Expertise matters most at the boundaries
Join me for the live stream (or watch the recording) on Monday, October 5 at 7:00 PM Pacific!

Building a Game With AI Is the Easy Part

I got into software development because I wanted to make games. That was the original spark for me, and even after more than 20 years of programming, I keep coming back to it.

One of my role-playing games has been evolving on and off for roughly two decades. Another project, currently called EVO: Habitat Zero, is a creature breeding and caretaking game inspired by something I played as a kid. These are not the only things I am building either. I still have BrandGhost moving full speed ahead, a SQL workbench project called Skweel, and a secure agent-to-agent communication platform in progress.

Why keep all of these projects around? Because side projects give me a place to explore ideas that matter to me. They let me test technology, architecture, product decisions, and now AI-assisted development without pretending every experiment needs to become a polished business.

The interesting part is not that an AI agent can generate code for a game. We already know these tools can generate code. The interesting part is what happens when you give one a backlog, let it run on autopilot, and then discover where your own judgment is still doing the real work.

You can check out my full thoughts on this in the video below:

Start With Decisions, Not a Giant Prompt

I did not begin by telling an agent, “Go make me a game.”

While I was traveling, I used ChatGPT to talk through the high-level mechanics and capture the decisions in Markdown. I chose Unity. I wrote down architectural ideas. I described how the creatures should behave and how the player should interact with the systems. This was not a giant specification with every detail locked down. It was enough context to establish direction.

Then I handed those files to Astra and asked it to do three things:

Decompose the design into high-level GitHub issues.
Put those issues into a sensible implementation order.
Deliver the game through small vertical slices.

I was also explicit about what not to do. I did not want every issue fully specified up front. When an issue was ready to be worked, the agent could break it down with the latest context instead of following a stale plan written weeks earlier.

That distinction matters. A huge prompt can produce a huge amount of output, but output is not the same thing as progress.

Actionable Tip: Give your agent enough context to make the next decision well. Do not force it to predict every decision for the rest of the project before the first useful slice exists.

Build the Smallest Thing You Can Inspect

The implementation plan started with questions I could answer by looking at the game:

Can Unity display a creature?
Can that creature animate?
Can it move through the scene?
Can its animation change with its internal state?

Each answer moved the project forward. More importantly, each answer gave me something concrete to inspect.

This is exactly why I like vertical slice development as a way to deliver useful behavior incrementally. The agent was not spending weeks building disconnected infrastructure and promising that a game would appear eventually. It was producing visible, playable behavior.

There is a tradeoff here. Horizontal groundwork can be necessary. You still need systems that support future features. But when an agent is generating a large amount of code quickly, vertical slices create feedback points before the volume gets away from you.

Fast code generation makes short feedback loops more important, not less important.

Autopilot Does Not Mean Unattended

I have let Astra work through the backlog on autopilot. That sounds like I handed over the repository and disappeared, but that is not what happened.

I check in regularly. I ask it to open Unity to a scene that demonstrates the latest functionality. While the main session continues working on the next slice, I can see what has actually changed in the game. Every check gives me evidence instead of a progress summary.

That is the part people can miss when they hear “autonomous agent.” Autonomy changes how often I need to type instructions. It does not eliminate accountability.

The workflow is closer to:

Give the agent a bounded objective.
Let it implement and validate the slice.
Inspect the behavior in the real application.
Correct the direction while the change is still understandable.
Continue only when the project still makes sense as a whole.

I use the same philosophy when I am delegating real work through agentic development workflows. The point is not to hover over every generated line. The point is to establish boundaries and feedback loops that make drift visible.

Actionable Tip: Ask the agent to demonstrate the feature in the environment where users will experience it. A written summary is useful, but it is not proof that the software works.

The Playable Test Case Surprise

One of those check-ins exposed something awkward.

The agent had been delivering the vertical slices as separate demo scenes. Each scene showed that a capability worked, but they did not yet feel like one cohesive game. It was almost like I had a collection of playable test cases:

One little experience for this mechanic
Another little experience for that mechanic
A different scene for the next capability

Was that wrong? Not entirely. Those scenes made the behavior easy to isolate and verify. They were useful artifacts.

But they were not the product I had in mind.

So I asked whether the roadmap included bringing those pieces together into the actual gameplay experience. It did. The agent could explain where that integration work belonged and why the current phase was still focused on isolated mechanics.

That was a good answer, but I only got it because I noticed the gap and asked.

This is where your role shifts. You are not just reviewing syntax. You are reviewing whether the implementation strategy still leads to the intended outcome.

Your Expertise Sets the Ceiling

The software side of the project has gone well. I have been programming for more than 20 years, and I am comfortable evaluating architecture, behavior, and implementation choices.

The art side? That has been a different story.

I am not a 3D modeler. I do not have deep experience with game materials, textures, or professional art direction. So I gave the agent a vague version of “make professional game assets and do not make mistakes.”

You can probably guess how that went.

It produced a space station interior. It made creature models. It checked boxes about polygon counts and materials. It was also hilariously bad. One creature started as a strange-looking fox and somehow became a compressed, ball-shaped version of that fox. The agent was proud of the result. I was trying to understand how we had arrived there.

The problem was not simply that the model failed. The problem was that I lacked the domain expertise to give it a strong target and evaluate the process early.

This is one reason I keep coming back to the question of what developers should retain when AI can write more of the code. Your judgment, taste, and ability to recognize a bad direction become more valuable as execution gets cheaper.

AI can amplify expertise. It can also amplify ambiguity.

Better Inputs Beat Louder Instructions

My next move is not to yell “make it professional” more forcefully.

I need to give the art agent better references. That might mean finding a high-quality texture that communicates the material I want, providing a model that demonstrates the proportions, or assembling a small visual language the agent can follow.

I do not want the final game to look like a pile of unrelated free asset packs. But a reference asset can establish the direction in a way that paragraphs of vague adjectives cannot.

This is not unique to game art. Templates, examples, constraints, and known-good starting points help agents reason about the result you actually want. I have seen the same thing while feeding AI workers reusable project templates. The fancy orchestration is useful, but a strong foundation often creates the biggest improvement.

Actionable Tip: When an agent repeatedly misses the mark, stop adding adjectives. Give it a concrete reference and define what should be preserved, changed, and validated.

Keep the Agent Fast and the Feedback Faster

I am genuinely excited by how much of Evo Habitat Zero has come together while an agent works through the backlog. Seeing new mechanics appear in Unity is fun. Watching the art agent confidently produce nightmare fuel is also fun, just in a very different way.

But the biggest takeaway is not “AI can build games now.”

It is this:

Give the agent clear direction, small slices, concrete references, and frequent opportunities to prove the work.

Let it move quickly where you have the expertise to evaluate the result. Slow down where you do not. Bring in stronger references or actual domain experts when your own judgment cannot reliably close the gap.

That is not a limitation of agentic development. That is the discipline that makes it useful.

Dev Leader Weekly

Discussion about this post

Ready for more?