Build a game prototype by speaking to Codex through Typeless

Set up voice input for the coding task

Thanks to Typeless for sponsoring this video. The original product link is Typeless: https://www.typeless.com/?via=ai-luke.

Luke’s May experiment uses Typeless as a voice keyboard while walking, dictating prompts into Codex instead of typing. The project is a GTA-style game prototype. The title is the creative challenge, not evidence that a commercial GTA 6 equivalent was built. The useful question is whether speaking makes it easier to describe a task and continue thinking while moving.

1. Follow the Typeless setup at 1:03 and the coding-dictation section at 2:20.
2. Choose one small game behaviour to describe clearly, including what the player should be able to do.
3. Inspect the dictated text before sending it when names, numbers or instructions matter.

Turn a spoken brief into a testable prototype

The source describes long coding prompts and hands-free feedback. Voice can carry more explanation, but the build still needs an observable goal. A complete sentence about controls or expected movement is more useful than a general request to make the game better.

The first prototype test starts at 5:27. Use that point to compare what was requested with what appears on screen, rather than judging success by how quickly a prompt was spoken.

1. Try the generated prototype and note the exact behaviour that differs from the brief.
2. Dictate the observed problem, the expected behaviour and the part that should remain unchanged.
3. Review the resulting change before giving the next round of feedback.

Compare the later version with the original task

The voice-feedback section begins at 8:34 and the final-version test at 10:05. Follow the progression between those tests: an initial build, concrete feedback and another inspection. The description establishes this iteration sequence, but does not list every implemented game feature or report a controlled typing-versus-speaking productivity study.

If adapting the method for emails or other work, keep the same habit of checking the entered text and the resulting action. The experiment concerns an input method; Codex still supplies the coding work, and the prototype still needs review on its own behaviour.

The takeaway

Use speech to explain the job and the defect precisely, then test the generated behaviour. Faster input alone does not establish a better build.