Build with an AI coding assistant
How do I build a client website with Claude or another AI coding assistant?
Give the assistant a project instructions file and the brief, ask for one component at a time, review every change and commit working states to git.
What you will be able to do
Set up a project so an AI coding assistant builds what you mean, one reviewed component at a time, with a git history you can roll back.
Before you start
- A finished brief and sitemap from Plan the sitemap and content.
- Access to Claude or another coding assistant that can read and edit files in a project folder.
- git installed. Check with
git --version. - The AI website prompt pack open in another tab.
Why this matters
An AI coding assistant is a very fast junior developer with no memory of your last conversation. Treat it like a mind reader and you get generic sites and code that undoes yesterday's fix.
What works: context in project files, small changes you can check, and git commits so a bad change costs a minute, not an afternoon. The assistant writes code. You decide whether it is right.
Step by step
Tick each step as you do it. Your ticks are saved in this browser.
Create the project folder and start git before anything else
mkdir austin-family-dental cd austin-family-dental git init git commit --allow-empty -m "Start project"Write a project instructions file
Most assistants read a file at the project root every session. With Claude Code it is
CLAUDE.md. Put in it the business, the one conversion action, the stack, the design tokens and the rules never to break. Add to it whenever you repeat an instruction.Put the brief and content in the project
Save the brief as
docs/brief.mdand the real copy asdocs/content.md, and reference them from the instructions file, so the assistant uses real copy instead of inventing it.Work with the context window
Long sessions crowd early instructions out of the assistant's limited memory. Keep durable facts in files, not chat, and start a fresh session for each major piece of work or when it forgets rules.
Ask for the skeleton first
The first build prompt creates the folder layout, a base stylesheet with the design tokens, and empty page files matching the sitemap. Review it, run it locally, commit.
Build one component per prompt
Header, hero, service cards, review strip, booking section, footer. For each, say what it contains, where the content comes from, how it behaves on a phone and what it must not do.
Review every change before you accept it
Read the diff with
git diff. Open the page at phone and desktop width. Check the content is real. Remove any library you did not ask for unless there is a good reason.Refine with specific feedback, not vibes
Not "make it pop" but "increase the hero headline to 40px on desktop and 30px on phones, and move the insurance line under the button."
Commit every working state with a clear message
Small commits are your undo button.
git add . git commit -m "Add hero with booking button and insurance line"Push to a private remote repository
It is your backup and what hosting deploys from. Never commit passwords or API keys: put them in
.envand add.envto.gitignorebefore your first push.
Example
Project instructions for the fictional Austin dental clinic.
AUSTIN FAMILY DENTAL WEBSITE (project instructions)
WHAT THIS IS
Marketing site for a fictional two dentist family clinic in South Austin.
Primary action: book a new patient visit (form at /book).
Secondary action: call the front desk (tap to call on phones).
Brief: docs/brief.md. Real copy: docs/content.md. Use only that copy.
STACK
Plain HTML, CSS and a little vanilla JavaScript. No frameworks.
No new dependencies without asking first.
DESIGN TOKENS (in css/tokens.css, never hard code colours)
--color-primary: #1F6F8B --color-accent: #F2B544
--color-text: #1D2630 --color-bg: #FFFFFF
Font: system font stack. Base size 18px. Spacing scale 4, 8, 16, 24, 40, 64.
RULES
* Mobile first. Design at 375px wide, then add wider breakpoints.
* Every page ends with the booking call to action.
* Never invent testimonials, prices or insurance names.
* Every image has meaningful alt text. Every form field has a label.
* Keep each change small and tell me which files you touched.
And two component prompts.
BAD PROMPT
Make a nice hero section for a dental website.
GOOD PROMPT
Read CLAUDE.md and docs/content.md first.
Build the homepage hero in index.html and css/hero.css.
Content: use the headline, subheading and button label from the
"Home / hero" section of docs/content.md, word for word.
Layout on phones (375px): headline, subheading, full width button,
then the line "We take most major insurance plans" linking to
/about#insurance. Everything visible without scrolling.
From 900px up: text on the left, the photo images/clinic-front.jpg
on the right, 50/50.
Use only tokens from css/tokens.css. No new dependencies.
When done, list the files you changed and anything you were unsure about.
The good prompt names the files, the content, the layout at each width and the limits, and asks for uncertainty, where most bugs hide.
Common mistakes
- One giant prompt for the whole site. You get a generic look and code you cannot review.
- Keeping the rules only in chat. The next session forgets them.
- Accepting changes without opening the page. Good code can still break on a phone.
- Letting the assistant write the copy. It will invent services, prices and reviews. Give it the real content.
Try it yourself
Start a git project for your practice client, write an instructions file like the example, and add your brief and content under docs/. Then use the AI website prompt pack to build only the header and the hero.
Time: about 60 minutes.
Deliverable: a repository with at least three commits (start, skeleton, hero) and a hero that shows the call to action without scrolling at 375px wide.
Resources
- AI website prompt pack component prompts to copy and adapt
- Website specification brief the brief to save into your project
- What AI coding really costs per site how to keep your usage predictable
- From an empty folder to a live demo the full build end to end
Finished this lesson?
Mark it complete to track your progress through the course.
Last reviewed October 18, 2026. Prices, laws and tool terms change, so check current terms before you rely on any figure.