I Built an Entire Roblox Game With Codex. Here’s What AI Couldn’t Get Right.

On October 9, 2026, Set & Steal became a public Roblox experience. Looking at the finished listing, it would be easy to tell a very neat story: I had an idea, gave it to Codex, and AI built the game.

The actual story was much messier, and much more useful.

At several points, Set & Steal technically worked. The rules ran. The cards played. A match could reach a winner. It was also crowded, difficult to read, and not always obvious about what a player should do next. The test suite could pass while the screen was still wrong.

That gap between working and understandable became the real lesson of the project. Codex lowered the technical barrier enough for me to direct a game I would have struggled to implement independently. It did not remove the need to make product decisions, watch people play, reject weak interfaces, or decide what “good” meant.

Starting with a game I did not know how to build#

I am a finance student at Michigan State University, not a traditional game developer. I had already been using Codex to build projects, including my personal website, and I wanted to test how far that collaboration could go. Could I use it to move beyond a webpage or small tool and publish a complete multiplayer game?

The idea became Set & Steal, a strategy card game in which players collect property districts, bank cards, charge rivals, and use actions to steal, swap, or defend. I was partly inspired by the fast strategic appeal of Monopoly Deal, but Set & Steal has its own districts, modes, visual identity, mechanics, and implementation. It is not affiliated with or endorsed by Monopoly Deal or Hasbro.

Roblox made the experiment concrete. I was not building a concept deck or a demo that only worked on my laptop. The game would need rules that held up, private and public player flows, bots, timers, a tutorial, and an interface that made sense to someone who had not watched it develop.

From early experiments to a playable system#

I started experimenting with the game in August 2026. There were earlier versions before the more structured September build, so Set & Steal did not emerge from a single prompt or one uninterrupted development sprint.

The repository’s available Git history begins on September 8. By then, the project records a detailed brief followed by architecture, a deterministic rules engine, automated simulations, a playable Roblox Studio match, and early tutorial and multiplayer flows. That was a milestone in an existing project, not the beginning of the idea.

That September implementation phase moved surprisingly fast. When a requirement could be stated precisely—what makes a move legal, what information a bot is allowed to see, or what happens when a timer ends—Codex could turn it into a connected system and test it.

The September 10 build looked like a Roblox world, complete with a city and physical tables. It also made the environment more prominent than the decisions players had to make.

This was not one giant prompt. The working pattern was closer to: describe the behavior, inspect the result, identify the mismatch, write a clearer requirement, and test again. As the game grew, that loop covered property sets, banking, action cards, Shields, bots, multiplayer tables, tutorials, card guides, and eventually Market Rush, a secret-bidding mode.

Codex did not make the technical work disappear. It changed the level at which I could participate. Instead of independently writing every system from scratch, I could spend more time on rules, priorities, player flows, and review.

It also surfaced a harder question: could another person understand what the code had produced?

Functional was not the same as intuitive#

The early city-style lobby was only one version of the interface. By September 23, the rules were playable and the game had more player-facing controls, but selecting a property could open a panel that covered almost the entire table. The action worked. The relationship between the card, the board, and the decision became harder to follow.

By September 23, a single card interaction could cover most of the table—another clear example of why “technically working” was not enough.

Earlier development had already moved away from a literal tabletop-first view, but the same underlying problem kept returning in new forms: small cards, competing panels, excessive scrolling, and screens that contained the required information without establishing what mattered most.

I eventually wrote an explicit redesign rule: gameplay information first, then cards, player boards, interactions, and only then the environment. The match view evolved toward larger cards, visible bank and set counts, opponent summaries, contextual decisions, and a bounded history of recent actions.

That pattern repeated in smaller details. A public-card transfer animation existed in the 3D world, but the interface covered it. The code performed the animation; the player could not see it. The TABLE and HAND controls behaved backward in one iteration. Some action cards looked disabled when they were actually playable. A tutorial instruction called for Rent Doubler while the interface highlighted Rent.

None of those problems was a broken rule. Every one could still make a player choose incorrectly or stop altogether.

Screenshots became part of the specification#

At first, I could ask for a feature. Later, I learned to specify the experience around it.

“Add private multiplayer” became questions about who hosts, what a code does, what happens when the host leaves, and how someone returns to the game. “Improve the tutorial” became a requirement to explain the goal before the mechanics, highlight one legal next action, and avoid covering the card the player needed to tap.

Screenshots became especially important because they captured problems that prose missed. I could show that a menu was visually dominant, that a card looked unavailable, or that a player’s hand had been pushed below the useful part of the screen. The prompt was no longer just an instruction to write code. It was a product brief with evidence.

