AI Prompts for Web Development: 8 Copyable Templates

The best AI prompt for web development doesn't start with "You are an expert senior full-stack engineer." What makes it work is the stuff a senior engineer would ask you for before touching the code: your stack and versions, the exact error, what "done" looks like, and what they're not allowed to change.

That's true in ChatGPT, Claude, Cursor, Claude Code, and GitHub Copilot alike. The official prompting guides from all of those vendors land on the same few habits:

• Give context, not a title. Framework, versions, file paths, existing patterns, constraints.
• State acceptance criteria. A test that should pass, a behavior that should change, a metric to hit.
• Ask for a plan before code when the change touches more than one file.
• Keep the diff small. One job per prompt, and say what's out of scope.
• Show an example. An existing component or test is worth a paragraph of description.

Below: why those habits work, eight copyable templates organized by job, and where to put the context you'd otherwise paste into every prompt.

What Makes a Coding Prompt "Expert"

"Expert" is the word people search for, and it's the wrong lever. A role line isn't useless: Anthropic's prompting best practices say a role in the system prompt focuses Claude's behavior and tone. But the same guide describes Claude as a brilliant new employee who lacks context on your norms. A new hire with a senior title still doesn't know your repo uses Zustand, not Redux.

So treat the expertise as something you supply. Here's what each pattern does, and which official guide backs it.

Two more details from the vendor docs are worth knowing. OpenAI's guide compares a reasoning model to a senior co-worker you can hand a goal, and a GPT model to a junior coworker who does best with explicit instructions. If you're using a reasoning model, lean on goals and acceptance criteria; with a faster non-reasoning model, spell out the steps.

And Anthropic recommends putting long inputs, such as a big log file or several source files, near the top of the prompt, with your question at the end. For a pasted stack trace plus three files, that ordering matters.

For the general version of these ideas outside of code, our guide to advanced prompt engineering techniques covers few-shot, decomposition, and chain-of-thought in more depth.

8 Copyable Prompts for Web Development

Each template uses [brackets] for the parts you fill in. Delete any line that doesn't apply. The shorter the prompt that still carries the context, the better.

