Not "AI assisted". Not "AI wrote the first draft". We mean: we describe changes in plain English, Claude Code edits the HTML and CSS, commits the change, and deploys to Cloudflare Pages. We review and steer — but we don't hand-write the markup. We don't write the words either. Claude Code does.
The setup
The RemoteCore site is deliberately simple: static HTML files, Tailwind CSS via CDN, deployed to Cloudflare Pages. No build pipeline, no framework, no bundler.
That simplicity was intentional. Before involving AI, we wrote two documents: a design system spec (DESIGN.md) and a project context file (CLAUDE.md). Together they describe the visual language and constraints of the site — colors, typography, spacing rules, things like "never use 1px borders between sections" or "use background color shifts to separate surface tiers, not dividers". The initial design system was generated using Stitch, Google's AI-powered design tool, then adapted into our DESIGN.md spec.
Those documents are the real interface. Claude Code reads them at the start of every session. Everything flows from that shared context.
We also got Claude Code to create and prioritise an initial set of Linear issues for the project — effectively letting AI plan its own backlog. That bootstrap step took about ten minutes and produced a structured list of work that a human PM would have taken hours to write.
The infrastructure
Claude Code runs on a Hostinger VPS — Arch Linux, bare metal, no Docker overhead. We install Claude Code with bypass permissions enabled so it can run git, wrangler, and other CLIs without prompting for approval at each step. TMUX lets us pair-program across machines: one shared terminal session, persistent between connections.
Three CLIs do most of the heavy lifting — but we don't run them directly. We tell Claude what we need in plain English, and it handles the commands.
gh (GitHub CLI) — pull requests, repo management:
"Create a pull request for this branch"
"Show me the open issues"linctl (Linear CLI) — issue tracking. When working on an issue, we tell Claude Code the issue ID:
"Start REM-34" // i.e., the Linear issue for creating the blog post you're reading right nowClaude attempts to address the issue and we review and iterate on it as needed.
wrangler (Cloudflare CLI) — deployment:
"Commit and deploy"How a typical change works
Each piece of work starts as a Linear issue. When working on an issue, we tell Claude Code the issue ID (e.g., Start REM-34 — the Linear issue for creating the blog post you're reading right now). The workflow:
- Claude reads the issue, understands the task, marks it in progress, and gets to work
- Claude Code reads the relevant files, checks the design system, writes the HTML
- We review the output in the browser
- If something's off — "that shadow's too heavy", "move this above the CTA" — it iterates
- When it looks right, Claude commits. As part of the commit, it extracts the prompts from the session and includes them as context in the commit message. For security reasons, the responses aren't included — just our prompts
- Claude runs
wrangler pages deploy - We get Claude to update the Linear issue with a summary of what was done — files changed, decisions made, anything worth noting — and mark it done
The whole thing often takes under ten minutes for a change that would have taken an hour to hand-code. More importantly, it stays consistent with the rest of the site.
What actually makes it work
A few things that aren't obvious until you're in it:
The context files matter more than the prompts. Having CLAUDE.md and DESIGN.md as persistent reference means we don't re-explain the design system on every conversation. The AI isn't guessing at the color palette or border radius conventions — it's reading them.
Version control is non-negotiable. Every change is committed before deploy. If a change breaks something, we can revert in seconds. This sounds obvious, but it's the safety net that makes it possible to move fast.
Review everything before you ship. AI is fast but not infallible. We read every diff. The occasional mistake — a wrong Tailwind class, a misread instruction — gets caught at review, not in production.
Give it the right grain size. "Redesign the site" is a bad prompt. "Add a two-column capabilities section with these two cards and this copy" is a good one. Smaller, clearer scope gets better results.
The quality of the output is mostly determined by the quality of the context you give upfront. Garbage in, garbage out — but context in, good work out.
Where AI earns its keep — and where it doesn't
It's fast and consistent on repetitive markup. It's good at following a design system when that system is written down clearly. It holds state across a session — once it's read the design system once, it applies it everywhere without being reminded.
It's less useful for decisions that require aesthetic judgment, brand instinct, or understanding of your actual users. Those still need a human in the loop. We review the copy, steer the direction, and decide when something "feels right". We make the calls on what to build and in what order.
The AI handles execution. We handle direction.
The meta point
We help clients use AI well. We built our own site using exactly the same approach we recommend to them. If that sounds circular, it is — and it's also exactly the point.
The tools work. The question is always whether you've set them up to succeed: clear spec, structured context, human review at every step. That's true whether you're building a marketing site or an AI feature inside a product.
If you're thinking about how to bring this kind of workflow into your own team or product, we're happy to talk through what that looks like.