One of the clearest changes was the front door to the game. The supporting lobby system still mattered, but it did not need to feel like a utilitarian lobby or lead with the 3D environment. I asked for a home-first experience with a clear path from Home to Play to Match to Results.

The later home screen replaced the city-style lobby with one clear promise and one obvious starting action.

The underlying systems did not vanish. The path into a match became clearer.

Beta testing exposed the assumptions I could not see#

The first beta made the gap more obvious. My notes after the session covered roughly 20 issue categories. The tutorial was the biggest barrier. Five-player matches required too much scrolling. It was not obvious enough when a player’s turn began. Private-table controls were confusing. Menus sometimes closed unexpectedly, and card families did not look different enough at a glance.

These findings changed the next set of Codex instructions.

The turn state gained a persistent frame, an explicit “YOUR TURN” message, a high-contrast arrival banner, and a sound. Dense five-player boards grouped districts, scaled cards by table size, and stacked duplicate bank cards. Important menus were changed so routine game updates would not close them.

The tutorial received the most fundamental revision. An earlier version began with a local action: draw two cards. The newer version began with the point of the game: build three different color sets before anyone else. Only then did it explain the card families and move into a guided, untimed practice match.

The tutorial eventually began with the objective—build three different color sets—before teaching the player what to click.

The beta evidence has limits. I did not collect polished participant transcripts, and I would not turn my notes into invented tester quotations. What I can say is that seeing the game leave my own mental model changed the priority list. Features that felt understandable during development were not necessarily understandable on first contact.

Debugging was not always about code#

Iterating with Codex also meant learning that an apparent bug could live somewhere other than the source.

Roblox Studio sometimes held an older in-memory version of the game even after a regenerated file was correct on disk. I could be looking at a supposedly broken screen while Codex was looking at a fixed file. Reopening the correct artifact became part of debugging.

Other problems were unmistakably game-logic or interaction issues. A private-table bot could reach zero seconds and leave the table stuck. A backdrop click could return someone to Home. A property-placement preview once implied a prerequisite that the server rules did not require. Market Rush initially recorded only a bid amount instead of the exact bank cards a player selected.

Fixing one case was not enough. A change had to work for bots and people, public and private tables, and different player counts without breaking the tutorial. Codex could trace the code, add tests, and implement a repair quickly. I still had to reproduce the problem, explain its player-facing effect, and verify that the fix solved the experience rather than only the function.

Publishing was a milestone, not proof of success#

Set & Steal launched on Roblox on October 9, 2026. The public experience included bot play, Quick Play, private tables, a guided tutorial, property districts, banking and charging, steal/swap/defend actions, flexible properties, and Market Rush.

I also created a Founding Player badge for people who joined during the launch period. Ranked play remained, accurately, “Coming Soon.”

A launch-day interaction screen keeps the table visible while focusing attention on one incoming payment decision.

Playing the public version on October 9 produced another bug list. Work continued after the listing was live, and a separate browser edition followed later.

That distinction matters: a game can be published without being finished, and it can be finished enough to play without having proved that people will return.

I do not have a dramatic revenue or player-growth story to attach to the ending, and I do not want to manufacture one. Launch proved that the experiment became a real, public product. Retention, discovery, and long-term success are different questions.

What building Set & Steal changed about how I see AI#

First, AI can make a difficult technical project reachable. I did not become a veteran Roblox engineer overnight, and Codex did not turn development into a button. It did let me direct a large, connected implementation without first mastering every layer on my own. That expands the range of ideas I can seriously attempt.

Second, prompting at this scale looks a lot like product management. The valuable inputs were not clever one-line prompts. They were briefs, priorities, screenshots, acceptance criteria, bug reports, and decisions about which problem mattered next. Better instructions improved the result, but discovering what to ask for required judgment.

Third, faster implementation makes human judgment more important, not less. When code arrives quickly, the bottleneck moves. Someone still has to decide what belongs, notice when a technically correct screen is confusing, listen when players struggle, and reject a solution that satisfies the request but misses the experience.

I would not turn this project into a universal claim that AI cannot design an interface. Codex improved the UI many times after I gave it clearer direction. The limitation I observed was narrower: it could implement an experience, but it could not independently decide which experience was right for these players.

That is what the title means by “what AI couldn’t get right.” The most important work was not only producing the game. It was developing an opinion about the game, testing that opinion against reality, and being willing to revise it.

You can play the browser edition of Set & Steal and see where the iteration landed. If you have used AI to build something outside your formal background, I would be curious to know where the technology stopped being the hardest part and judgment took over.