Anticode Open builder

How to edit an AI-generated website locally and sync it back

Pull the project into a folder, edit its spec file in your own editor or let a coding agent do it, push the change back, and publish from the command line. With Anticode's CLI the page is rebuilt from the spec each time, the open builder picks up your change, and publishing still has to pass the server's security gate.

Updated · By the Anticode team

Why work locally at all

A browser builder is quick for visual changes, but some jobs suit a text editor better: rewriting every section's copy in one pass, search-and-replace across a site, keeping the project in Git, or handing the work to a coding agent such as Claude Code or Cursor that reads and edits files. Editing locally also gives you a plain-text record of what changed, which is easier to review than a series of clicks. Below is how to edit an AI-generated website locally with Anticode's CLI, from sign-in to publishing.

What you edit, and what you don't

It helps to know the model first. Anticode doesn't store your site as hand-written HTML. It stores a spec: the site's name, kind, design direction, sections, their order, the text in each, theme tokens and features. The design engine turns that spec into the HTML that ships. So locally you edit the spec, and the CLI regenerates index.html for you to look at. Changing index.html directly does nothing; it's overwritten on the next push.

spec.json
The build spec. This is the file you edit: text, section order, pages, theme, features.
index.html
The page as it ships, rebuilt from the spec. Open it in a browser to check your change.
anticode.json
Which project the folder belongs to and which version you pulled. Leave it alone.

For coding agents, Anticode publishes /AGENTS.md and a JSON Schema for the project format at /schema/project.v1.json, so an agent can check its edits against the allowed fields rather than guessing.

Pull, edit, push, publish

  1. Install Node 20 or later. The CLI is a single script with no dependencies.
  2. Sign in with anticode login. It shows a code and opens a page where you approve it in the browser. The CLI never sees your password; it stores a personal access token in your user config folder.
  3. List projects with anticode projects, then pull one with anticode pull "Reid's Barbers" (a name or ID), optionally followed by a folder name.
  4. Edit spec.json in your editor. Change a headline's text, reorder the sections listed in order, adjust a colour in tokens. Text is plain text; markup in it is shown literally.
  5. Push with anticode push. The CLI rebuilds index.html, uploads the spec, and the builder, if it's open, redraws with your change and offers an undo.
  6. Check index.html in a browser, at phone and laptop widths.
  7. Publish with anticode publish, adding --slug yourname the first time to choose the address. It pushes first, then publishes; if any security check fails, it lists them and nothing goes live.

What protects you along the way

  • Version conflicts are refused, not merged. If someone changed the project in the builder after you pulled, push stops with a conflict message. Save your spec.json elsewhere, pull again and re-apply your edits.
  • Every push is a version. Saves from the CLI appear in History labelled as coming from the CLI or a coding agent, so you can restore the version before if a change goes wrong.
  • The security gate runs on the server. Publishing re-runs the checks that matter once a page is public, such as scripts, inline handlers, form targets and HTTPS, so editing locally can't bypass them.
  • Local edits don't use model builds. Pushing a spec you changed by hand regenerates the page with the design engine rather than calling the AI model.

Working with a coding agent

Point the agent at the pulled folder and tell it to read AGENTS.md first. Give it one change at a time ("rewrite the services section for a mobile-only business"), then read the diff before you push. Keep the CLI token out of any file you commit, and if you put the folder under Git, add nothing that holds the token. If you'd rather not touch files at all, an assistant can make the same changes through Anticode's MCP server.

Common mistakes

  • Editing index.html and wondering why the change vanished.
  • Leaving the builder and the CLI both editing the same project for an afternoon. Pull before you start each session.
  • Adding fields the schema doesn't list. The project schema sets out the allowed fields; check against it, or have the agent validate its edit before you push.
  • Sharing the token. Each machine should run its own anticode login. Revoke a machine's token with anticode logout on that machine, or from Account menu, CLI access.

Limits

You edit within the spec, so the result still comes out of Anticode's design engine: you can't hand-add arbitrary elements, scripts or CSS. If you need full control of the code, export the site as Next.js and push it to GitHub, where it becomes an ordinary codebase without Anticode's sync.

Questions people ask

Can I edit the site in VS Code?

Yes. Pull it with the CLI, open the folder in VS Code and edit spec.json. Push when you're done.

Does pushing from the CLI use my build allowance?

Pushing a hand-edited spec regenerates the page with the design engine and doesn't run a model build.

What if I break the spec?

Push refuses a spec that doesn't have what the page needs, and History keeps every earlier version to restore.