
Coding Agents in a Development Team - How to Roll Out Claude Code and Cursor Without Losing Quality
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 - WHAT THE RESEARCH SAYS
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.
| Model | Example tools | Where it works | Main risk |
|---|---|---|---|
| Assistant in the editor | Cursor, GitHub Copilot in agent mode | Day-to-day work, small changes, learning new code | Accepting suggestions without reading them |
| Delegating a task in the terminal | Claude Code, Codex CLI, Gemini CLI | Larger tasks with a clear goal: tests, migrations, refactors | The agent changes more than needed |
| Background agent | Copilot coding agent, Cursor background agents, Codex cloud | Well-described issues that end in a pull request | Large 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 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:
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
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.Measure the baseline: lead time for changes, failure rate, code review time, number of revisions.
- 2.Pick a working model to start with - usually an assistant in the editor or delegating tasks in the terminal.
- 3.Add AGENTS.md or CLAUDE.md with the project's commands, rules and architecture.
- 4.Make tests and CI a gate for every PR, including those from the agent.
- 5.Configure permissions: block secrets, no production access, an isolated environment for autonomous tasks.
- 6.Introduce a new-dependency rule: a human checks every one.
- 7.Run a pilot with volunteers on tasks that suit agents well.
- 8.Compare the metrics after a quarter against the baseline.
- 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:
- Context Engineering - How to Manage Model Context So Your AI Agent Doesn't Lose the Thread
- How to Write Tests for AI Applications: Test Pyramid, Golden Dataset and CI/CD for LLMs
- Prompt Injection and LLM Application Security - How to Protect Chatbots, RAG and AI Agents
- Vibe Coding: Complete Guide to AI Coding Tools 2026
/// RELATED_SERVICES
Need these concepts implemented? Explore the services related to this topic.
AI App Development
Custom AI software and AI-powered web applications. MVP development, full stack engineering, and AI systems programming from scratch to production.
View serviceServiceAI Training & Workshops
AI training for companies: prompt engineering, n8n automation, generative AI for leaders and AI literacy aligned with Article 4 of the EU AI Act. Hands-on workshops your team can apply the next day.
View service/// SOURCES
- 01METR - Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- 02METR - We are Changing our Developer Productivity Experiment Design (February 2026)
- 03Google Cloud - Announcing the 2025 DORA Report
- 04Veracode - 2025 GenAI Code Security Report
- 05Cloud Security Alliance - Slopsquatting: AI Code Hallucinations Fuel Supply Chain Attacks
- 06The Hacker News - Malicious Nx Packages in 's1ngularity' Attack Leaked 2,349 Credentials
- 07OpenAI - OpenAI co-founds the Agentic AI Foundation under the Linux Foundation
- 08Claude Code Docs - Settings reference
/// RELATED_RECORDS
Polish Embedding Models - bge-m3, multilingual-e5 or PolDense? A Test on 900 Questions
Which embedding model should you use for Polish RAG? I tested 10 models and BM25 on 900 real customer questions: results, robustness to missing diacritics and typos, the prefix that costs 30 points, the PIRB ranking, API prices, cost at two scales, licences and code.
AI Adoption in Your Team - Why Licences Sit Unused and How to Get People Using AI
According to Gartner, only 5% of companies that finished a Copilot pilot planned a larger rollout, and just 8% of employees use AI daily. Five kinds of resistance and what works, the role of managers, AI champions, measuring adoption at three levels and a 90-day plan.
How to Choose an AI Implementation Partner - 15 Questions, Warning Signs and Contract Clauses
According to MIT NANDA, 95% of AI pilots show no financial impact, yet deployments with partners succeed in 67% of cases. In-house, partner or hybrid, 15 questions to ask, warning signs, contract clauses and a pilot with success criteria.
Signal received?
Terminate
Silence
Initiate protocol. Establish connection. Let's build something loud.
