AI Can Write Code Fast, but Testing Is Still the Bottleneck

AI has changed the way I work on my mini-game.

With tools like GPT, Gemini, and Codex, I can implement features much faster than before. I use AI to help write code, generate configurations, review logic, fix compilation errors, design game mechanics, and maintain documentation.

Recently, I used AI to work on different types of enemies and bosses. Features such as speed bursts, armor changes, summoning, healing, and different boss behaviors can now be implemented surprisingly quickly.

At first, this felt like a huge productivity boost.

And it is.

But after using AI heavily on my mini-game, I discovered something interesting:

Writing code is no longer my biggest bottleneck. Testing is.

AI Makes Implementation Cheap

Before AI coding tools became this capable, adding a new game mechanic meant spending a lot of time thinking about the implementation, reading through existing code, writing the logic, fixing syntax errors, and debugging it.

Now I can describe a feature, provide the relevant context, and let AI handle a significant part of that work.

For example, I can ask AI to add a new boss ability or modify enemy behavior. It can inspect the existing structure, suggest an implementation, update the code, and sometimes help fix compilation errors afterward.

This changes the cost of experimentation.

An idea that I might previously have skipped because it required too much coding is now relatively easy to try.

But there is a problem.

Just because a feature is easy to implement doesn't mean it is finished.

Implemented Is Not the Same as Done

A game mechanic needs to be experienced inside the game.

Does an enemy move too fast?

Does the boss heal too much?

Does a summoned enemy behave correctly?

Does an ability trigger at the right moment?

Does a level create the intended pressure?

Is the mechanic technically correct but simply annoying to play against?

AI can help reason about all of these questions, but ultimately, I still need to launch the game and see what actually happens.

That creates a development loop like this:

Design → Generate code → Compile → Run the game → Test → Observe → Adjust → Test again

AI can dramatically accelerate the first few steps.

It doesn't eliminate the rest.

My Development Time and Testing Time Are Different Resources

This problem is even more obvious because this mini-game is a side project.

I have a full-time job and a family. During the day, I sometimes find small pockets of time that I can use for development.

With AI, those fragments are surprisingly useful.

I can modify some code, work on configurations, review a mechanic, fix compilation errors, or prepare another feature.

But there is an important limitation:

I can't actually run and play the game in my work environment.

Real testing has to wait until I am at home.

And my evenings are not unlimited blocks of development time. There are normal family responsibilities and everyday tasks. Even when I have some free time, I may only have a relatively short window in which I can sit down and properly test the game.

So I have ended up with a strange imbalance:

My ability to produce code has become much greater than my ability to validate that code.

AI might help me implement several features during the day.

At night, I may only have enough time to properly test one or two of them.

The result is what I have started thinking of as testing debt.

AI Can Actually Create More Testing Debt

This is one of the less obvious downsides of AI-assisted development.

When implementation becomes cheap, adding another feature becomes very tempting.

A new enemy mechanic?

Sure.

Another boss phase?

Easy.

A different healing behavior?

Let's try it.

More level configuration?

Generate it.

Individually, each decision feels inexpensive because AI is doing much of the implementation work.

But every new feature creates something else that must eventually be tested.

If five new mechanics are implemented but only one is validated, the project hasn't really moved forward by five features. It has also gained four pieces of unfinished work.

This means that maximizing AI output is not necessarily the same as maximizing project progress.

That was an important realization for me.

I'm Now Building Tools to Make Testing Faster

If testing is the scarce resource, then the obvious response is to make every minute of testing more productive.

I have started adding debug commands that allow me to quickly spawn specific enemies, bosses, or set up game states.

Instead of playing through half the game just to reach one specific situation, I can jump straight to the exact scenario I need to test.

I want to push this idea further.

For each mechanic, the ideal workflow should be something like:

1. Launch the game.
2. Enter a debug command.
3. Immediately spawn the target enemy and set up the game state.
4. Observe the mechanic.
5. Record the result.
6. Change the relevant values.
7. Repeat.

The less unrelated gameplay I have to go through, the more useful my limited testing time becomes.

AI is useful here too.

Instead of asking it only to build more gameplay features, I can ask it to build better debugging tools, test commands, state displays, and shortcuts.

That may produce less visible progress, but at this stage it can actually help the mini-game reach a playable release faster.

I Also Need to Stop Over-Polishing

There is another problem that AI cannot solve for me: deciding when something is good enough.

A game can always be adjusted.

An enemy could move slightly faster.

A boss could have a little less armor.

A level could contain a few more enemies.

An ability could trigger two seconds earlier.

If I try to perfectly tune every number before releasing the game, the project can consume an unlimited amount of time.

For a side project, that is simply not realistic.

So I'm trying to distinguish between two kinds of problems:

Release blockers (problems that prevent the game from shipping), such as broken mechanics, game-breaking bugs, serious balance issues, or incorrect behavior.

And "nice-to-haves" (things that could simply be better), such as minor balance adjustments or aesthetic improvements.

The first category needs to be fixed.

The second category often needs to wait.

Otherwise, "polishing the game" becomes a never-ending rabbit hole.

AI Moved the Bottleneck

After using GPT, Gemini, and Codex extensively on this mini-game, I don't think the interesting story is simply that AI makes programmers faster.

It does.

But software development is a pipeline.

When one part of the pipeline suddenly becomes much faster, another part becomes the constraint.

For my mini-game, AI has reduced the cost of implementation enough that I can clearly see the next bottleneck:

Validation.

I can generate code faster than I can play the game.

I can create mechanics faster than I can judge whether they are fun.

I can add features faster than I can properly tune them.

So my goal now isn't to make AI write as much code as possible.

It's to use AI to help me reach a tested, playable version faster.

That means fewer unnecessary features, better debugging tools, shorter testing loops, and a stricter definition of what "done" actually means.

AI didn't remove the hard part of game development.

It moved the bottleneck.