What this is
The hands-off version of the simple-and-fast path. Instead of chatting back and forth, you give Codex the goal and let it work, it plans, writes the files, runs commands, and tests in its own environment, sometimes for a long autonomous stretch. When it’s done you have a real project folder, and Revdoku turns that folder into a live site. Good when the thing is more than a single page but you still don’t want to babysit a deploy.
When to pick this stack
- The task is “build me the whole small app or site,” not “write me this one file.”
- You’re comfortable delegating to an agent and reviewing the result, rather than steering each edit.
- You want the speed of agentic building plus a one-step publish at the end.
How publishing works (Revdoku)
Codex leaves you a folder of files; revdoku p . (or the publish action) puts it online in seconds. Choose the access level that fits:
- Public, open to anyone with the link.
- Password-protected, the link plus a shared password.
- Password + email, a password and the visitor’s email, with optional email confirmation to verify them before entry.
You get analytics on how the published project is used, and password + email mode adds per-visitor detail, which email opened it and what they did. The URL stays the same as you re-publish, and a free plan gets you started.
What we’d swap
- Codex → Cursor or Windsurf: if you’d rather drive the agent from inside an editor and watch the diffs.
- Codex → ChatGPT or Claude: when the job is small enough that a chat handing you files is faster than spinning up an agent.
Common gotchas
- Agents can over-build. Be specific about scope or you’ll get a framework-heavy project when a static page would publish more cleanly.
- Review what the agent ran and added before publishing, check for stray secrets, API keys, or server-only code that won’t work as a static site.