Claude Code

Claude Code is Anthropic's agentic coding tool. It runs in the terminal and inside the IDE, reads a repository, edits files, runs commands and opens pull requests, each step driven and approved by the engineer using it rather than left to run unattended.

What it changes for us is the ratio. A senior engineer still decides what to build and still owns the result, but far less of their day goes on the mechanical majority of the work: reading into an unfamiliar codebase, mapping a dependency, extending test coverage, carrying a rote refactor across two hundred files, writing the migration nobody wants.

What it does not change is the bar a change has to clear. Code the tool helped write goes through the same review, the same tests and the same CI as code a person typed, with a named engineer accountable for it. Nothing merges because a model produced it.

The setup matters more than the install. The project instructions, commands and house conventions that make output look like the codebase it is joining live in the repository, versioned and reviewed like any other file, which is also what makes the tool useful to the next person rather than to whoever configured it.

What we put in place before it touches a repository, on our own work and on client engagements:

• Exclusions for secrets, credentials, customer data dumps and production fixtures, with secret scanning in pre-commit hooks and CI, so a key cannot reach a prompt or a commit in the first place.
• Which repositories are in scope and who holds a seat, re-checked on a schedule rather than at launch only.
• Where a repository contains personal data, a written record of what is processed, where, and what is retained, established against the terms that apply to that contract, not assumed from a vendor page.
• Provenance and licence checks in review, so every dependency and every snippet that ships can be accounted for line by line.
• A short set of house patterns: what the tool is good at, and the places where accepting its first answer reliably creates rework.

It is not a replacement for engineers, and a team that treats it as one produces more code and more defects at the same time. It is weakest exactly where the work is hardest: architecture with long-lived consequences, a subtle concurrency bug, anything that depends on context that was never written down. Those are the parts we are paid for, and they stay with people.

On client work we use it where the engagement allows it, and we say so up front. Where a contract, a security review or a data-protection constraint rules it out, we work without it. That is a normal answer, not a negotiation.