How designers and developers collaborate on a website without overwriting each other
The classic split, where the designer hands over a mock-up and the developer rebuilds it, doubles the work and loses detail on the way. When both work on the same project, the questions change: who edits which parts, how changes from each side meet, and who presses publish. Here is how designers and developers collaborate on a website in Anticode, and where the arrangement stops working.
Two ways into one project
The designer works in the builder in a browser: the visual editor for text and section order, the layout editor for position and size, theme and action colour, and change requests in words. The developer works from a terminal with the Anticode CLI. anticode pull writes the project into a local folder as spec.json (the build spec: sections, content, settings) and a rendered index.html. They edit the spec in their own editor, run anticode push to upload it, and the page is rebuilt from it.
The spec follows Anticode's open project format, documented by a public JSON Schema at /schema/project.v1.json and by /AGENTS.md for coding agents, so a developer (or their agent) can see which fields exist and what they accept rather than guessing.
Agree who owns what
| Area | Owner | Where they work |
|---|---|---|
| Look: design system, colour, theme, headline scale | Designer | Builder |
| Layout: section order, sizes, positions | Designer | Visual and layout editors |
| Bulk content: many FAQ entries, service lists, consistent wording | Developer | spec.json, locally |
| Repeating content such as team or menu entries | Whoever updates it most | CMS collections in the dashboard |
| Custom form logic | Developer | A site function calling their own HTTPS endpoint |
| Publishing | One named person | Builder or anticode publish |
The working loop
- Both sign in. The developer runs
anticode login, which uses a code they approve in the browser; the CLI never sees their password. In a Team workspace both people need a seat. - Announce before a session. A one-line message ("pulling the site for FAQ edits, back in an hour") avoids most collisions.
- The developer pulls fresh before starting, every time, rather than reusing yesterday's folder.
- Each works on their area. If the designer has the builder open while the developer pushes, the builder redraws with the incoming change and offers an undo.
- The developer pushes. If the project changed in Anticode since the pull, the CLI refuses with a version conflict and asks them to save their spec, pull again and re-apply their edits. Nothing is silently overwritten.
- One person publishes.
anticode publishpushes and then publishes behind the server's security gate; the builder's publish does the same checks. A page that fails them doesn't go live, from either route. - If something goes wrong, version history keeps recent saves from both sides; preview and restore.
What the developer can't do here
It's worth being clear early, because it decides whether this setup suits the project. Pages are generated from the spec by Anticode's design engine, so the developer edits structure and content, not hand-written markup. The Pro mode code editor shows the HTML and maps text, section order and :root colour tokens back to the project, but other markup or CSS changes are flagged and not kept. Scripts, inline handlers and javascript: URLs are refused everywhere, and published pages run no scripts at all.
If the developer needs full control of the code, the right move is a handover rather than a sync: export the project as a Next.js app (or push it to GitHub) and continue there. That's one-way; the exported code doesn't sync back to the builder. See developer handoff with the Next.js export.
Signs it's working
- Version conflicts are rare, and when they happen they're resolved in minutes.
- The designer never has to ask "who changed this?": version history and the announce-first habit answer it.
- Every publish passes the gate first time, because both sides ran the release checklist or pushed early.
Limits
There's no branching, merging or line-by-line diff between the builder and a local copy; the CLI's protection is refusing a stale push. There's no live co-editing cursor. The CLI covers sign-in, listing projects, pull, push and publish, not domains, connectors or team settings. For agent-driven edits on the same project, see reviewing AI agent website changes and editing a website locally with the CLI.
Questions people ask
Can a developer write custom HTML and CSS for the site?
Not in the synced project: pages are generated from the spec. For custom code, export to Next.js and continue outside Anticode.
What happens if we both edit at once?
The CLI refuses a push if the project changed since the pull, and asks the developer to pull again and re-apply their edits.
Can the developer publish from the command line?
Yes, with anticode publish, which runs the same security gate as publishing from the builder.