How Should My Team Use AI Coding Tools?

Some of our developers use Cursor, some Claude Code, and our pull requests have grown so big that reviews pile up. Should we standardise on one tool, or limit how much AI writes?

Neither. Change the repository instead. Small pull requests, checks on every change and rules the agent can read decide whether its speed ships or piles up.

The pile-up doesn't come from Cursor or from Claude Code. Both write code faster than anyone on the team. The repository is what lets one task grow into a diff nobody can read in one sitting.

Limiting how much AI writes slows the typing, and typing was already the easy part. Someone still decides what gets built and answers for what merges. That's where the fix goes.

The Tool Matters Less Than the Repo

Cursor or Claude Code, either works.

Cursor is a code editor with AI built in. Claude Code is an agent that runs in the terminal or inside your editor. Both read the codebase, change files and run commands.

I use Claude Code every day, inside my editor. On a team, the choice matters less than it looks.

On one product we rebuilt, the designer pulled a branch and opened it in Cursor or Claude Code. The interface got its final polish in the code itself. He picked his tool, and the codebase stayed the same for everyone.

So one tool for everyone wouldn't shorten this team's queue. Standardize what the tools read instead.

Claude Code reads a CLAUDE.md file and Cursor its rules files, but both can read one AGENTS.md: Claude Code when there's no CLAUDE.md, or through an import from it. Write the conventions there once, and both tools follow the same ones.

What Should I Send a Developer First? covers what goes in front of an agent. That file is one part of what the repository needs before the agents arrive.

Agents Need What Teams Need, More

Small pull requests, checks on every change and written rules the agent reads. A team of people needs the same, and agents put more weight on each.

An agent reads part of the code, fixes what it was asked to fix and sometimes a little more. Nothing in it knows what else depends on the line it changed.

Four pieces catch that:

• Types. TypeScript turns a wrong data shape into a build error before anything runs. Quality Gates explains why I lean on it more than on unit tests.
• Checks on every change. A build, a linter and the tests run on every pull request, whoever wrote it. The agent can run them itself before it calls a task done.
• Written rules. The conventions, the commands and the traps of the codebase, in the instruction file. As Documentation puts it, the question is whether the process feeds the right context to the tools.
• A way back. A feature flag turns a bad change off without a new deploy.

Secrets get a rule of their own. Keys stay out of the chat and out of any file the agent reads. In my setup, agents call scripts, and the scripts read the tokens.

This team needs the four pieces whichever tool each developer opens. With them in place, the pressure moves to the person reading the diff.

Review Load Follows Pull Request Size

Keep pull requests small and let the checks read first. Then review keeps up.

AI-written code swamps review when the pull request grows with the output. An agent produces a day of typing in minutes, and a reviewer reads at last year's speed. That's how this team's queue formed.

Three habits keep it readable. The first is one task per pull request, small enough to review in one sitting. A large change goes in as several steps, each in production before the next starts.

The second is machines first. Types, the linter, the build, the tests and an AI code review run before a person opens the diff. The person then reads for intent, not for syntax.

The third is the why in writing. Each pull request says what changed and why. An agent drafts that description in seconds, so skipping it saves nothing.

How much a person reads depends on what the setup has earned. Where my checks are still incomplete, I read the diff before each commit. Where tests and screenshots cover the work and a rollback is ready, I check the result: the screenshots and a live look.

A pull request waiting for review is one of the queues in Why Does My Team Ship So Slowly? Kept to one step, it gets read between two other tasks. Review is also where a team finds out who answers for the change.

The Person Who Merges Answers for It

An agent wrote it, a person approved it. A model can generate an opinion, but it can't be accountable for one. Every AI-written change still ships under a person's name.

That person also sets how far each agent may reach. I give an agent the smallest access that does the job. It gets read-only where it only has to look, and no admin rights just in case.

Accountability is also why AI doesn't replace a senior developer. AI makes me faster at writing code. It doesn't decide what comes first, or carry the result to production.

Software is an iceberg. AI writes the visible part fluently: the screens, the forms, the path where everything goes right.

Underneath sit the data rules, the edge cases and what depends on what. Knowing where that part is buried is the senior job.

On one product I work on, the agents' test for report downloads checked each report's name, header and size. Nothing read what was inside.

Then I had the agents open the reports and compare them with the app. Four bugs turned up that had sat in the generator for months.

Code with no senior behind it shows the gap. A founder once showed me a SaaS built by prompting alone, and within minutes I found three security holes. Is My Vibe-Coded App Ready for Production? lists what to check first.

What AI changes is the size of the team. Solo Model holds that one developer with modern AI tools can rival a small team from five years ago. The hands get fewer, and the judgment stays with whoever merges.

Other Teams Hit the Same Queue

The numbers from other teams match this one. In July 2025, Faros AI published telemetry from more than 10,000 developers on 1,255 teams.

On teams with high AI adoption, developers completed 21% more tasks and merged 98% more pull requests. Pull requests also grew 154% in size, and review time rose 91%. Bugs per developer rose 9%.

The typing got faster, and the queue moved to review: the same pile-up this team is asking about.

How I Work Inside a Team's Repo

Same repository, same rules, same checks. An outside developer should work inside your setup, not beside it. Code built in someone else's setup comes back with someone else's rules.

That's how I join a team: one senior who owns one stream, by the week. The price is on the homepage. My part is often the foundation: the hardest tasks and the base the rest of the team builds on.

Your branch rules and your review apply to my pull requests too. Nothing merges without your approval, and a written update follows every session. My agents follow your rules file, and the code stays in your repo from the first commit.

Where the setup has gaps, I close them as I go. The scout rule says the codebase gets better with every change.

What the Team Should Do Now

Cap the pull request size, add the checks, write the rules, then let everyone pick their tool. The order matters, because each step makes the next one cheaper:

1. Cap each pull request at one task, small enough to review in one sitting.
2. Run types, the linter, the build and the tests on every pull request, before a person reads it.
3. Write the conventions once, in an AGENTS.md both tools can read.
4. Keep both tools, and let each developer use the one they prefer.

Don't limit how much AI writes. Limit how much lands in one pull request, and review keeps up with the agents.