Inspiration
I wasn't going to enter at all. I got an email about Build Week and it made me curious how Codex actually codes. So I made an empty repo and just told it to build a dart game, to see how it would do.
But the idea behind it was mine. The EngineCore architecture notes and the mathematical idea I call PZO are my own. So I made a second repo and gave Codex those two documents, to see if it could build the kind of system I already had in my head. It built it pretty much the way I'd pictured it. PZO isn't standard math, so it could have thrown it out, or taken it literally and broken the arithmetic. It did neither. It took one useful idea out of it, that changing a visible result shouldn't destroy the information behind it, and left the rest alone. I thought that was really well done.
What got me was that even the first version, with no architecture docs at all, came out clean, and the second one with the documents built a solid backend. That's when I decided to stop just testing and actually build this into a complete app for the competition, on my own rules and my own idea, not just leave it as something the AI put together.
What it does
You type what you want in plain language, and GPT-5.6 picks one thing to do, nothing more. It can throw one dart at a target (single, double, treble, or bull), compare two throwing techniques, take a saved throw and change one thing to see what would have happened, or ask you to clarify if the request doesn't make sense.
The point is that GPT only chooses. It never makes up the physics, the numbers, the scores, or the results. The program does all of that itself, and every result is saved to a ledger that can't be changed afterwards.
Every throw starts from a seed, so it can be replayed exactly the same way later. Two techniques can face the exact same conditions, so the comparison is fair. And when you change one thing on a saved throw, the original stays untouched. The new version is saved next to it, not on top of it. Nothing is ever lost.
There's also a Technical Lab where you can look at the whole history, replay any throw exactly, and see how one small change grew into a big difference over the flight.
How I built it
It's a local desktop program written in Python. Everything it needs to run is in Python's standard library. There are no outside dependencies:
- Tkinter for the window and drawing
- SQLite for the append-only history
- standard-library HTTPS for the optional OpenAI connection
- unittest for the tests
- SHA-256, xorshift64*, and Box-Muller for turning a seed into repeatable random values
The work is split into clear steps. You state a goal. GPT-5.6 picks one action. A validator checks the choice is allowed. The runtime supplies the seed, IDs, time, and storage. The engine computes the actual result. The ledger saves it. The UI shows the result and where it came from.
The Technical Lab works without an API key. GPT makes the natural-language part nicer, but the experiment, comparison, saving, replay, and branching all work offline.
Built with Codex
After that first test, I asked Codex, as an analysis task before writing any code, to look at what I had and propose one feature worth entering. The AI Experiment Director idea was Codex's own proposal.
Once I approved it, Codex built the whole thing from scratch in one main thread using GPT-5.6: the architecture, the engine boundaries, the runtime, storage, physics, UI, tests, replay, comparison, and branching. My job was to set the goals and the rules, review what came back, make the product decisions, and run focused correction rounds. Things like making it hold back from calling a winner when the difference was just noise, keeping targeted throws from messing up the learning, and cleaning up the UI for the competition.
One thing stood out. When I asked for something that wasn't possible within the rules, Codex didn't fake it. It stopped, worked out why it wasn't possible, and suggested the smallest real way to add it.
The repo has timestamped commits and notes on where Codex sped things up and where I made the calls. The Codex feedback Session ID is submitted separately.
Challenges I ran into
The hardest part was learning how to prompt Codex. How it handles things, what it takes into account and what it doesn't. I didn't know that going in, so it took some trial and error.
Figuring out how precisely I had to describe the UI was one of those things. Too vague and it wouldn't come out right, so I kept adjusting how much detail I gave it until it landed.
The other real challenge was the boundary itself. Keeping GPT useful for choosing actions while making sure it never touched the actual numbers or results. Those stay owned by the program.
Accomplishments I'm proud of
I'm proud that I actually reached the goal. The deadline was tight, and I decided to make a complete app that could enter the competition instead of just a demo. Maybe the thing I'm most proud of is that after the very first prompt the pieces clicked, and that's when I decided to enter.
The finished project includes:
- a bounded GPT-5.6 Director that only chooses actions
- deterministic 3D dart physics
- single, double, treble, and bull targeting
- visible learning between throws
- fair technique comparison under matched conditions
- append-only history with exact replay across restarts
- one-change branches that keep both the original and the alternative
- a Technical Lab that works offline
- no runtime dependencies
- 85 passing tests
I also tested the published GitHub repo from a fresh folder using only the README. It installed, the tests passed, and the program launched.
What I learned
What I mostly learned is that Codex is surprisingly good at coding and at following rules. It seems to apply things in a bounded way, it doesn't over-reach. I gave the backend strict rules and it stayed inside them, and even where I gave no rules, it didn't leak business logic into places it didn't belong. The frontend, for example, stayed clean of engine logic even though I never told it to.
The flip side was just as useful to see. Without rules, the frontend grew on its own. Nothing broke, but it expanded more than it needed to. So the rules didn't just prevent mistakes, they kept things from sprawling. That's the part I'll take forward: be clear about the boundaries even where things seem to work fine without them.
What's next for AI Experiment Director
For me, what's next is simple. I'm going to keep using Codex and use it more. I want to learn how it works, find its weaknesses and its strengths, so I can pin it down with rules where it matters and deliberately leave gaps where it can figure things out on its own.
The project could grow too. Darts made the idea easy to see, but the system underneath isn't tied to darts. The same approach fits anywhere you compare strategies under the same conditions. The next step there would be to separate the general experiment engine from the dart part, so other deterministic modules could plug in with their own targets, changes, and measurements under the same rules.
Log in or sign up for Devpost to join the conversation.