AI agents for development teams

We turn the use of coding agents into a repeatable, reviewed engineering process in your repository — measured on real work, not on the number of lines generated. This page is about agents in developers' hands, not agents in business processes — those are covered under AI agent implementation.

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. A licence will not fix that — rules in the repository, gates and review will.

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 under AI and MCP integrations;
  • 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;
  • an evaluation log — 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.
  • The tool you license anyway. We do not choose for you and we do not sell licences.
  • 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.

This is not a training course

We do not run courses or workshops on coding agents — neither open enrolment nor in-house. A workshop in a room, after which the team returns to a repository with no rules, no gates and no review, changes little. Learning here is part of the implementation: it happens on your code, on your tasks, and ends in a process that stays in the repository rather than in slides. We treat training the same way in every AI implementation — see what we don't do.

What we do not do — and when we advise against it

  • We do not fix a broken build, write missing tests from scratch or sort out code ownership within this service — if that dominates, we sell conventional engineering work separately and leave the agents for later.
  • We do not replace code review with an agent.
  • We do not promise the agent will write everything — we settle what it writes and what stays with people.
  • We do not sell licences and we do not choose the tool for you.
  • We do not connect the agent to production or to secrets.

We advise against the project when the build is unstable, there are no tests or nobody owns the code — the agent would then only speed up the production of technical debt.

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, with no promise of 24/7 availability.

Frequently asked questions

Is this a Claude Code or Copilot training course?

No. We do not run courses or workshops on coding agents — neither open enrolment nor in-house. This is the implementation of 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 backlog items. The team learns along the way, but what remains after the project is a process in the repository, not a slide deck.

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. We do not sell licences and we do not choose the tool for you; if the choice is still open, our note on Copilot, ChatGPT and Claude for business sets out how the plans and terms differ. We connect an MCP server only when the process genuinely lacks an integration, not because it is fashionable.

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.

Will the agent lower the quality of our code?

It can — which is exactly why 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 those numbers rise, the process needs fixing, 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.

Have a task that comes back every week?

Let's pick one — tests, a bounded feature, a reproducible bug — and check on it whether an agent in your repository produces a measurable result. We will also say outright when the build has to be fixed first.

Last updated: