Claude Code in development teams: how to start without breaking quality

You can introduce Claude Code in a team without losing quality if you treat it like a new team member: give it clear rules in the repository and limited permissions, and review its work the same way you review anyone else’s. Start with a pilot on one well-tested repository, set up a CLAUDE.md file and permissions, keep pull requests small with human review, and measure lead time and review time from day one. The speed-up comes from discipline, not from the tool itself.

What is Claude Code and how does it differ from code autocomplete?

A classic AI autocomplete suggests lines of code in the editor. Claude Code is an agentic tool: it receives a task, explores the repository on its own, proposes a plan, edits multiple files, runs tests and continues based on the results. It works in the terminal or in the editor, and the developer approves its steps.

This difference changes what matters. With autocomplete, the quality of individual suggestions is what counts. With an agent, what counts is the environment it works in: how well the project is described, what permissions it has, how quickly tests tell it that it broke something, and who reviews its output.

Where to start?

Do not roll the tool out to everyone overnight. A pilot works better:

1. Pick one repository with reasonable test coverage and a working CI pipeline. An agent without tests has no feedback, and you will only find the bugs in production.
2. Pick two or three developers who are keen to experiment and also know the code well. They are best placed to recognise when the AI is proposing nonsense.
3. Measure the baseline – lead time, review time and pull request size over recent months.
4. Set the pilot length, for example four to six weeks, and evaluate both the data and the experience at the end.
5. Write down what you learn and turn it into rules for other teams.

How to prepare the repository?

The CLAUDE.md file

CLAUDE.md is the project’s memory file. Claude Code loads it at the start of every session. It should contain:

• commands for installation, build, tests and linting,
• a short description of the architecture and main directories,
• code and naming conventions that the linter does not show,
• rules on what not to do, for example not changing the public API without agreement or not touching migrations,
• links to more detailed documentation.

Keep it short and up to date. Besides the project file, you can also have personal developer settings and files in subdirectories for individual parts of a monorepo. Version CLAUDE.md in git and change it through pull requests, like code.

Permissions and allowlists

Claude Code asks for approval before risky steps. In the project settings you can define which commands it may run without asking (for example tests and the linter) and which are forbidden. Typically you block reading files that contain secrets, deleting outside the working directory, pushing to the main branch and deploying. Put the shared settings in the repository so they apply to the whole team.

MCP servers

The Model Context Protocol (MCP) is an open standard for connecting Claude Code to other systems: an issue tracker, documentation, a database or monitoring. Add only servers you trust and give them the lowest permissions they need. Read and write access to the production database has no place in a pilot.

Skills, hooks and subagents

• Skills are packaged instructions for recurring tasks, such as the procedure for adding a new API endpoint or cutting a release.
• Hooks are commands that run automatically on certain events, for example formatting and linting after every file edit. Quality is then enforced by the machine, not by memory.
• Subagents are specialised helpers with their own brief and context, for example for exploring code or for review. They are useful for larger tasks where the main conversation would get swamped with detail.

What workflow works from ticket to merge?

1. A clear brief. A ticket with acceptance criteria. The more precise the brief, the fewer corrections.
2. Plan before code. In plan mode, the tool first goes through the code and proposes an approach without editing files. The developer reviews and corrects the plan before the first line is written.
3. Tests first. Have it write a test that describes the required behaviour and fails. Then the implementation, until the test passes. The test is the contract that tells you the agent did what it was supposed to.
4. Small steps and small pull requests. One pull request should solve one thing. A large diff generated in five minutes is hard to read, and review turns into a formality.
5. Human review. The reviewer checks logic, security, architectural impact and tests. The author must be able to explain the change, even if the tool wrote it.
6. CI as a gate. Tests, linter, type checking and security scans must pass, otherwise nothing gets merged.

A hypothetical example: a team is adding a CSV export of orders to an application. The developer has Claude Code propose a plan, adjusts it (the export must respect user permissions), has it write tests including an empty export and special characters, and then the implementation. The pull request touches a few files and the reviewer gets through it in one sitting.

How to maintain quality?

AI speeds up writing code. But if the rest of the process stays the same, review becomes the bottleneck and bugs move further downstream. These rules keep quality in place:

• Quality rules in automation, not in good intentions. Linter, formatter, type checking and tests in CI and in hooks.
• A pull request size limit. Agree on a threshold and split larger changes.
• AI review as a supplement. Automated review on the pull request will catch typos, missing error handling or inconsistencies. It does not replace human review.
• Watch out for fake tests. Check that tests really test behaviour, not just that the code runs. An agent sometimes adjusts a test so that it passes.
• Architectural decisions are made by people. New dependencies, changes to the data model and public interfaces are approved by the team.

What to watch out for in security?

• Keep secrets out of reach. Passwords, API keys and certificates belong in a secrets manager, not in the repository. Block reading files such as .env in the permissions.
• Customer data. Do not paste production data containing personal data into an AI conversation. Use anonymised or test data for debugging.
• Untrusted content. Text from the web, issues or dependencies can contain hidden instructions (prompt injection). The more tools and permissions the agent has, the more carefully you need to handle this.
• New dependencies. Check that a suggested library actually exists, is maintained and has a suitable licence.
• Company rules. Write down what must not go into AI tools. This also ties in with the AI literacy obligation under the AI Act, which we cover in the article AI literacy under the AI Act.

How to use Claude Code in CI?

Claude Code can also run non-interactively (headless mode), without a developer at the keyboard. In CI, this is useful for:

• an automatic first review of a pull request with comments,
• proposing a fix for a failing lint check or a simple test,
• generating a change description or release notes.

In CI, give the tool only minimal permissions: read access to the repository, comments on pull requests, no access to production secrets and no deployment. Output from CI is a proposal that a person decides on.

How to measure the benefit?

Without measurement you cannot tell whether the team has become faster or is just generating more code. Track these before and after the pilot:

Metric	What it shows
Lead time (from first commit to deployment)	Whether work reaches users faster
Time waiting for review	Whether the bottleneck has shifted to reviewers
Pull request size	Whether the team keeps steps small
Share of deployments that cause a failure	Whether speed comes at the expense of quality
Number of fixes after merge	How much work comes back

Supplement the data with a short developer survey: where the tool helps them and where it slows them down.

What to do now

• Pick a pilot repository with tests and CI, and two or three developers.
• Measure baseline lead time, review time and pull request size.
• Write a CLAUDE.md with commands, architecture and rules.
• Set up shared permissions and block access to secrets.
• Introduce hooks for formatting and linting.
• Agree on the workflow: plan, tests first, small pull requests, human review.
• After the pilot, evaluate the data and decide whether to expand.

If you want to start quickly and properly, we have prepared a one-day AI-assisted development workshop with Claude Code, where your team sets up the repository and workflow on its own code. If you need long-term technology leadership, including bringing AI into development, take a look at our Fractional CTO service. And if you want to see AI-assisted development in practice on a new product, see MVP in 14 days. Write to us via the contact form and arrange a no-obligation consultation.