In a chat tool like ChatGPT, paste the relevant code under the prompt. In an agent that can read your repo (Claude Code, Cursor's agent, Copilot in agent mode), point it at file paths instead and let it read them.

Build and fix: scaffolding a feature and debugging

1. Scaffold a feature (plan first)

Stack: [Next.js 15 App Router, TypeScript, Tailwind, Prisma + Postgres]
Feature: [users can save a search and get it back from /account/saved]

Existing patterns to follow:
- [src/app/account/page.tsx] for page layout and auth checks
- [src/lib/db/favorites.ts] for data access

Acceptance criteria:
- [Saved searches persist per user and survive a reload]
- [Logged-out users are redirected to /login]
- [No new dependencies]

Out of scope: [styling polish, email notifications]

Don't write code yet. List the files you'd create or change, the data model
change, and any open questions. Wait for my go-ahead.

The last line does the heavy lifting. Claude Code's docs recommend exactly this split: explore, then plan, then implement. They also note that if you could describe the diff in one sentence, you can skip the plan.

2. Debug from an error and stack trace

[Paste the full error and stack trace here]

Context:
- [React 19, Vite 6, Node 22]
- Happens when: [I click "Submit" on /checkout after changing quantity]
- Expected: [order posts and redirects to /confirmation]
- Already tried: [clearing cache, checking the API returns 200]
- Relevant files: [src/features/checkout/CheckoutForm.tsx, src/api/orders.ts]

Explain the most likely root cause first, citing the exact line.
Then give the smallest fix. Don't suppress the error or wrap it in a try/catch
unless that is the actual fix. If you need to see another file, ask.

"Already tried" saves a round of suggestions you've ruled out. "Don't suppress the error" mirrors Claude Code's own before/after example, which asks to address the root cause rather than hide the symptom.

Review, refactor, and test

3. Code review

Review this diff for a [Node/Express API]. Our conventions:
[async/await only, errors go through middleware/errorHandler.ts, zod for input validation]

Report only issues that affect correctness, security, or the conventions above.
For each: file and line, what's wrong, why it matters, and a suggested fix.
Group by severity: blocking, should fix, nit. Skip style preferences.

[Paste diff, or: review the changes on this branch against main]

Telling the reviewer what not to report matters. Claude Code's docs warn that a reviewer asked to find gaps will usually find some even when the work is sound.

4. Refactor without changing behavior

Refactor [src/components/ProductTable.tsx] to [split data fetching from rendering].

Constraints:
- No behavior change. Existing tests in [ProductTable.test.tsx] must still pass unchanged.
- Keep the public props interface the same.
- Don't touch other files unless required; if required, say which and why first.

Show the change as a diff, then list anything you noticed but deliberately left alone.

5. Write tests

Write [Vitest + React Testing Library] tests for [src/hooks/useCart.ts].

Follow the style of [src/hooks/useAuth.test.ts].
Cover: [adding an item, updating quantity to 0 removes it, totals with a discount code,
behavior when localStorage is unavailable].
Avoid mocking the hook's internals; mock only [the fetch to /api/prices].
Run the tests after writing them and fix failures in the test, not the hook,
unless the hook is actually wrong. If so, tell me instead of changing it.

The "follow the style of" line is the example pattern in action. GitHub's Copilot guide makes the same point: unit tests can serve as examples of expected behavior.

Audit, design, and explain

6. Accessibility and performance audit

Audit [src/app/pricing/page.tsx and its child components] for:

1. Accessibility against WCAG 2.2 Level AA: keyboard access, focus order,
   labels, color contrast, alt text, landmark structure.
2. Performance risks for Core Web Vitals (LCP, INP, CLS): large images without
   dimensions, render-blocking work, layout shifts, heavy client components.

For each finding: the element or line, the specific criterion or metric affected,
and a concrete fix. Mark anything you can't confirm from code alone
(like real contrast values or field data) as "needs manual check".

Naming the standard keeps the audit grounded. WCAG 2.2 is the current W3C Recommendation, and Google's Web Vitals page defines "good" as LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of page loads. The "needs manual check" line matters because a model reading source code can't measure field data.

7. API design

Design a REST API for [team invitations in a B2B SaaS app].

Context: [Express + Postgres, existing resources use /v1/ prefix, cursor pagination,
errors shaped as { error: { code, message } }]

Give me:
- Endpoints (method, path, purpose)
- Request and response bodies as TypeScript types
- Status codes and error cases, including [expired invite, already a member]
- Auth and permission rules per endpoint
- Two design choices you considered and rejected, and why

No implementation yet.

Asking for rejected alternatives is a cheap way to see whether the model understood the trade-offs or just produced the most common shape.

8. Explain unfamiliar code

I'm new to this codebase. Explain [src/server/middleware/tenant.ts].

- What problem it solves and where it's called from
- The request flow through it, step by step
- Anything surprising or non-obvious, with line references
- What would break if I removed [the cache lookup on line 42]

Read the file and its callers before answering. If you're unsure about something,
say so rather than guessing.

The "read before answering" line comes almost straight from Anthropic's guidance on reducing hallucinations in agentic coding, which tells the model never to speculate about code it hasn't opened.

Put the Repeated Context in Project Instruction Files

After a week of using these templates, you'll notice you're pasting the same lines every time: the stack, the test command, "we use pnpm." That context belongs in a file your tool loads automatically.

One detail trips people up: Claude Code reads CLAUDE.md, not AGENTS.md. If your repo already has an AGENTS.md, Anthropic's docs recommend a CLAUDE.md that imports it with an @AGENTS.md line, so both tools share one source of truth.

What goes in the file matters more than which file. Claude Code's best practices include a useful test for every line: would removing it cause the model to make mistakes? Good entries are the ones a model can't infer from reading the code:

# Commands
- pnpm dev / pnpm test / pnpm typecheck
- Run a single test: pnpm vitest run path/to/file.test.ts

# Conventions
- Server components by default; add "use client" only for interactivity
- Data access only through src/lib/db/*, never Prisma directly in components

# Gotchas
- The local API needs Redis running (docker compose up redis)

Skip "write clean code" and anything already obvious from the files. A bloated instruction file gets partly ignored, which is worse than a short one that's fully followed. If you'd rather not write one from scratch, the AGENTS.md generator skill drafts per-folder context files with real build commands.

Chat vs Agent: Adjust the Prompt to the Tool

The eight templates work in both, but the delivery changes.

Two agent-specific habits come straight from Claude Code's best practices. First, ask for evidence rather than a claim of success: the test output, the command it ran, a screenshot. Second, if you've corrected the model more than twice on the same issue, start a fresh session with a sharper prompt instead of piling on corrections.

For browser-level verification on a web app, a Playwright-based check like the web app testing skill gives an agent real screenshots and console errors to check against. And if you're still choosing between tools, our comparison of AI coding assistants breaks them down by shape.

Once a prompt sequence works, the next problem is keeping it. A great debugging flow buried in last Tuesday's chat is gone. Taku is an AI-native desktop workspace where you can mirror a working AI setup, remix it, and save it so it runs again next week instead of being rebuilt from scratch. Taku is in Beta, and the Mac app is available now.

Key Points

• An "expert" coding prompt is defined by its context: stack, versions, files, constraints, and a way to verify the result. A role line adds focus, not knowledge.
• Ask for a plan before code on multi-file changes, and skip the plan when the diff fits in one sentence.
• One job per prompt. Name what's out of scope.
• Examples from your own codebase (an existing component, an existing test) steer output better than description.
• Move repeated context into CLAUDE.md, AGENTS.md, Cursor rules, or Copilot instructions, and keep those files short.

FAQ

What is the best AI prompt for programming?

There isn't a single magic prompt. The most reliable structure is: the goal, your stack and versions, the relevant code or error, acceptance criteria, constraints, and an instruction to plan first or keep the diff small. The templates above follow that shape for eight common jobs.

Do "act as an expert web developer" prompts actually help?

A little, for tone and focus. Anthropic's docs note a role in the system prompt does shape behavior. But the model's output quality on your project depends far more on the context you give it, like your framework version and conventions, than on the job title you assign.

Should I use different coding prompts for ChatGPT, Claude, Cursor, and Copilot?

The core content stays the same. What changes is delivery: in a chat tool you paste code, while agents like Claude Code, Cursor, and Copilot's agent mode can read files you name and run your tests. With agents, add explicit scope limits and ask for evidence that checks passed.

How do I stop the AI from rewriting half my codebase?

Name the files it may touch, list what's out of scope, and ask for a plan before code. For refactors, require that existing tests pass unchanged and that the public interface stays the same.

What should go in a CLAUDE.md or AGENTS.md file?

Commands the model can't guess, conventions that differ from defaults, testing instructions, and known gotchas. Leave out anything the model can learn by reading the code. Claude Code's docs recommend keeping CLAUDE.md concise, and Claude Code can import an existing AGENTS.md rather than duplicating it.

Are coding prompts different for front-end work?

The structure is the same, but front-end prompts benefit from naming standards to check against (WCAG 2.2 for accessibility, Core Web Vitals for performance) and from visual verification. Paste a screenshot of the target design and ask the agent to compare its result against it.