Notes from an OpenAI Builder Session

A little while ago I attended a Build with OpenAI builder session. I had applied, a spot opened up, and I found myself at an event where you build and submit something within a short window of time. I usually just code alongside Claude and Codex at my own pace, so it had been a while since I had to ship a result against a clock.

The session opened with a short talk about where OpenAI is trying to go — less a showcase of models, more a statement of direction. With that context laid down, the builder session began. One moment you're listening; the next, your hands need to move.

What I built#

The challenge was called Codex's Day Off, and the constraint was unusual: build a 60-second experience that Codex itself — not a human — can read, click through, and finish via Computer Use. A screen whose player is an AI.

I had always been the one telling AI what code to write. This time I had to design a screen the AI would use directly.

My entry was Last Green Gate, a static HTML experience where finishing three missions unlocks a locked DND switch. The first mission, Safe Pack, is about packing only what's safe and leaving the secrets behind; Agent Dispatch delegates the remaining work to a helper agent; Inbox Quiet clears the notifications. Finish all three and the gate opens, leaving a line of evidence on the final screen.

No pending fires. No secrets packed. Last green check complete.

Proof that the work is done, no secrets were packed, and the last green check has passed. The hardest part of building it wasn't the functionality — it was the point of view. The audience for this screen is not a person. A human will forgive a vague button label; they fill the gap from context and flow — "ah, this must be the one to press." Codex won't. Every unexplained intent, hidden menu, and ambiguous button becomes a probability of failure.

The results#

The judging was unusual too: Codex ran the entire evaluation as a single session. Round one shortlisted the top ten teams from a project description of 500 characters or less; in round two, Codex entered each of those ten submissions through Computer Use and scored them against the rubric. Experiences built by AI, played and graded by AI.

I didn't expect much after submitting. A single static HTML page with three missions — nothing flashy. But it scored better than I thought. Prizes went to one first-place team, two second-place teams, and three third-place teams, and Last Green Gate made the third-place group. A good feeling.

What stayed with me, though, wasn't the ranking. It was the sense that my whole working order had been flipped upside down while building.

What I took home#

When I code with Claude and Codex, I'm the one catching the AI's mistakes. When a pattern repeats, I tune the harness, set boundaries, run it again. We work together, but I'm the one managing.

This time I had to put that structure down entirely. Codex was the one reading the screen and pressing the buttons; all I could do was design the arena well in advance. Before deciding what to build, I defined what failure meant. With /goal I narrowed the objective to a single sentence.

It has to finish within 60 seconds, be static HTML, involve no secrets or logins, and end with that line of evidence on screen.

Once that boundary was in place, most of my ideas sorted themselves into "good, but out of scope." Every button had to be the next action, every card the current state, and the final screen had to be proof that it was truly over.

And Codex did better than I expected — without leaving me any room to step in.

This is where the tool started to look different to me. Handing everything over worked not just because the AI is good, but because the failure conditions were set up first. Next time I open Claude or Codex, I want to write down the failure conditions before I build anything.