Coding Agents in a Development Team - How to Roll Out Claude Code and Cursor Without Losing Quality
RETURN_TO_BLOG
AI & Automation 13 min

Coding Agents in a Development Team - How to Roll Out Claude Code and Cursor Without Losing Quality

Paweł Wiszniewski
Paweł Wiszniewski
SEO & GEO Specialist · AI Engineer

In July 2025 the research organization METR published a result that surprised the industry. In a randomized study, experienced open-source developers worked on real tasks in their own repositories and were 19% slower with AI tools - yet afterwards they estimated that AI had sped them up by 20%. In February 2026 METR published an update: with late-2025 tools, developers were about 4-20% faster, though the researchers note the true effect is hard to measure, because some people didn't want to work without AI at all. Coding agents can speed up a team, but it doesn't happen automatically, and developers' impressions aren't a reliable measure of the effect.

In METR's study, experienced developers were 19% slower with AI while feeling 20% faster, and DORA shows AI raises throughput but also delivery instability. How to roll out coding agents in a team: working models, metrics, AGENTS.md, tests as a gate, security and senior pushback.

The 2025 DORA report adds a second important conclusion. AI is now used by 90% of people in the industry, and its effect works like an amplifier: teams with good practices get even better, while teams with problems just reproduce them faster. AI tools increase throughput, but instability rises at the same time: more rollbacks, hotfixes and unplanned work. In this post I describe how to roll out coding agents such as Claude Code, Cursor or GitHub Copilot in a team that already has a software delivery process: working models, what to measure, which standards to introduce, how to handle security and how to win over the skeptics on the team.

/// THIS POST IN SHORT

Coding agents in a team - key takeaways from this post

/// CODING AGENTS - WHAT THE RESEARCH SAYS

-19% / +20%
actual time with AI vs developers’ perception (early-2025 tools)
METR, July 2025
+4-20%
faster with late-2025 tools - a result that’s hard to measure
METR, February 2026
90%
of people in the industry use AI; throughput rises, but so does delivery instability
DORA 2025
66%
of developers complain about AI code that’s "almost right, but not quite"
Stack Overflow 2025

Three ways of working with an agent

A coding agent isn't one tool; it's several ways of working that differ in how much control stays with the developer.

ModelExample toolsWhere it worksMain risk
Assistant in the editorCursor, GitHub Copilot in agent modeDay-to-day work, small changes, learning new codeAccepting suggestions without reading them
Delegating a task in the terminalClaude Code, Codex CLI, Gemini CLILarger tasks with a clear goal: tests, migrations, refactorsThe agent changes more than needed
Background agentCopilot coding agent, Cursor background agents, Codex cloudWell-described issues that end in a pull requestLarge PRs that are hard to review properly

Copilot coding agent has been generally available to paid Copilot users since September 2025: you assign it a task like a normal issue, and it works in a separate environment and opens a draft pull request. The more autonomy an agent gets, the more good task descriptions, tests and code review matter - because a human only sees the result at the end. A good practice is to start with the first model and move on to the next ones only once the team has proven standards.

What to measure - and what not to

The worst metric is lines of code or the percentage of code written by AI. An agent can easily generate a lot of code, but that's not the point. The METR study also showed that developers' self-reports can be off from reality by tens of percentage points.

/// WHAT TO MEASURE WITH CODING AGENTS

Measure
+ Lead time for changes
+ Deployment frequency
+ Change failure rate
+ Time to restore service
+ Code review time and PR revisions
Don’t measure
✗ Lines of code
✗ Percentage of code written by AI
✗ Number of accepted suggestions
✗ Self-reported sense of speed-up

Measure the same things you measure without AI, just more carefully. The DORA metrics are a good starting point: lead time for changes, deployment frequency, change failure rate and time to restore service. On top of that, add three metrics specific to working with agents: code review time, the number of revisions to agent-prepared PRs, and defects found after deployment. If throughput goes up while the failure rate and the number of revisions go up too, the team hasn't sped up - it has just moved work from writing code to fixing it. Measure the baseline before you roll out, otherwise after a quarter you'll have nothing to compare against.

Repository standards: AGENTS.md and CLAUDE.md

An agent doesn't know your project's rules until you write them down. That's what instruction files in the repository are for. AGENTS.md is an open standard from August 2025 that in December 2025 moved under the Agentic AI Foundation at the Linux Foundation, and according to its creators it's used in more than 60,000 projects - Codex, Cursor, Copilot and Gemini CLI, among others, support it. Claude Code reads its own CLAUDE.md file. The contents of both are similar:

AGENTS.md
INSTRUCTIONS FOR AGENTSRunning:- Install: npm ci | Tests: npm test | Lint: npm run lintRules:- Every change must pass tests and lint before committing.- Don't add new dependencies without a justification in the PR description.- Don't modify files in /migrations unless explicitly asked.Architecture:- Business logic lives in /src/domain, with no framework dependencies.

Such a file works like onboarding notes for a new team member, only shorter and more concrete. Keep it in the repository, review it in PRs like code and update it when the agent repeats the same mistake. Every recurring agent mistake is a sign that one line is missing from the instructions. I cover choosing what information reaches the model in more depth in the post on context engineering.

Tests and code review as a gate

