Grow a toy programming language overnight with a Codex run

Shawn Knight pointed Codex at a small Python language built in ChatGPT and went to bed; about six hours later it reported five new features, a README and seven passing tests.

Done withCodex· Oct 23, 2026

What they did

Knight, who is not a compiler engineer, first built a tiny language in a single ChatGPT conversation, one upgrade at a time: tokenizer, parser, syntax tree, compiler, bytecode and a stack VM, all in one Python file. When it had grown, ChatGPT helped him write a staged brief for Codex. The brief listed five features in order (logical operators, strings, a nil value, a registry of built-in functions, lists), told Codex to keep existing behaviour, avoid a rewrite, keep the stages separate, add tests after each feature, update the docs, write examples and fix bugs it found. A short vision document set the tone of the language. He started the run around 11:30 pm and slept. The folder had no git repository at the time.

How it went

Codex stopped roughly six hours and twenty minutes later, by his memory rather than logs. Its report said all five features were in, plus list indexing, printing and handling of files that start with a UTF-8 byte-order mark, with a new test file of seven tests that passed, a README and two example scripts. Knight says he could not tell whether the work was actually right: he only had the agent's own report and ChatGPT's reading of it. The project later became the Nodus language with a real repository.

Worth knowing

The author is candid that the run proved progress, not correctness. With no version control there was no diff to review, and seven tests say little about a language runtime. If you try this, commit before the run, ask for small commits per feature, and have something other than the agent judge the result. Times are recalled, not logged.

Try it

With Codex· 4 parts to fill in

This repo holds a small interpreted language in [language and file layout]: tokenizer, parser, compiler and VM. Add these features in order, one at a time: [feature 1], [feature 2], [feature 3]. Keep every existing behaviour working, do not rewrite the architecture, and keep the stages separate. After each feature, add tests for it, run the full test suite, update the README and commit with a message naming the feature. Fix any bugs you hit along the way and list them. Stop when all listed features are done and the suite passes, or when a feature needs a design decision from me, and write a report of what changed, what is untested and what you are unsure about.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related