AI Coding Tools for Websites: Cursor and Claude Code Checklist

Cursor is a code editor built on the open-source base of VS Code, with AI chat, inline edits and an agent mode that can change several files at once. It lets users choose among models from different providers. Claude Code is Anthropic’s agentic coding tool; it runs in the terminal and in IDE integrations, reads the project, runs commands and proposes or makes edits, asking for permission according to the settings you choose.

Both tools work on the files in your repository. That is their strength and their risk. They can understand a theme or a component library quickly, and they can also change things you did not intend if the task is vague or permissions are wide open.

Good first tasks are bounded and easy to verify. Poor first tasks touch payments, authentication or data migrations, where a subtle mistake is expensive and hard to see.

• Building or restyling a single component, such as a pricing table or FAQ accordion
• Writing structured data (JSON-LD) templates and validating them
• Fixing accessibility issues flagged by Lighthouse or axe
• Converting repeated markup into a reusable block or partial
• Writing tests for existing code before refactoring it
• Explaining an unfamiliar legacy theme to a new developer

Pick one repository and one or two developers. Agree on a two-to-four-week window and a short list of tasks from the list above. The goal is to learn how the tools behave on your codebase, not to ship a redesign.

Repository preparation

• Make sure the project is in Git with a protected main branch
• Add a project instructions file: CLAUDE.md for Claude Code, rules files for Cursor
• Describe the stack, folder layout, naming rules and commands to run tests
• List files and folders the tool must not touch, such as secrets and vendor code
• Keep environment files and API keys out of the repository entirely

The instructions file matters more than people expect. It is where you write down the decisions a new developer would need to know, and the tool reads it on every session. Updating it after each surprise is how the team stops repeating the same correction.

Generated code is still code your team owns. Treat it like a pull request from a capable new colleague who does not yet know your history.

• Every change goes through a branch and a pull request, never straight to main
• A human reads the full diff, not just the summary the tool wrote
• Small diffs only; split large changes into several reviewed steps
• Run linting, unit tests and a build in CI on every pull request
• Check Core Web Vitals on a preview: LCP under 2.5 seconds, INP under 200 ms, CLS under 0.1
• Validate structured data in Google’s Rich Results Test before merge

Permission settings deserve a decision too. Claude Code can be set to ask before editing files or running commands, and Cursor lets you control whether agent actions run automatically. During a pilot, keep approvals on. Loosen them only for commands you trust, such as running the test suite.

After the pilot, review what happened. Which tasks were faster, which needed heavy rework, and where did the tool misunderstand the codebase? Turn those lessons into updated instructions and a short internal guide.

Then widen access step by step. Add more developers, then more repositories, keeping the same review and CI gates. Watch for quiet regressions: page weight creeping up, unused CSS, duplicated helper functions or plugins added without discussion. An AI tool will often solve a problem by adding code, so someone has to ask whether code should be removed instead.

Some errors repeat across tools and projects. Knowing them makes review faster, because the reviewer knows where to look first.

• Invented functions or library options that do not exist in your installed version
• Inline styles or scripts that break your content security policy
• Missing escaping on output, which opens the door to cross-site scripting
• New dependencies added for a task the existing stack already handles
• Changes to templates that quietly remove meta tags, canonical links or structured data

For WordPress sites in particular, check that generated PHP uses the platform’s escaping and sanitising functions, and that new options or queries do not run on every page load. For JavaScript frameworks, check that server rendering still outputs the content search engines need to see.

Keep a short list of these findings in the instructions file. Over a few weeks it turns into a project-specific review guide.