The Core Build Workflow

How do you actually get Claude Code to build something good? Not in theory. In practice, on a real project, with a real deadline sitting somewhere behind you and a real client waiting to see what you've actually produced by the end of the week.

A first look at control

Before diving into workflow, one control matters immediately: in "ask before edits" mode, Claude requests your approval before it changes any local file, every single time, without exception. That's safer. It's also slower, because repeated approval prompts can genuinely interrupt a longer task and break your concentration right when you need it most. Modes that auto-edit or bypass approval trade that safety for speed, fewer prompts, faster work, and more freedom for Claude to alter files without asking first. All six permission modes get their own full treatment later in this documentation.

That same discipline shows up in a concrete demonstration covered fully in the next chapter: asked to refactor a page from dark mode to light mode, Claude entered Plan Mode on its own, examined the file's CSS (the styling rules that control how a page looks), and broke the request into steps before touching anything. The interface turned blue while it planned, with a stop control ready the whole time to interrupt execution already underway if something looked wrong. Figure 11 shows the general shape underneath it. Every interaction in this course follows the same one.

FIGURE 11 — The task, do, verify loop. Skip the verify step and the loop collapses into blind trust, the whole discipline lives in that last arrow.

Claims worth flagging as personal

Two claims here are my own experience, not a general rule about what Claude Code can do for anyone. I've personally built around fifteen high-quality websites comparable to the polished examples I show on screen. I also think most of those gallery-quality sites can now be built end to end in roughly ten minutes, based on my own repeated use of the tool. Take both numbers as one person's track record. Neither is an independently measured benchmark you can hold Claude Code to on your first attempt.

Three ways to design

The course walks through three approaches to design. None of the three is presented as the one correct path. They're offered as options instead, each one useful in a different situation, and one of which I personally prefer, for reasons I'll get to at the end of this section.

Reference plus screenshot loop. First method. Claude's first attempt might land around eighty percent close to a supplied reference image. Repeating a screenshot-compare-revise cycle moves it closer each round after that, by my own rough figures: ninety percent, then ninety-five, eventually somewhere near ninety-nine, though rarely a truly perfect match by the end of it. A reference design mainly supplies fonts, colors, spacing, and button style. Once those fundamentals are locked in, you can swap the actual written content for a completely different business without starting over.

Voice-transcript prompting. Second method. People type somewhere around fifty to seventy words a minute, but most speak closer to two hundred. That's roughly two and a half to three times faster, by my own rough estimate. This method may not nail a complete, correct site on the very first try, since it hands Claude no visual reference to work from at all, unlike the screenshot-loop method described just above it. But the back-and-forth that follows can still land on something usable faster than typing every instruction out by hand ever would.

Reusable components. Third method. Services like 21st.dev let designers publish individual interface pieces you can preview and copy. Open one, select "Copy Prompt," and you get text Claude Code can use to rebuild that exact component's look and behavior inside whatever project you happen to be working on at the time.

Try this with AI "Here are the three ways I build a site with Claude Code: reference plus screenshot loop, voice-transcript prompting, reusable components. Given [describe your project], which one would you start with, and why?"

I personally prefer the first method. That's a stated preference, not a ranking backed by any data I share. The goal in every case is an initial direction, never an exact copy, and I say so directly: the finished product can end up looking nothing at all like where it originally started out, and that's fine.

Capturing a reference, and the core loop

Building happens locally, on your own machine. Deploying is different. It means making the result reachable by other people, through a hosting service like Netlify or Vercel. To capture a full reference screenshot: open developer tools, set the viewport to a desktop size such as 1920 by 1080, then use the command menu to select "Capture full size screenshot." A full-page image around twenty megabytes is too large to hand Claude directly. It burns tokens fast and risks hitting a file-size limit, so I resize it down to roughly four or five megabytes first, using a simple online tool.

Everything in this course circles back to one core loop, repeated more than once in my own material: give Claude a task, let it act, then verify the result yourself. Skip that last step, and here's what tends to happen instead. People assign a task, let Claude finish it, immediately assign another, and blame the tool later when the output disappoints them, without ever giving Claude a real chance to check its own work along the way. Build that check in from the start. For visual work, a screenshot comparison. For software, automated tests. Either way, verification is the step that actually makes the rest of the loop worth trusting.