Cursor and Claude Code in a production team: guardrails that keep velocity

Using Cursor and Claude Code in a production team works when guardrails live in the repository, not in people's memory: written project rules, small scoped tasks, protected branches, required review, automated checks, secret scanning, and no production credentials in agent environments. Those controls keep the speed of AI coding while stopping it from shipping unreviewed risk.

This article is about team process. Our post on the limits of building agents only from vibe-code tools covers AI agents you ship to users, and how to turn a Lovable or v0 prototype into a production application covers hardening an app that already exists. Here the question is different: how do professional developers use coding agents every day without slowly eroding a production codebase? The observations come from our own daily use and from the ImadDhin portal repository; they are not productivity measurements.

Why coding agents need guardrails

Coding agents change the economics of a team. Writing code becomes cheap and fast; reviewing it does not. A developer who used to open one careful pull request a day can now open several large ones, and each looks plausible. Review capacity becomes the bottleneck, and under pressure, plausible gets merged.

Agents also have habits that are harmless in a prototype and costly in production. They add dependencies freely, sometimes suggesting packages that do not exist or have similar names to popular ones. They make failing tests pass by changing the test. They touch files outside the task. They loosen a type, a lint rule or a security rule to remove an error. And because each session starts with limited context, they reinvent patterns the codebase already has, so the code drifts toward several ways of doing the same thing.

Modern agents can also run terminal commands and call external tools. That is where most of their power comes from, and it is also where a mistaken command can affect a shared database, a deployment or a repository's history.

What teams often get wrong

• Banning the tools, which pushes usage into personal accounts with no controls
• Allowing everything, including production credentials and unrestricted commands
• Treating a passing test suite as proof, when the agent also wrote the tests
• Accepting very large pull requests because they were quick to produce
• Leaving conventions unwritten, so every session invents its own patterns
• Relying on each developer's prompting discipline instead of shared configuration

The common thread is putting guardrails in individual habits. Habits vary by person and by how tired they are. Configuration in the repository applies to everyone, including the agents.

A practical approach: guardrails in layers

No single control is enough. The approach that holds up stacks several cheap ones, so a mistake that passes one layer is caught by the next.

Repository instructions

Both tools read project instruction files. Cursor uses project rules stored in the repository, Claude Code reads a project memory file, and many tools also read a shared agents instruction file. Use them to state architecture boundaries, where code of each kind lives, patterns to follow, patterns that are forbidden, and the exact commands to run for type checks, linting and tests. Keep the files short and specific. A rule such as all calls to the payments provider go through one module is more useful than a page of general advice.

Treat repeated review comments as missing rules. When reviewers write the same correction twice, add it to the instructions so the agent reads it before writing code next time.

Task shaping

Give agents small tasks with one concern and clear acceptance criteria. For anything larger, ask for a plan first, review the plan, then let the agent implement it in steps. Set a team expectation for pull request size; a change too large to review carefully should be split before review starts, not after.

Execution permissions

Both tools let you control which commands and tools run without confirmation. Allow routine, reversible commands, such as running tests or type checks. Require confirmation for anything destructive or shared: deployments, database migrations against shared environments, force pushes, deleting files in bulk, and publishing packages. Give external tool integrations, such as MCP servers, the minimum scope they need, read-only by default.

Review and continuous integration

Protect the main branch. Require review by a person who owns the area being changed, and use code owners for sensitive paths such as authentication, payments, database rules, migrations and infrastructure configuration. Run type checks, linting, tests, a production build, a dependency audit and secret scanning on every pull request, whether a person or an agent wrote it.

Credentials and environments

Agent environments get development or staging credentials only. Production secrets live in a secret manager and in the deployment platform, not in local environment files that an agent can read and paste into a response or a commit. Local environment files are ignored by version control, and credential files stay outside the repository directory.

Implementation considerations

Roll out in a fixed order: instruction files and continuous integration first, because they help immediately and cost little; then branch protection and code owners; then permission settings; then environment separation. Each step is useful on its own.

Review AI-assisted changes differently. Read tests before implementation and ask whether they would fail if the feature were broken. Check every new dependency by name, publisher and maintenance history. Look for changes outside the stated task, especially to configuration, rules, types and tests. Be suspicious of any diff that makes a check less strict.

Background and cloud agents that open pull requests on their own should go through exactly the same gates as people. The convenience of an agent working overnight disappears if its changes bypass review.

Keep instruction files maintained. Out-of-date rules are worse than none, because agents follow them confidently. Assign an owner, review the files when architecture changes, and remove rules that no longer apply, since long files also consume the agent's limited context.

Trade-offs

Confirmation prompts and strict permissions slow individual developers down. The time lost is small compared with recovering from a mistaken migration or a force push, but it is real, and overly strict settings lead people to disable them entirely. Tune them so routine work flows and only consequential actions stop.

Required review and code owners can create bottlenecks, particularly when agents raise the volume of changes. The answer is smaller changes and more reviewers who understand the codebase, not lighter review.

Detailed instruction files improve consistency but cost context and maintenance. A short file that captures the rules people actually break beats a comprehensive document nobody updates.

Lessons from ImadDhin work

These are code-level observations from the ImadDhin portal repository and how we work in it, not productivity claims.

The repository carries an agents instruction file that records learned preferences: design system constraints, copy rules, where each type of content lives and which patterns to avoid. Scoped rule files add narrower constraints. One states that all traffic to a third-party web research API must go through a single wrapper module, that its key is server-only, never given a public prefix and never logged, that retries follow a fixed policy, and that tests mock the wrapper instead of calling the paid API. That rule turns what would otherwise be a recurring review comment into something the agent reads before it writes code.

The workspace instructions also tell agents not to deploy or start long-running processes without asking first. That is a permission guardrail expressed in words, and it works best when the tool's own permission settings enforce the same boundary.

The project's web application and its cloud functions are type-checked with separate configurations, and the web build excludes the functions directory. An agent that runs only the main type check after editing a function has not actually verified its change. Instruction files should name the right check for each package.

Some issues only show up in careful review. A common example in AI-assisted code is a usage counter that reads the current count and writes the incremented value in a separate step, outside a transaction, so concurrent requests can both pass the limit. The code is short, readable and passes a quick glance. It is exactly the kind of change that a reviewer skimming a large AI-assisted diff would miss, and exactly the kind a small, focused pull request makes visible.

Common mistakes to test for

• Ask the agent to add a feature and check whether it modified existing tests to pass
• Verify every newly added package exists and is the intended one
• Confirm destructive commands prompt for confirmation in each developer's setup
• Check that agent environments cannot read production secrets
• Look for edits to rule files, lint configuration or CI in feature pull requests
• Run secret scanning against a branch containing a deliberately planted test key
• Confirm background agent pull requests require the same review as human ones

When a simpler solution is better

A solo developer or a very small team working on a prototype does not need code owners and elaborate permission policies. A short instruction file, continuous integration with type checks and tests, secret scanning, and no production credentials on the development machine cover most of the risk.

The layers matter more as the team, the codebase and the consequences grow. Add them when you add people, customers or sensitive data, not all at once on day one.

Keep the speed, lose the risk

Write the rules down in the repository, keep tasks small, restrict consequential commands, and put every change through the same review and checks. If you want help setting up guardrails for AI-assisted development or rescuing a codebase that grew without them, see ImadDhin's vibe-code rescue practice and engagement options, or discuss your team's setup in a 30-minute call.