Output goes up immediately and the bottleneck moves.

Writing code stops being the constraint and reviewing it becomes one, which is a better problem to have and still a problem.

The teams that get value from it are the ones that change their process to match. The teams that treat it as a faster typist end up with more code than they can verify, which is not an improvement.

We rebuilt our own website with it, so this is a report rather than a prediction.

What it actually is

Claude Code is a coding agent that runs in the terminal, with access to your repository. It reads files, writes changes, runs tests and commands, and works through a task across many steps. A code-completion tool suggesting the next line is a different thing, and the difference is what changes how a team works.

The unit of work stops being a line and becomes a task.

What changed for us

Over one month on our site rebuild we ran 784 commits and merged 210 pull requests, the largest month that project has had. That is not a claim that it made us four times better engineers. It is a measure of how much more work reaches the point of being reviewable.

That is the honest headline: the volume of work arriving at review went up sharply, and everything downstream of review had to change to cope.

What got faster. Migrations and repetitive restructuring, the work that is well understood and tedious. Test writing. Tracing a bug through a codebase nobody has looked at for a year. Anything where the shape of the answer is known and the work is in the doing.

What did not. Deciding what to build. Anything where the hard part is the judgement and not the typing. Work that needed a conversation with a person first still needed a conversation with a person first.

The three failure modes we hit

Review becomes the bottleneck, and then review gets skipped. This is the dangerous one. When more changes arrive than a person can genuinely read, the temptation is to skim. A change that looks right and was not read is worse than one nobody wrote. We ended up with a standing rule: the session that wrote the code never reviews it. A fresh review with no context on how the code came to exist catches what the author would wave through.

Work that goes to the wrong place. Our worst hour came from correct, tested work merged to a branch nothing deployed from. Nine fixes, reviewed and working, that reached nobody, while everyone believed they had shipped. Faster output makes process mistakes more expensive, because more work sits behind each one.

Changes wider than the task. An agent asked to fix one page will happily improve four. Every one of those improvements is a thing to review and a thing that can break. We now scope the working tree to the job.

What we changed to make it work

One task, one branch, explicit paths. Never a blanket add. When two sessions run against the same repository, one will sweep the other's uncommitted work into its commit, and the result looks like your work half shipped.

The reviewer is never the author. Stated above and worth repeating, because it is the control that catches the most.

Verify where the user actually looks. Our most instructive bug was invisible in the markup and obvious in the rendered text: a cleanup removed empty anchor tags, and on two pages the only content of one of those tags was the space between two words. The code was correct. The page read "Line Itemsif you sell". Reading the diff hid it.

Write the rules down where the tool reads them. House conventions, branch rules, what not to touch. Guidance that lives in someone's head applies to the work that person happens to do.

What this means if you are considering it

It is not a headcount decision. Treating it as a way to do the same work with fewer people misses where the gain is, which is in what a team can attempt.

Your review process is the constraint. If review is already a rubber stamp, this makes that worse quickly. Fix that first.

Your test coverage matters more than it did. More changes per week against a codebase with no tests is a bad trade. With decent tests it is a very good one.

Codebase quality pays off twice. A clean, conventional codebase gets much better results than a tangled one, because the agent reads the same cues a new engineer would.

The security part, briefly

A coding agent reads your repository, which means your secrets if they are in it, and it runs commands. Two practical measures: keep credentials out of the repository and scanned for on commit, and be deliberate about what the agent is permitted to run without asking. The same least privilege thinking applies here as anywhere else an agent acts, which we covered in where we put the limits when we connected HubSpot to Claude over MCP.

If your work touches personal information, the Australian framework that applies to you does not change because the AI is writing code rather than making decisions.

In short

Give a team a coding agent and the amount of work reaching review goes up a long way. That is the whole story, and every consequence follows from it.

The teams that benefit change their review process, keep tasks narrow, verify where the user actually looks, and write their conventions down. The teams that do not end up shipping more code they have not read.

Frequently asked questions

What is Claude Code? A coding agent that runs in the terminal with access to a repository. It reads files, edits them, runs tests and commands, and works through a whole task instead of suggesting the next line.

Does a coding agent replace developers? No. It removes the typing constraint, which moves the bottleneck to review, judgement and deciding what to build. Those remain human work and become more important as output rises.

What is the biggest risk of adopting a coding agent? Reviewing less than you ship. When more changes arrive than a team can genuinely read, review turns into skimming, and an unread change that looks correct is harder to catch than an obviously bad one.

What makes a team get more out of it? Existing test coverage, a codebase that follows consistent conventions, a review process that is real, and written-down house rules the tool can read.

Sources


Thinking about rolling a coding agent out to your team? Talk to us.