How to enforce coding standards on AI-written code

Every engineering team has its own way of building software. There are agreed patterns for handling dependencies. APIs return errors in a consistent structure. Database queries follow a defined style. Over time, these standards make the codebase predictable and easier to maintain.

Then an AI assistant generates code that ignores those patterns. It creates objects directly instead of following your dependency setup. It returns a different error format. It writes queries in a style no one on your team uses.

The result isn’t broken code. It’s inconsistent code. And that inconsistency adds friction to every review.

This keeps happening because generic AI tools are trained on public repositories from everywhere. They suggest the most common pattern they’ve seen, not the one your team has agreed to follow. Without guidance, they default to average practices instead of your standards.

Instruction files such as CLAUDE.md and AGENTS.md give a coding agent that guidance while it writes, and our practical guide to using Claude Code shows how teams set them up. Custom review agents then check what the agent wrote on every pull request.

TLDR

Enforce your team's standards on AI-written code through:

• Custom agents in plain English that analyze code against your specific rules during every PR

• Reading the rule files your coding agents already use, such as .cursorrules, CLAUDE.md and AGENTS.md, as review context

• Community-proven agents from successful teams that you can adopt and customize

• Learning from team feedback to reduce false positives over time

• Multi-repository enforcement applies the same standards across all your projects

cubic's AI code review runs up to 5 custom agents per repository on the Team plan, and more on Pro and Max.

Why generic AI doesn't follow your team's patterns

AI trained on public repositories learns common patterns. But "common" doesn't mean "right for your team."

The training data problem

If most repositories use async/await but your team prefers Promises with .then() for specific architectural reasons, AI will suggest async/await. Not because it's better for your system, but because it's more common in the training data.

Your team might have valid reasons for your patterns. Maybe your error handling strategy works better with .then() chains. Maybe your architecture team decided on specific patterns after careful evaluation.

Generic AI doesn't know this context.

What happens without configuration

Without configured agents, every AI-generated pull request needs manual cleanup:

• Renaming variables to match team conventions.

• Restructuring code to fit architectural patterns.

• Rewriting error handling to use team standards.

• Moving files to follow team organization.

How custom coding agents enforce team standards

Custom coding agents are AI systems configured to understand and enforce your specific patterns.

Plain English rule definitions

The most effective approach is to define rules in plain English that agents can understand and apply.

Example custom agent for API standards:

Name: API Response Format Validator Description: All API endpoints must return errors in the format { error: { code: string, message: string, details?: object } }. Success responses must include a data field. Never expose internal error details in API responses.

Example custom agent for architecture:

Name: Dependency Injection Enforcer
Description: All service classes must use dependency injection through constructor parameters. Never use direct class instantiation with 'new'. Services should be registered in the DI container in /config/dependencies.ts.

Example custom agent for database access:

Name: ORM Query Pattern Validator
Description: Database queries must use the TypeORM query builder. Raw SQL is only allowed in /migrations. All queries must include error handling and use transactions for multiple operations.

These agents run on every pull request, flagging violations before human reviewers see the code.

How agents analyze code

Custom agents work through specialized analysis:

• Planner agents coordinate overall review, identifying which specific agents should examine each code change.

• Security agents check for vulnerabilities based on your team's security standards.

• Architecture agents enforce layer boundaries and dependency rules specific to your system.

• Code quality agents validate formatting, naming, and organizational patterns.

This multi-agent approach catches violations that single-model AI assistants miss.

Setting up custom agents in cubic

cubic provides a straightforward process for configuring team-specific agents.

Creating your first custom agent

On the Team plan, each repository runs up to 5 custom agents (more on Pro and Max). Start with the pattern that causes the most review friction.

Step 1: Identify the problem

What conventions do you constantly correct during code review? Common examples:

• Error handling format inconsistencies.

• Architectural boundary violations.

• Security patterns are not being followed.

• Database access patterns.

Step 2: Write the agent description

Use plain English to describe what code should follow:

Name: React Component Standards Description: Functional components only, no class components. Use hooks for state and effects. Props interfaces must be defined with TypeScript. Event handlers should be prefixed with 'handle' (handleClick, handleSubmit). Components over 200 lines should be split into smaller components.

Step 3: Test the agent

Open a pull request that violates the rule. Verify the agent catches it and provides clear feedback.

Step 4: Refine based on feedback

If the agent creates false positives, refine the description. If it misses violations, add more specific guidance.

Reusing your coding agents' rule files

Teams using Cursor already have .cursorrules files defining standards.

cubic automatically reads your .cursorrules file during review, so your existing conventions apply without re-entering them. This maintains consistency between what AI suggests in your IDE and what gets enforced during code review. cubic reads CLAUDE.md and AGENTS.md the same way, and our guide covers what to put in CLAUDE.md and AGENTS.md.

Example Cursor rule:

# API Design Standards

- All API endpoints must return errors in the format: { error: { code: string, message: string } }

- Use dependency injection for all service classes

cubic reads these rules as context during PR review. To have cubic actively flag violations of a rule, write it as a custom agent.

Using community agents

cubic maintains a library of proven agents from successful teams. Instead of writing rules from scratch, adopt patterns that work. You can also browse cubic's code review standards by language and framework, then turn each rule on in cubic or paste it into AGENTS.md so your coding agent follows it too.

Each rule in cubic's code review agents library has its own page with code it flags. These match examples in this guide:

