My AI-Built Game Passed 55 Tests. I Still Couldn’t Call It Finished.

I handed a web game to AI: write the code, build the screens, add features, run the tests.

The report came back: “55 tests passed.”

Technically, that sounded excellent. Then I opened the result.

It worked—but the first screen felt more like a link directory than a game.

Passing tests did not mean I had something people would want to play.

What did those tests actually guarantee?

Tests can prove that a button opens the correct screen, data saves correctly, required text appears, and errors do not occur.

But a button working is not the same as a button being tempting to press. Text rendering is not the same as text being worth reading.

Software correctness and player enjoyment are different problems.

I wanted a village, not a directory

One project I’m building is a small interactive village. I wanted houses you can touch, residents who seem to live there, a cat wandering around, and small differences when you return.

The first prototype technically contained the information, but it did not feel like visiting a world.

I wanted an experience of entering a village, not a website explaining a village.

A GitHub PR is not a playable game

AI coding tools often return a Pull Request URL. That is useful for reviewing changed files and diffs—but it is not necessarily where the game can be played.

A PR URL, a preview URL and a production URL are three different things.

I previously wrote about another version of this problem here: My Web Game Worked on My PC but Broke on Phones.

A preview URL is still not the end

A preview can exist while being protected by authentication or inaccessible to the person who needs to review it.

I now separate three milestones: code completed, working preview completed, third-party operation verified.

Desktop success does not guarantee mobile success

On phones, buttons may be too small, text may overflow, layouts may break in landscape, and controls may feel awkward.

Passing desktop tests does not prove a mobile experience is good.

Separate AI work from human judgment

“Finish the game” is too vague. Implementation, automated tests, preview deployment, hands-on play, fixes and production release should be separate stages.

Give AI a definition of done

I now want instructions like: do not stop at code and tests; provide an interactive preview; check desktop and mobile portrait/landscape; report what could not be verified; do not merge or publish to production automatically.

How do you test fun?

Automation can test whether the game launches and reaches the ending. It cannot reliably answer whether the first ten seconds are interesting, whether the next scene feels worth seeing, or whether the text is tiring.

Unintended friction has to be separated from intentional challenge.

Completion rate is not the same as enjoyment

Analytics can track starts, progress and completion. But someone finishing a demo does not prove they liked it.

Behavioral data and actual feedback need each other.

AI changes the human job

AI can help with code, art, localization and tests. The human job increasingly becomes deciding what to make, defining completion, reviewing the result and asking one final question: would I actually want someone to play this?

Being able to build is no longer enough

Building something and making something people want to play are different achievements.

I’m applying that lesson to ORA Quest Sin, a story game I’m still improving.

Play the free ORA Quest Sin demo

I would rather make a game one person wants to keep playing than a game that merely passes 55 tests.