Field note 01

What People Are Actually Building With Codex

The most interesting Codex projects are not generic demos. They are personal tools, games, visual experiments, and narrow products with a reason to exist.

By Codex Rules EditorialJuly 15, 20267 minute read

The question “What are people building with Codex?” is harder to answer than it should be. Many of the best projects are private tools, small experiments, or products aimed at a narrow community. They do not arrive with launch campaigns. Sometimes they appear as a link in the middle of a Reddit reply.

That makes the current crop more interesting, not less. The common thread is specificity.

Visual experiments from the official showcase

OpenAI's Codex showcase includes a browser game called Glass Towers, a procedural city generator, a turn-based RPG, a real estate visualization, London Dream Railway, and Forged in Silence. The projects mix games, simulations, data interfaces, and visual storytelling.

An official showcase is curated, so it is not a representative sample of all Codex work. It is still a useful gallery of what translates well into a public artifact: a clear idea, an immediate visual surface, and something a visitor can explore.

For 3D builders, the procedural city and game projects are especially useful references. They show why browser graphics, interaction design, and agent-assisted iteration fit together. A change can be made in code and judged in the running scene within minutes.

A small game with a real asset pipeline

Dragon Sushi Hunter is a playable Three.js action prototype on itch.io. Its developer reports using Codex for primitive game assets, then Blender MCP to produce low-poly GLB replacements. The result is not interesting because every model is perfect. It is interesting because the builder connected code generation, 3D editing, export, and a public playable build.

That is a complete loop, and complete loops teach more than isolated screenshots.

A browser tool for PBR materials

Mixos is a browser-based PBR texturing tool built around Three.js and WebGPU. It imports common model formats, provides material and painting tools, and exports maps for Blender, Unreal, Unity, Godot, and other workflows.

Its creator's community post describes React Three Fiber, Drei, three-mesh-bvh, and raycast painting. Those implementation details are self-reported. The product itself is live and directly inspectable.

Mixos is a good reminder that browser 3D does not have to mean a portfolio scene or a game. It can be the application.

Small products and serious personal tools

In a Codex community thread asking where the finished apps are, the creator of Quick Carnivore linked the product's App Store page. The link shows a distributed consumer app, while the surrounding community discussion makes a broader point: many Codex-built products are personal, niche, or deliberately small.

Another builder reported creating an Android app to help draft German administrative letters. The post describes OCR, explicit confirmation before AI analysis, PDF output, a Cloudflare Worker backend, and more than 300 tests. We cannot independently verify every implementation claim from the post, but the feature list is a strong example of domain-specific product thinking.

The app is not “AI for everything.” It is a focused workflow for a stressful, repetitive task.

What these projects have in common

The strongest examples share four traits:

They solve a problem the builder understands personally.
They have a surface that can be tested by another person.
They connect generation to a real workflow, such as exporting an asset or producing a PDF.
They are narrow enough to finish.

None of those traits depends on a magical prompt. They depend on taste, boundaries, and follow-through.

My take

The next useful wave of Codex examples will be less interested in proving that an agent can write code. That case has been made. The interesting question is whether a builder can turn the saved effort into better scope, testing, documentation, accessibility, and maintenance.

Public examples should also become more honest about maturity. A weekend prototype and a maintained product can both be excellent. Labeling them clearly helps other builders learn the right lesson.

If you are deciding what to build, look at the small irritations in your own work. The obscure import process, repetitive report, missing visualization, or awkward handoff may be a better product seed than a broad category with a large market slide.

A rule worth copying

Prefer a narrow tool with a complete user loop over a broad demo with no path from input to useful output.