Getting Coding Agents Working in Your Team
Most teams have tried coding agents; fewer have made them stick. The gap is rarely the model. It is the missing scaffolding, and here is what that scaffolding consists of.
On this page
Most engineering teams have now tried coding agents. A much smaller number have made them a normal part of how work gets done.
The difference is almost never the model. It is whether anybody built the scaffolding that makes an agent reliable inside a particular codebase.
The usual arc
It goes roughly like this. A few engineers try an agent and are impressed. Enthusiasm spreads. Within a month or two, output quality becomes uneven: code that ignores local conventions, changes that are confidently wrong in unfamiliar parts of the system, review queues filling with diffs nobody wants to read closely.
Trust erodes quietly. Nobody announces they have stopped; usage just drops back to the two or three people who worked out their own approach.
The tooling was not the problem. Nothing was set up.
Conventions the agent actually reads
The single highest-leverage artefact is a project instruction file that encodes what a new senior engineer would need to know: architecture and why it is that way, naming and structure conventions, how testing works here, what is deliberately not done, and the things that must never be touched without a human.
Most teams have some of this in a wiki nobody opens. The difference is that an agent reads it every time, without getting bored.
Be specific. "Follow existing patterns" is useless. "API routes validate input with Zod at the boundary and return typed errors; see the contact route for the reference implementation" is actionable.
Skills for repeated work
Every team has workflows it repeats: adding an endpoint, writing a migration, onboarding a service to monitoring. Capture one once as a reusable skill and every engineer gets the same result, instead of each of them rediscovering the house style.
This is also where institutional knowledge stops evaporating when someone leaves.
MCP servers, so answers come from your data
An agent that cannot see your systems is guessing. MCP servers connect it to the real thing: internal APIs, ticketing, documentation, observability.
The difference in practice is between "here is a plausible answer about your deployment process" and "here is what your pipeline does, having read it".
Start with read-only access to the systems people ask questions about most. Write access comes later, if at all.
Guardrails that are enforced, not documented
Decide explicitly what an agent may do unsupervised, what needs a human, and what it must never do. Then enforce it through permissions, not instructions, because an instruction is only a suggestion.
A reasonable starting point: reading anything is fine; writing to a working branch is fine; touching production, secrets, or infrastructure state needs a person. Tighten or loosen with evidence.
Agents in CI
Once local usage is working, CI is where agents earn their keep unattended: a first-pass review flagging obvious problems before a human looks, test generation for uncovered paths, dependency-update triage.
The rule that keeps this useful is that an agent in CI may advise and must not merge.
Measure it, and be willing to find nothing
Take a baseline before rollout: cycle time from first commit to merge, review turnaround, proportion of changes needing rework after review. Compare a few months later.
Some of what teams attempt with agents is not worth doing, and the measurement is how you find out. A rollout nobody evaluated is indistinguishable from one that did not work.
Where to start
If you do one thing, write the conventions file. It is an afternoon of work, it improves output immediately, and it is useful to human engineers too.
Everything else in this list is worth doing, but none of it compensates for an agent that does not know how your codebase is meant to be written.