AI agents in your development team

How this differs from AI agent implementation

This page is not about agents that handle the company's business processes — reading tickets, updating the CRM, preparing quotes. Those are covered under AI agent implementation, linked above, and there the project starts with permissions in the company's systems. This page is about coding agents — Claude Code, GitHub Copilot, Cursor and the like — in developers' hands: making their use in your repository stop depending on who happens to be at the keyboard, and become a process the team repeats, reviews and measures.

Who this service is for

A CTO, head of engineering or software-house owner who already pays for agent tooling and sees one of three things:

use is uneven — two people do half their work with the agent, the rest do not touch it or use it quietly, on private accounts;
review discipline is slipping — there are more changes and no more people reading them, so code nobody understands reaches the main branch;
in a mature codebase the agent breaks more than it helps — because it does not know the conventions, does not run the tests and does not know what it must not do.

The common denominator: the tool is there, the process is not. We build that process with the team: rules in the repository, gates and review.

What you get

Repository instructions and agent skills — CLAUDE.md, rules and skills fitted to the conventions of your code. An instruction is not a safeguard, which is why alongside it comes:
environment and permission configuration — what the agent may read, run and change, and what it never may; secrets out of its reach;
approved tool access — with an MCP server only where the process genuinely lacks an integration; how we build one is set out on our Connecting an AI assistant to your system (MCP) page;
task templates for the agreed family of tasks — what the agent gets as input and what it has to hand back;
tests and CI gates that every change written with an agent has to pass;
review requirements — what the reviewer checks in such a change and what they must not let through;
examples of accepted changes from your repository, as the pattern;
a record of what worked, what did not, and why;
team practice on real backlog items — not on exercises.

How we work

One repository, one team. Not "AI adoption in the IT department", but a place where before and after can be measured.
One family of tasks — tests for existing code, a bounded feature, a reproducible bug, a narrow dependency upgrade. Something that comes back every week, not a one-off migration.
A tool that fits the team. We work with the one you already license, and if the choice is open, we help pick the one that suits your code and way of working.
On the real backlog. The first tasks we do together, the next ones the team does and we review. We finish when the team repeats the process without us.

The stages, the concrete deliverable at the end of each and the split of decisions are the same as in every project we run — they are set out in our delivery methodology. The process in the repository is also often one stage of a wider AI implementation.

Acceptance and measures

We sign off when:

the team repeats the process without us in every session;
changes meet the agreed review and test rules;
no secret has reached a prompt, a log or a change;
the agent's failures are visible — in CI, in review, in the log — rather than hidden in merged code.

We measure four things, before and after: time from picking up a task to merging it (lead time), reviewer time per change, the share of changes reworked after review, and the number of defects that reached production. We do not measure lines of code generated — that number also rises when a team gets worse.

Learning during the implementation

The team learns to work with the agent as part of the implementation: on your code, on your tasks, with rules, gates and review that stay in the repository. That way the learning carries straight into day-to-day work and ends in a process rather than in slides. We run training the same way in every AI implementation. The rest of our working principles are in our standards.

How we prepare the repository and the team

A stable build and tests first. If the build is unstable, tests are missing or nobody owns part of the code, we put that in order first, in a separate, separately priced stage of engineering work. That way the agent speeds up good work rather than the growth of technical debt.
Code review stays with people. The agent prepares the change, and a reviewer from your team decides whether it is merged.
We agree the split of work together. We decide with you which tasks the agent writes and which stay with people.
We match the tool to the team. We help choose the one that suits your code, and work with the licences you already have.
The agent works away from production and secrets. It gets only what it needs for the task.

Where the code goes

A coding agent sends fragments of code to the model provider. On what terms, how long they are retained, how company accounts differ from private ones and what applies to MCP servers — we set that out using the example of Claude Code for business; a comparison of the plans and terms of other tools is in our note on Copilot, ChatGPT and Claude for business. A company account, not a private one, is a condition of starting. The split of roles for personal data — and a repository holds more of it than you think — is on our security and GDPR page.

Scope and price

A fixed scope and a fixed price for a specific stage — not open-ended consulting hours.

We set the scope and the price after seeing the repository — the build, the tests, CI and the way reviews are done — and after choosing one family of tasks from your backlog.
Fixed scope of a stage: one team, one repository, one family of tasks, agreed before-and-after measures. An advance before the start, the remainder on acceptance.
Outside the quote: tool licences and model usage, work on the code itself (a broken build, missing tests) and extension to further teams — that is a separate stage.

For teams that want to keep the process working after a change of tool or model, we offer care after handover within an agreed hour allowance, during business hours.

Frequently asked questions

How does the team learn to work with Claude Code or Copilot?

During the implementation, on real backlog items. We implement a process in one repository: the agent's instructions and permissions, task templates, tests and CI gates, review requirements, and the team's practice on real work. The team learns on its own code, and what remains after the project is a process in the repository that people who join later can use too.

Which tools do you work with?

The one your team already licenses or is about to license — most often Claude Code, GitHub Copilot, Cursor or Codex. If the choice is still open, we help match the tool to your code and the way your team works, and our note on Copilot, ChatGPT and Claude for business sets out how the plans and terms differ. We connect an MCP server where the process lacks an integration with your systems.

How long does it take and what does it cost?

We set the scope and the price after seeing the repository — the build, the tests, CI and the way reviews are done — and after choosing one family of tasks from your backlog. Pricing is per stage, at a fixed scope and a fixed price: one team, one repository, one family of tasks, agreed before-and-after measures. The first stage is usually counted in weeks. Tool licences and model usage sit outside the quote.

How do you keep the quality of code written with an agent high?

The process starts with review rules, tests and CI gates rather than with prompts. A change written with an agent passes the same gates as any other, and the reviewer gets a list of what to check in such a change. We measure quality before and after: the share of changes reworked after review and the number of defects that reached production. If either measure gets worse, we improve the process before extending it to further tasks — however much code was produced.

What about the security of the code and of secrets?

Three conditions are non-negotiable: a company account, not a private one; rules that forbid the agent to read secrets and data or to run commands outside the permitted scope; and no access to production. A coding agent sends fragments of code to the model provider — on what terms, how long they are retained and what applies to MCP servers is set out in our note on Claude Code for business. The split of roles for personal data is on our security and GDPR page.