AI Coding Tools for Websites: Risks, Limits and Governance Rules

Cursor is a code editor built on VS Code with an AI assistant that can read the project and edit many files at once. Claude Code is Anthropic’s command-line agent that works inside a repository, runs commands and proposes or applies changes. GitHub Copilot started as autocomplete and now includes chat and agent modes inside common editors. Several others follow the same pattern.

The shift that matters for governance is autonomy. Autocomplete suggests a line and a developer accepts it. Agents can open files, install packages, run database commands and push changes. The more a tool can do without a person approving each step, the more your rules need to say about what it may touch.

Most incidents fall into a handful of categories. None are hypothetical; each is a normal software risk that becomes more frequent when code is produced faster than it is reviewed.

• Security flaws: missing input validation, SQL built from strings, weak authentication checks or permissive file uploads that pass a quick look.
• Secret exposure: API keys pasted into prompts, committed to the repository or printed in logs the tool reads.
• Destructive commands: an agent running a database reset, a forced git push or a mass file deletion on the wrong environment.
• Dependency risk: the tool adds a package that is outdated, abandoned or, in rare cases, a lookalike of a real package.
• Hidden regressions: a refactor that fixes one page and quietly breaks checkout, forms or tracking tags elsewhere.
• Licensing and IP questions about generated code and about client code sent to a third-party model.

AI coding tools are strong at boilerplate, explaining unfamiliar code, writing tests, converting designs into components and fixing clearly described bugs. They are weaker when the requirement is vague, when the codebase has undocumented conventions, or when the correct answer depends on business context the model cannot see.

They also make confident mistakes. A tool may claim a fix works without running it, invent a function that does not exist in your version of a library, or produce code that passes tests because it changed the tests. Treat every output as a pull request from a fast junior developer who never gets tired and never asks questions.

Start with rules that are cheap to follow and expensive to skip. You can refine them later, but these belong in writing before anyone connects an agent to a client repository.

• No production access: agents work on local or staging copies; deployment goes through the normal pipeline.
• Human review for every change: nothing merges without a named reviewer reading the diff.
• Secrets stay out: keys live in environment variables or a secrets manager, never in prompts, code or chat logs.
• Permission settings: restrict which commands an agent can run without asking, and block destructive ones by default.
• Approved tools and accounts: business plans with clear data retention terms, not personal free accounts.
• Dependency policy: new packages need a reason, a check of maintenance status and a reviewer’s approval.
• Logging: keep the session or summary of what the tool changed for any client-facing release.

A project instruction file helps

Many tools read a project file with standing instructions, such as CLAUDE.md for Claude Code or rules files in Cursor. Use it to record conventions, forbidden actions, test commands and known fragile areas. It does not replace review, but it reduces repeated mistakes and documents decisions for the next developer.

Speed is easy to feel and hard to verify. Track a few indicators so the team can see whether AI assistance is improving the work or only accelerating it.

• Automated test coverage on critical flows such as checkout, forms and login.
• Core Web Vitals after each release: LCP under 2.5 seconds, INP under 200 ms, CLS under 0.1.
• Number of bugs reported within a week of release, compared with the previous quarter.
• Security scan results from tools like GitHub code scanning, Snyk or a WordPress security scanner.
• Review time per pull request, to spot when reviewers are rubber-stamping large AI-generated diffs.

Two questions come up in every client conversation. First, what happens to the code sent to the model? Business and enterprise plans from the major vendors generally state that customer code is not used for training, but terms differ and change, so read the current agreement and record which plan you use. Second, who owns the output? Contracts should say plainly that delivered code belongs to the client, whatever tool helped write it.