AI coding assistants in a small development team: a practical guide

One developer on the team has been using an AI assistant for months and swears by it. Another tried one, got a confident answer that called a function which doesn't exist, and went back to doing things by hand. Meanwhile someone has asked whether the company has a view on all this, and nobody is quite sure.

That's a very common position for a small team, and a good one to be in. You haven't committed to anything yet, so you can choose deliberately. This guide is for teams of one to ten developers who want to use these tools well: what the main kinds are, where they genuinely save time, where they quietly cost it, and the handful of team habits that keep quality where you want it.

Product details here are as of October 2026. This area moves monthly, so check the linked documentation before you buy.

Three kinds of tool

Most products now do more than one of these, but it helps to separate the jobs.

"Agentic" just means the tool can take several steps on its own (read a file, change it, run the tests, try again) instead of producing a single suggestion. That makes it more capable, and it also means you should think about what it's allowed to do, which we come to below.

A few current details worth knowing:

• GitHub Copilot's Business and Enterprise plans include agent mode, Copilot code review and the cloud coding agent, with central policy controls for the organisation.
• Claude Code runs in the terminal, VS Code, JetBrains IDEs, a desktop app and the browser, and needs a Claude subscription or an Anthropic Console account.
• OpenAI Codex is available as a CLI, an IDE extension and a cloud service, signed in with a ChatGPT account.
• Cursor is an editor built around AI, with a Teams plan for central management.
• If you were considering Google's tools: new Gemini Code Assist subscriptions stopped being sold on 9 October 2026. Existing subscriptions continue for now, and Google points developers to Antigravity, available through eligible Gemini Enterprise subscriptions.

GitHub is part of Microsoft, and we supply Microsoft licences, but the right choice depends on your team, your editors and your existing accounts. Several of these tools also run inside each other (Claude Code and Codex both have extensions that work in Cursor, for example), so the choice is less exclusive than it looks.

Where they save real time

The gains tend to come from work that is well defined, easy to check and a little tedious.

• Tests for existing code. Ask for tests around a module before you change it. The tool is quick at the scaffolding, and you can see straight away whether the tests pass and whether they test anything meaningful.
• Mechanical refactors. Renaming across a codebase, moving to a newer API, splitting a large file. These are easy to describe and easy to verify with a compiler and a test run.
• Unfamiliar code. "Explain how authentication works in this repository and which files are involved" is one of the most useful prompts there is, particularly when you've inherited a system.
• Documentation and small scripts. READMEs, migration notes, a one-off data clean-up script, a first draft of a pull request description.
• Getting unstuck. Reading an error, suggesting causes, and proposing a fix you can then test.

Where they cost time

The costs are real, and they're mostly about review and confidence.

• Plausible but wrong code. The output usually looks right. Occasionally it calls a method that doesn't exist, or handles the common case and misses an edge case your domain cares about.
• Large diffs. An agent can change twenty files in a minute. Reviewing twenty files properly takes much longer, and a big diff is where problems hide.
• Shallow tests. Generated tests sometimes assert whatever the code currently does, bugs included. A passing test suite is only reassuring if the tests are good.
• Drift from your conventions. Without guidance, the tool writes code in a generic style that doesn't match the rest of your codebase.

All of these are manageable with a few habits, set early.

Team practices that keep quality high

Review AI-written code like any other code. The person who opens the pull request owns it, whoever or whatever typed it. If they can't explain a change, it isn't ready.

Keep changes small. Ask for one thing at a time and commit often. Small pull requests are easier to review, and when something goes wrong it's obvious where.

Give the tools your conventions in a context file. Most assistants now read a Markdown file in the repository at the start of each task. Claude Code reads CLAUDE.md, and GitHub Copilot reads .github/copilot-instructions.md and also supports AGENTS.md, a shared format several other tools use too. A short file pays for itself quickly. An illustrative example (not a template to copy wholesale):

# AGENTS.md

## Build and test
- Install: `npm ci`
- Run tests: `npm test` (all tests must pass before a change is finished)
- Lint: `npm run lint`

## Conventions
- TypeScript strict mode; no `any` without a comment explaining why
- Database access only through `src/data/`; never query from route handlers
- Dates are stored in UTC and shown in Europe/London

## Boundaries
- Never edit files in `migrations/` that have already been applied
- Never read or print the contents of `.env` files

Treat it like code: review changes to it, and keep it short enough that people actually read it.

Let tests and linters do the checking. An agent that can run your test suite and linter will fix many of its own mistakes before you see them. If your project lacks tests, generating a set around the area you're about to change is a sensible first job for the tool anyway.

Start agents with tight permissions. Most agentic tools ask before running commands or editing files, and let you allow specific actions. Keep the defaults at first. Be wary of letting an agent act on content it reads from outside your team, such as issue text, web pages or dependency documentation, because instructions hidden in that content can steer it (this is called prompt injection). Approving each command for the first few weeks also teaches you what the tool tends to do.

Secrets, IP and data

This is the part to settle before rolling out, and it's mostly straightforward.

Use business plans. Business and enterprise tiers give you central administration and clearer data terms. For example, Anthropic states that by default it won't use inputs or outputs from its commercial products to train its models, and Cursor says Privacy Mode is on by default for team members and can be enforced by admins. Read the terms for whichever tool you choose, check its data retention settings, and make sure you have a data processing agreement where personal data could be involved.

Keep secrets out of reach. Never paste API keys, passwords or connection strings into a prompt. Keep them in environment variables or a secrets manager, out of the repository, and say so in your context file. Don't rely on exclusion settings alone: GitHub's own documentation notes that content exclusion isn't supported in some agent modes, for example.

Watch for personal data. Test fixtures and database dumps sometimes contain real customer records. Under UK GDPR, sending those to a third-party service needs the same care as any other processing. Use synthetic data for tests and examples.

Write it down. One page covering approved tools, what can and can't be shared, and how AI-written code is reviewed is enough. Our article on an AI use policy your team will actually read has an outline you can adapt for a development team.

Measuring value honestly

Lines of code generated is a poor measure. It rewards the large diffs you want to avoid. More useful signals:

• how long typical tasks take from start to merged pull request, compared with before
• whether review time has gone up or down
• defects found after release in code the tools helped with
• the team's own view, asked plainly: which tasks got easier, and which got more frustrating

You don't need a dashboard. A short note at the end of each week is enough to see a pattern.

A sensible first step

Run a two-week trial with the whole team on one tool.

1. Pick one tool and one plan that fits the editors you already use, and set it up with business terms and default permissions.
2. Write a short context file for your main repository: how to build and test, your conventions, and the boundaries.
3. Choose three kinds of task from the "saves real time" list, such as tests for one module, one refactor and one documentation job.
4. Keep notes on time taken, review effort and anything that went wrong, then meet for half an hour at the end to decide: adopt, adjust or try a different tool.

Two weeks is long enough to get past the novelty and short enough that nobody feels locked in.

If you'd like a hand choosing tools or setting up team practices, our Technology Partner service covers exactly this, and if you'd rather we build or modernise the software itself, take a look at Software & Integration.