In the 2025 Stack Overflow survey, developers' most common complaint, cited by 66%, was AI code that's "almost right, but not quite". That's exactly the kind of error that passes a quick review and only surfaces in production. So with coding agents, tests and code review stop being good practice and become an entry requirement.

  • Tests as a requirement. The agent runs tests itself, and a PR without green CI doesn't go to review. I cover testing AI applications in the post on how to test AI applications.
  • Small changes. A large PR from an agent is hard to review properly. Splitting tasks into smaller ones works better.
  • AI as the first reviewer, a human as the last. Automated code review catches obvious problems, but responsibility for merging stays with a person.
  • Clear accountability. The person who handed the task to the agent is responsible for the code just as if they'd written it themselves.

Security: code, dependencies and secrets

Security is the area where coding agents need the most attention.

/// THREE RISKS AND HOW TO PREVENT THEM

45%
FLAWS IN GENERATED CODE
Of tests with significant vulnerabilities (Veracode 2025)
→ Code scanning in CI for every PR
19.7%
HALLUCINATED PACKAGES
Of code samples with a non-existent package (USENIX Security 2025)
→ A human checks every new dependency
2,300+
STOLEN SECRETS
Credentials taken in the Nx package attack (August 2025)
→ Block secret files, use an isolated environment

Vulnerabilities in generated code. In Veracode's 2025 report, code generated by more than 100 models contained significant security flaws in 45% of tests, and bigger, newer models did no better than smaller ones. Code scanning in CI is therefore mandatory, regardless of who wrote the code.

Hallucinated packages. A study presented at USENIX Security 2025 found that 19.7% of 2.23 million code samples referenced a package that doesn't exist - 5.2% on average for commercial models, 21.7% for open ones. Attackers register those names and wait for someone to install them. The rule: the agent doesn't add a new dependency without a human checking that the package exists and is what it claims to be.

Secrets and permissions. In August 2025, malicious versions of the Nx package stole, according to analyses, more than 2,300 credentials from over a thousand developer machines, and used locally installed AI command-line tools to search the disks. An agent running on a developer's machine has access to everything the developer has access to. That's why it's worth:

  • blocking the agent from reading secret files (.env, keys) in its settings - Claude Code supports this with "deny" rules, which take precedence over allow rules;
  • not giving agents access to production data or keys with full permissions;
  • running autonomous tasks in an isolated environment, not on the main machine;
  • in larger teams, managing settings centrally so a single project can't widen the agent's permissions.

A separate risk is hidden instructions in files the agent reads - I described that mechanism in the post on prompt injection. When an agent connects to external tools through MCP, every server is an extra set of permissions to think through - more in the post on MCP. Then there are licenses: a license scanner in CI helps catch code fragments that may come from projects with an incompatible license.

Rolling out to the team and senior pushback

Skepticism from experienced developers isn't a problem to "break through"; it's a signal worth taking seriously. In the 2025 Stack Overflow survey, more developers distrusted the accuracy of AI tools (46%) than trusted it (33%), and only 3% reported a high level of trust. Seniors see best where "almost right" code will do damage - and they should be the ones co-writing the rules for working with agents.

A rollout that works:

  • A pilot with volunteers, not a mandate for the whole team.
  • Tasks where agents do well: tests for existing code, migrations, refactors covered by tests, documentation, repetitive changes across many files.
  • Tasks that need more caution: core business logic, security, architecture, code without tests.
  • Shared sessions - one person works with the agent while the rest watch and comment. It's the fastest way to share good practices.
  • Shared instructions in the repository instead of every developer's private tricks.

If people outside the IT team want to build simple tools with AI, that's an entirely different scenario - I covered it in the post on vibe coding. This post is about a professional team bringing agents into an existing process. I cover how AI agents work in general in the post on AI agents.

A step-by-step implementation plan

  1. 1.Measure the baseline: lead time for changes, failure rate, code review time, number of revisions.
  2. 2.Pick a working model to start with - usually an assistant in the editor or delegating tasks in the terminal.
  3. 3.Add AGENTS.md or CLAUDE.md with the project's commands, rules and architecture.
  4. 4.Make tests and CI a gate for every PR, including those from the agent.
  5. 5.Configure permissions: block secrets, no production access, an isolated environment for autonomous tasks.
  6. 6.Introduce a new-dependency rule: a human checks every one.
  7. 7.Run a pilot with volunteers on tasks that suit agents well.
  8. 8.Compare the metrics after a quarter against the baseline.
  9. 9.Expand gradually - move to background agents only once the standards are working.

---

I help development teams roll out coding agents so they speed work up rather than pile up debt - from repository standards and permission setup, through tests and code review, to measuring results and running workshops for the team. I do this as part of AI app development and AI training, and I cover the practice of working with agents in the AI Engineer course. Get in touch - I'll start with a review of your process and metrics, so it's clear where to begin and how to measure the effect.

Worth reading next:

/// AUTHOR
Paweł Wiszniewski – AI & Web Engineer

Paweł Wiszniewski

SEO & GEO Specialist & AI Engineer

SEO/GEO specialist (10 years) and AI engineer (3 years). I build search visibility, AI systems and automations that reduce costs and improve operational efficiency.

Signal received?

Terminate
Silence

Initiate protocol. Establish connection. Let's build something loud.

> WAITING_FOR_INPUT...