Inspiration
AI coding is powerful, but the people who shape products often get blocked before the first useful prompt. Product managers and designers may never get past Git, folders, language runtimes, OAuth, local servers, and broken builds.
They already know a better interaction model: open Figma to design, open Notion to write, and share the result. I wanted live product planning to work the same way. A conversation should not end in a document or mockup. It should become the running product.
PPP follows a longer lineage. Emacs put a Lisp interpreter at the center of an extensible document tool. Lisp has been called a programmable programming language. nREPL lets other interfaces inspect and change a running environment. During the Deep Space 1 Remote Agent experiment, engineers used a spacecraft Lisp REPL to diagnose a wedged scenario and inject the event that let it continue. PPP brings that live-programming idea out of the terminal and into a familiar browser workspace.
What it does
Programmable Programming Page is a conversation-first workspace where a product manager or designer can change a running full-stack product without seeing code, files, Git, models, Skills, or MCP.
A turn can:
- answer without changing the product;
- ask one focused clarification;
- generate and activate a full-stack change;
- restore an earlier source-plus-data checkpoint.
Accepted changes can replace the canvas, sidebar, CSS, browser interactions, server actions, business rules, domain tests, and SQLite schema. The requesting browser stages the candidate inside a fresh opaque-origin sandbox while the JVM stages generated Clojure and a copy of the database. PPP commits only when the exact client and server version both succeed. A rejected candidate leaves the last successful product unchanged.
The result is not an opaque mockup. Every accepted state has real CLJ, CLJS, CLJC, CSS, SQL migrations, tests, persistent SQLite data, append-only history, and recoverable checkpoints that a developer can continue.
Why this is more than hot reload
Hot reload watches a developer's saved file and replaces a module in an existing development environment. PPP starts from a product conversation, generates the source, evaluates and tests the client/server/SQL boundaries, renders the candidate in isolation, and advances browser behavior, server logic, SQLite, history, and checkpoint as one product version.
The public proof uses SCI-evaluated transactional hot swapping. It does not pretend that Codex currently connects through nREPL. The repository also contains a trusted development-only Workspace REPL profile in which Codex attaches through a project-scoped nREPL, inspects and redefines real JVM Vars used by the action router, invokes actions against SQLite, and reconciles accepted behavior back to source and checkpoints.
Live demo
The submitted film uses one fresh project on the current public judge server and the real OAuth Codex provider with GPT-5.6 Terra at medium reasoning.
- A conversation turns the blank canvas into a polished dark arcade.
- The next turn adds playable Snake with a real browser timer and keyboard input.
- A full-stack turn adds product signup and sign-in plus a SQLite-backed public profile while preserving Snake.
- The film submits an invalid identifier and shows the generated actionable error, creates Player One, signs out, signs in, and reloads. The account and game remain because they are real server actions and durable workspace data.
- One final product decision creates a Game library and adds timer-driven, keyboard-controlled Tetris without losing Snake or the account.
Provider waits remain part of the continuous real capture and are truthfully accelerated at 30x. The deterministic fake provider is only CI infrastructure and does not appear in the film.
Architecture and safety
PPP is one JVM Clojure application serving a ClojureScript host.
- Clojure, http-kit, Reitit, and Integrant form the fixed kernel.
- SCI evaluates generated Clojure inside explicit namespaces and capabilities.
- Reagent and browser SCI run generated UI in a disposable opaque-origin iframe.
- SQLite and next.jdbc provide one durable database per project.
- A versioned WebSocket protocol coordinates server staging, hidden browser rendering, exact request-tab acknowledgement, commit, and broadcast.
- Append-only filesystem history and SQLite snapshots provide checkpoint restore and crash recovery.
- The Linux amd64 Docker image runs non-root with separate data and Codex credential volumes.
Generated server code receives no shell, general filesystem, JVM interop, dynamic dependencies, MCP, Skills, host credentials, or unrestricted network. Generated browser code can use normal JavaScript, timers, keyboard input, Canvas, and WebAssembly only inside the untrusted sandbox frame; it cannot reach the authenticated parent, cookie, session transport, recovery controls, or other projects.
Product authentication and workspace data belong to the generated product boundary, not the PPP Control Plane. In the intended isolated-capsule architecture, Codex may inspect and replace product auth, account rows, password hashes, and application logs while PPP access, owner OAuth, host state, and other workspaces remain unreachable.
How OpenAI was used
Codex and GPT-5.6 were used throughout the project: product planning, architecture, Clojure and ClojureScript implementation, browser and SQLite verification, deployment, presentation design, English narration and captions, this film, and the live product agent on the public test server.
At runtime, PPP sends the current complete source tree, bounded conversation context, runtime version, and capability catalog to codex exec through stdin. GPT-5.6 returns one schema-constrained reply, clarification, change, or restore. PPP then validates paths, syntax, capabilities, SQL, quotas, generated domain tests, server execution, hidden browser rendering, and exact version acknowledgement before activation.
If a generated product later fails, PPP preserves a bounded, redacted reason from the active sandbox. On a relevant next turn, Codex can inspect that volatile evidence through an isolated diagnostic Skill. Ordinary prompts remain free of telemetry, extension noise is excluded, and raw model reasoning is never streamed into the product UI.
Challenges and lessons
The hardest part was activation, not code generation. Browser and JVM runtimes must agree on one version while source and data remain recoverable. That led to the two-phase browser/server/SQLite protocol.
Real owner testing changed the architecture. Cold-frame timeouts, Korean IME corruption, over-restricted browser interop, generic failure messages, missing client diagnostics, and model-output variance all became explicit runtime contracts and regression tests. User reproduction always outranked a narrower synthetic pass.
Hiding code does not mean discarding engineering structure. Complete source, domain tests, manifests, and checkpoints make the nontechnical experience safer and give developers a credible handoff.
Current limit and destination
The public hackathon build is intentionally one shared-password workspace on one JVM, using the owner's Codex OAuth capacity. Raw host nREPL, shell, and dependency loading would expose PPP itself and every public project, so the judge profile uses bounded SCI capabilities and atomic staging.
The destination is one disposable Workspace Capsule per project: real source, shell, dependencies, database, server nREPL, browser CLJS REPL, product authentication, and diagnostics. Codex works REPL-first inside that isolated project while the external Control Plane protects credentials, the host, and other workspaces. Accepted live definitions reconcile into source, tests, data, and developer-readable history.
That is the future this project argues for: product conversations become running software, and the running history becomes the developer handoff.
Log in or sign up for Devpost to join the conversation.