Claude Code in a team: what changes when the agent runs in the terminal

Terminal coding agents changed the shape of a working day more than editor autocomplete did, and not for the reason people expected. The speedup on writing new code is nice. The change that matters is that a class of work nobody used to do now gets done: the migration across two hundred files, the test suite for the module everyone avoided, the investigation into why a service is slow that used to require a free afternoon.

Here is what we learned running these tools across a consulting team and several client codebases.

Where the gains are actually large

Mechanical change at scale. Renaming a concept across a repo, migrating a deprecated API, adding a parameter through a call chain. These were always possible and always not worth a person's week. An agent does them in an hour and, crucially, does the boring eightieth file as carefully as the first.

Understanding unfamiliar code. Dropping into a client codebase and asking what happens when a request hits this endpoint saves the first two days of every engagement. This is the single highest-value use in consulting and it involves writing no code at all.

Tests for existing behaviour. Characterisation tests around a legacy module, generated from the code and then run to prove they pass. This is high volume, low creativity work with an automatic correctness check, which is precisely the shape agents are good at.

The task you would have skipped. Fixing the flaky test, writing the runbook, cleaning up the logging. The marginal cost of small maintenance dropped enough that the work happens.

Where it is oversold

Anything requiring a decision you have not made. An agent will happily implement the architecture you vaguely gestured at, thoroughly and in the wrong direction. The failure is not bad code; it is a large volume of coherent code committed to a premise nobody examined. Spending ten minutes writing down the approach before starting is the single highest-return habit.

Also anything where the feedback loop is missing. Agents are strongest where they can run something and see it fail — tests, type checks, a linter, a build. In a codebase with no runnable tests, output quality drops sharply, and the honest read is that the agent is only as good as your CI.

What we had to change

Review became the constraint, so review had to change. Diff size went up; reviewer attention did not. We split review into two questions asked separately — is this the right change, and is this change correct — and moved the first one earlier, into a written plan before the code exists. Review gates for agent-written code is the longer version.

Context files earned their keep. A CLAUDE.md at the repo root describing the build commands, the layout and the three local conventions removes most of the repeated correction. It is the highest-leverage file in the repository now; we wrote about what goes in it.

Permissions needed a policy. An agent that can run arbitrary shell in a repo with cloud credentials in the environment is a production incident waiting for a bad day. Ours run against read-only cloud roles by default, with writes going through the normal pipeline.

We stopped counting lines. Any metric based on volume became meaningless in a week. What we track now is cycle time from problem to merged change, and the defect rate after merge.

Cost, honestly

Per engineer it is a subscription in the tens of euros a month, or usage-based billing that for heavy days lands higher. Against a loaded engineering cost it is noise, and the question is not price but whether the review capacity exists to absorb the output. In teams where one senior reviews everything, the agent makes that person the bottleneck and the team slower. That is a real failure mode and it is organisational, not technical.

What to do this week

Take the maintenance task everyone has been deferring for two months — the dependency upgrade, the missing tests, the dead code — and give it to an agent with a clear written statement of what done looks like. It is a low-risk task, it has a natural correctness check, and it tells you more about the tool's fit for your codebase than any benchmark.