• Require API Auth, Validation, and Tenant Scoping flags API endpoints that skip auth, accept unvalidated request bodies or leak internal errors.

• Prevent Sensitive Data in Logs flags logs and error reports that expose passwords, tokens or card data.

• Flag Security Vulnerabilities catches hardcoded secrets, SQL injection, XSS and weak crypto.

You can adopt these as-is or customize them for your specific needs.

Configuring agents for different scenarios

Not all code needs the same level of enforcement. Configure agents based on context.

Production code vs experimental code

Production repositories:

• Enable as many custom agents as your plan allows.

• Strict enforcement of security and architecture rules.

• Require a human approval before merge with GitHub branch protection, and leave cubic's auto-approval off or in shadow mode.

Experimental repositories:

• 2-3 core agents for critical patterns.

• Leave findings as comments and let the author decide.

• Allow team discretion on enforcement.

Critical paths vs general code

Configure stricter agents for code touching:

• Authentication and authorization.

• Payment processing.

• Data privacy and PII handling.

• External API integrations.

Example critical path agent:

Name: Payment Code Security Validator Description: Code in /services/payment must validate all monetary amounts for overflow. Use the Decimal type for currency; never float. All payment operations must be wrapped in database transactions. Log all payment events with an audit trail. Never log credit card numbers or CVV codes.

Framework-specific patterns

Different frameworks need different agents.

React projects:

Name: React Hooks Pattern Validator Description: Use useState for component state. Use useEffect for side effects with proper cleanup. Custom hooks must start with 'use'. Never mutate state directly; always use setter functions.

Python projects:

Name: Python Type Hint Enforcer Description: All public functions must have type hints for parameters and return values. Use Optional[T] for optional parameters. Import types from the typing module. Use dataclasses for data structures instead of dictionaries.

Learning from team code review patterns

The most powerful configuration evolves based on actual team feedback.

How feedback reduces false positives

When developers reply to a finding to explain why it doesn't apply, or give it a thumbs down, cubic learns from it. In later reviews, it uses those learnings to avoid repeating known false positives.

Example learning cycle:

1. Agent flags a 40-line function as too long.

2. The reviewer replies that longer functions are fine in this module.

3. System learns that longer functions in this module type are okay.

4. Future reviews account for this context.

Team-specific preferences vs hard rules

Configuration files define rules. Learning systems discover preferences.

Hard rule: "Use dependency injection." Learned preference: "In /scripts directory, direct instantiation is acceptable for one-off utilities."

The agent learns these nuanced preferences from how your team actually reviews code.

Multi-repository configuration

Apply the same standards across all your team's repositories automatically.

Organization-wide agents

Security standards, coding conventions, and architectural patterns that apply company-wide can be configured once and applied across the company.

Example organization agent:

Name: Company Security Standards Description: Never commit API keys, passwords, or tokens. Use environment variables for secrets. All external API calls must include timeout handling. Log security events to the central audit system.

This agent runs on every repository in your organization, preventing each team from developing different security practices.

Repository-specific customization

While organization agents enforce company standards, repository-specific agents handle project conventions.

A microservice might have strict API versioning rules. A CLI tool might have different patterns. Each repository adds 2-3 custom agents for its specific needs while inheriting organization-wide agents.

Integrating with CI/CD for enforcement

Configuration means nothing without enforcement. Integrating into CI/CD makes standards automatic. To check code before it reaches a pull request, you can set up Claude Code hooks that run a review with the cubic CLI, which applies the same custom agents, learnings and repository settings as pull request reviews.

Automated enforcement

cubic posts its findings as review comments, each with a priority from P0 to P3. Its review settings have no option that blocks a merge or turns findings into warnings. To gate merges, use GitHub branch protection or rulesets, which can require approving reviews, passing status checks and code owner approval.

Quality gates

If you turn on auto-approval (it is off by default), cubic approves only pull requests that clear these rules:

• By default, any open cubic issue blocks the approval.

• "Allow open issues" lets issues at the priorities you pick, such as P3, stay open.

• "Never auto-approve" rules keep sensitive paths, such as migrations or auth code, with a human reviewer.

Measuring the configuration effectiveness of coding agents

Track metrics to know if your configuration works.

1. False positive rate

How often do agents flag code that's actually fine? Target below 15%.

If false positives exceed 20%, your agent descriptions are too vague or overly strict.

2. Code review cycle time

Configured agents should reduce review cycles by automatically catching issues.

Target: 30-40% reduction in review cycles after configuration.

3. Standards compliance

What percentage of merged code follows team standards?

Track before and after configuring agents. Target: 80%+ compliance with key standards.

Making coding agents work for your team

Generic AI is powerful but generic. Custom agents transform them into team-specific tools that understand your conventions.

Effective configuration combines plain English agent descriptions, reading the rule files your coding tools already use, adopting community-proven patterns, learning from team feedback, and multi-repository management.

Model choice matters as well as configuration. On Bug Bench, the models ranked for code written in Claude Code have relative bug rates from 1.09 to 1.49, where 1.00 is the all-model average. Check the best model for Claude Code before you set a team default.

Start with core standards that cause the most review friction. Add agents incrementally. Measure effectiveness. Iterate based on team feedback.

Ready to configure agents that enforce your team's standards?

Book a demo of cubic and watch custom agents validate every pull request against your architecture, security, and coding conventions.