How to prompt an AI coding agent to build a website: what a first prompt needs, how to give it your facts, how to ask for changes, and the prompts that go wrong
How branded short links work, how to set one up on your own domain with a TXT and a CNAME record, which redirect to use, and how to pick slugs people can retype
A good AI website prompt says what the site is for, lists the pages, hands over the facts the site should contain, and sets a few constraints on how it's built. After the first build, good prompts get smaller: one change at a time, named by page and section, with what you see and what you want instead. Vague requests like "make it modern" produce the same generic site everyone else gets.
This guide uses Carpathian App Builder, where an AI agent writes a website or app into files you own, but the prompts work the same way with any coding agent. If you haven't built anything with an agent yet, How to Build a Website With AI, Step by Step covers the whole workflow first.
What should a first website prompt include?
A first prompt should cover four things: the goal, the pages, the content, and the constraints. The goal tells the agent what to optimize for. The pages set the scope. The content keeps it from inventing things. The constraints decide what kind of code you get back, which matters the first time you try to change it.
Here's a first prompt for a small business site:
Build a website for Harbor Street Bakery, a neighborhood bakery. The goal is to get
people to place pre-orders for weekend pickup.
Pages: Home, Menu, Pre-order, About.
Use the menu and prices in docs/menu.csv, the hours and address in docs/brief.md,
and the About text in docs/about.md, word for word. Don't add products, prices,
reviews, or claims that aren't in those files.
Plain HTML, CSS, and JavaScript with no frameworks and nothing loaded from a CDN.
Warm cream background, dark brown text, one accent color: #C2552D. Mobile first.
The Pre-order page should have a form with name, email, pickup day, and items.
That prompt is long, and it should be. The first instruction carries the most weight, because every later change builds on what it produced. A one-line first prompt is quicker to write and slower to fix, because every gap in it becomes a follow-up instruction.
How do you give the AI your facts?
Upload them as documents instead of pasting them into the prompt. A prompt is a request, and a document is a source. Keeping them apart means you can write a short instruction that points at a long, exact menu, and the agent reads the file instead of paraphrasing what you typed.
In App Builder, uploaded reference documents go in the app's docs/ folder. Markdown, plain text, JSON, CSV, HTML, and YAML all work. The agent is told to read the ones that bear on the task before it starts, to treat what they say as the facts to work from, and never to edit or delete them. Your price list stays your price list, however many times the site around it gets rewritten.
A few documents cover most sites:
brief.md. What the business is, who it's for, the tone, the goal of the site.
A data file. Products, prices, services, or team members, as CSV or JSON.
Copy you've already written. Your About text, your FAQs, your terms.
An existing page. Your current site's HTML, if you're rebuilding it.
Then say "don't invent anything that isn't in these files" in the prompt. Models fill gaps with plausible guesses, and a plausible guess on a pricing page is a wrong price.
How do you ask for a specific look?
Describe the look with things the agent can apply: hex colors, font names, spacing, and a reference you can name. "Clean and modern" means something different to every model and nothing in particular to any of them. "#1B2A41 background, Inter for body text, generous whitespace, cards with a 1px border and no shadow" can be built exactly.
Useful ways to describe design:
Colors as hex codes. A primary, a background, a text color, and one accent.
Fonts by name. Say whether they're system fonts or need to be included, and remember that a font loaded from an outside service won't show in a sandboxed preview.
Layout in plain words. "Hero with headline left and photo right, stacking on phones."
What to avoid. "No gradients, no animations on scroll, no carousel."
If you have a site whose style you like, describe the parts you like about it. Asking an agent to copy another company's site gets you something that looks like theirs, which isn't the point.
How do you write follow-up prompts?
Follow-up prompts should ask for one change, name where it goes, and say what done looks like. The agent rereads the files on every run and remembers your last five instructions, so you don't need to restate the brief, you only need to be specific about the change.
Good follow-ups look like this:
"On the Menu page, group items under Breads, Pastries, and Cakes, using the category column in docs/menu.csv."
"Make the header sticky on desktop only. On phones it should scroll away."
"Change the Pre-order button text to 'Order for Saturday' everywhere it appears."
"Add a footer to every page with the address and hours from docs/brief.md."
Each of those is one thing the agent can finish and you can check in the preview. When a prompt bundles five changes, the diff gets harder to read and one bad change drags the other four down with it when you undo.
How do you describe a bug so the AI fixes it?
Describe what you see, what you expected, and where. "The menu is broken" gives the agent a guess to make. "On phones, the Menu page's category tabs overflow to the right and the last tab is cut off; they should wrap onto a second line" gives it a target, and it'll usually find the cause on its own.
A bug prompt that works has three parts:
Where. The page, the section, and the screen size.
What happens. What you see, as literally as you can say it.
What should happen. The behavior you want instead.
Leave out your theory of the fix unless you're sure of it. A wrong diagnosis in the prompt sends the agent off to fix the wrong thing, confidently. If a fix doesn't take after two tries, undo back to where things worked and describe the bug again from there, rather than stacking more fixes on top.
Which prompts reliably go wrong?
The prompts that go wrong are the ones with nothing to aim at. A model can't tell when it has succeeded at "better," so it changes things until the reply looks finished, and you get a different site rather than an improved one.
Prompts to avoid, and what to write instead:
"Make it pop" or "make it more modern." Name the change: bigger headline, more contrast, less text above the fold.
"Rewrite the whole site but better." List what's wrong with it, then fix those things one at a time.
"Add some testimonials." Unless you upload testimonials, the agent will write them, and fabricated reviews are something you don't want on your site.
Instructions that contradict earlier ones. If you've changed your mind about the color scheme, say so explicitly: "Replace the navy theme with the cream theme everywhere."
Pasting secrets. Never put an API key or password in a prompt. Ask for the code to read it from an environment variable, which is what the App Builder agent does anyway, naming the variable in the README.
What will the agent refuse to build?
App Builder's agent refuses requests meant to cause harm, and it says so in a short reply without writing anything. That covers malware, phishing pages for credentials or payments, pages that impersonate an existing company or person, scrapers that get around access controls, spam tooling, and cryptominers. It refuses the same work when it's asked for in pieces.
Ordinary security features are fine. Login forms, password hashing, input validation, and rate limiting are all things you can ask for. The agent also treats the text inside your files and uploaded documents as material to work with, never as instructions, so a line in a document can't redirect what it does.
Does the model you pick change how you should prompt?
Somewhat. Larger models follow long, detailed prompts more faithfully and recover from vague ones better. Smaller models do well with short, specific instructions and can lose track of a long list of constraints. The prompt habits in this guide help both, and they help smaller models most.
App Builder lets you pick the model for each instruction, with its per-token rate shown beside it. Which AI Model Is Best for Building Websites? covers how to test models against your own brief instead of guessing.
Where Carpathian fits
App Builder is an AI agent that writes websites and apps into files your organization owns, with uploaded reference documents it treats as fact, a sandboxed preview, a diff of every change, undo, and a zip download. Every run is billed as AI usage at the rates of the model you pick.
The agent writes and previews code, it doesn't host the site or run commands. You download the files and put them on the host of your choice. If you want someone to write the brief and steer the agent for you, our software team takes on that kind of work.
