← /blog

Using Claude Code as Your Pair: Notes from Building a Real Site

Using Claude Code as Your Pair: Notes from Building a Real Site

I spent three days rebuilding my personal site with Claude Code in the driver seat. Spec, plan, implementation, the whole thing. This post is the honest report on what that workflow actually looks like, what it gets right, and where you still have to step in.

The setup

The project: rebuild yigittanriverdi.com on a single Cloudflare Worker. Astro 6 SSR, D1 for content, an admin panel, two write paths into one source of truth, real SEO. Not a toy. Not a tutorial. The actual site you are reading.

The tooling: Claude Code in a VS Code window, with the superpowers plugin handling brainstorming, plan writing, and subagent dispatch. wrangler dev running in another terminal. I sat between them.

What Claude Code does well

It writes long, focused code. The TypeScript service layer, the Drizzle schema, the migration files, the API routes, the admin pages, the SEO component, the JSON-LD helpers. Most of the lines on this site.

It self-reviews. After each task it ran type checks, ran the test suite, ran the linter, and only marked work complete when all three passed. When something failed it diagnosed the root cause and fixed it before reporting back. That self-checking is not the model being clever -- it is the agent harness doing its job: verifying results instead of trusting them.

It writes intelligible commit messages. Multi-paragraph commits explaining why a change was made, what tradeoffs were considered, and what implication the change has for later phases.

It catches its own mistakes. Several times during this build a subagent reported DONE_WITH_CONCERNS rather than silently shipping bad code. Real engineering discipline.

What it does not do

It does not replace product judgment. The hero copy. The aesthetic direction. The decision to ship the admin behind a session cookie versus full Cloudflare Access on day one. Every decision that touches taste, you still own.

It does not always read fresh state. The wrangler dev cache, the browser cache, the not-yet-applied migration. When something looks broken in the running app, it is often because the last code change has not actually loaded yet. You have to push back.

It does not always know which API is current. The Astro Cloudflare adapter v13 changed the binding API in ways the LLM had not seen. Two real bugs surfaced and were fixed in commits, but only after a build broke first.

The patterns that worked

A few habits emerged that made the whole thing run smoother.

Brainstorm first, in detail. Fifteen minutes of question-and-answer to nail down scope and stack saves hours of mid-build rework. Decisions that feel obvious at the start are the ones that hurt most when reversed.

Spec, plan, then build. Writing the design document and the task plan before any code means each implementation step is short and obvious. The reviewer subagents can compare plan against code and catch drift.

Trust subagents but verify diffs. Subagents are perfect for parallelizable, well-specified tasks. Read every commit anyway. Trust comes from the pattern, not the individual.

ASCII-only seed strings on Windows. wrangler d1 execute reads SQL files as cp1252, which mangles em-dashes and middle-dots into U-FFFD replacement characters. Your seed should be plain ASCII; let users type fancy punctuation through the admin form where the encoding pipeline is clean UTF-8.

The honest cost

This site took roughly three working days, including the design pass and the second redesign once the first version came up bare. A side project, not a sprint. Most of that time was spent on the parts Claude Code does not own: looking at the running site, deciding the next move, telling Claude to ship a smaller thing.

You still have to be a senior engineer. The model is fast and disciplined, but it does not have your context, your taste, or your standards. What it gives you is the ability to ship at the pace your judgement supports, instead of the pace your typing supports.

What is next

More posts. The cron-driven git export. The cutover from the local dev environment to a real Cloudflare deployment. Probably another product post once Falimda lands in the stores.

The RSS feed is the lowest-friction way to catch the next one.

Built on Cloudflare, in Berlin, in 2026.