Claude Code can write an app, fix a broken import, and hand me a working preview. That still does not mean it should decide when the app becomes public.
This is the line I kept coming back to while building drobek. The coding agent should be fast inside the build loop. Publishing should remain an explicit human decision.
Drobek launched on Product Hunt today. The short version fits into 33 seconds:
The useful part is the contract behind the animation.
For the normal path, the agent works through three MCP tools:
create_app
-> starter, app ID, briefing, preview URL
write_files
-> immutable version, compile result, preview URL
publish
-> the selected compiled version becomes public
create_app gives the agent a compiling starter and the rules of the environment. write_files applies the changed text files and runs esbuild on the server.
The response includes compile.ok. If the build fails, it also includes the file, line, column, and compiler message. The agent can use that result for its next edit without opening another terminal or asking me to paste an error back into the conversation.
A failed build is still kept as a version. The preview continues to serve the latest version that compiled successfully.
This is a small detail, but I like what it does to the workflow. A broken edit becomes something the agent can inspect and repair. It does not replace the working preview, and it does not erase the attempt.
I still open the preview.
A green esbuild result tells me the imports and syntax survived. It does not tell me that the button makes sense, the mobile layout works, or a destructive action is safe.
The preview URL follows the newest successful build:
https://<slug>--preview.drobek.app
Production stays on its current version while the agent keeps editing. When I am happy with a particular compiled version, I ask the agent to publish it.
That final request matters. The Drobek agent instructions say to call publish only when the user asks. The OAuth grant also separates read, write, and publish scopes, so a client does not need deployment access just to inspect an app.
Once published, the app gets its normal address:
https://<slug>.drobek.app
Publishing an older compiled version moves production back to that code. It does not rewind the app's stored data. Preview and production share backend data, so I treat rollback as a code operation, not a database undo button.
The app's JavaScript runs in the browser. Drobek compiles and serves it.
Backend capabilities come from modules installed by the server operator: authentication, data, forms, email, files, and controlled API calls. The agent can use the documented module contracts through skill_info, but it cannot upload arbitrary server code or install a private npm dependency for the app.
That boundary is deliberate. I wanted agents to build small tools quickly without turning every generated frontend into a new server process I now have to trust and operate.
It also keeps secrets out of the generated files. For an external API, the owner enters the credential in the dashboard. The proxy uses it on the server. The browser app and the coding agent do not receive the value.
I am happy to let the agent make several versions, read compiler errors, and improve the preview. Those are fast, reversible steps with visible output.
Making a URL public is different. That is where I want one boring sentence from me: publish this version.
The public core is AGPL-3.0 on GitHub, and the hosted service is available at drobek.app. If you use Claude Code, Codex, Cursor, or Claude to build small browser apps, I would like to know where you draw the publish boundary.