Coding Agents Are Team Tools Now. You Need Rules, Not Vibes

Coding agents stopped being a solo trick your best engineer runs on the side. They now write real code that ships. Claude Code alone accounts for roughly 4% of all public GitHub commits as of April 2026. That is a lot of production code coming out of a tool your team may still be using with no shared rules. Let me catch you up on what changed and what you owe your team by the next review.

The onboarding doc the agent actually reads

The first shared artifact your team needs is a file called CLAUDE.md. It sits in your repo. The agent reads it at the start of every session. It holds your build commands, your naming rules, and the mistakes you keep correcting. One engineer described the agent as a brilliant new hire who has amnesia every morning. CLAUDE.md is where you write the stuff down once so nobody re-explains it daily.

The counterintuitive part: shorter is better. Frontier models reliably follow only around 150 to 200 instructions, and the agent's own system prompt burns about 50 before your file even loads. Stuff it with things the agent could read from the code itself, and the rules that matter get diluted. The recommendation is to keep it under 200 to 300 lines and delete half of what the auto-generator gives you.

What earns a spot: commands the agent can't guess, your conventions, and the running record of every correction. What doesn't: your dependency list and a directory tree it can list on its own. That is token tax with no payoff.

Knowing the answer is not the same as doing it

Here is the trap nobody warned your team about. The agent can describe good engineering process in detail. Ask it to plan before coding, and it gives a textbook answer. Tell it to build, and it skips straight to implementation. Jesse Vincent, who built the Superpowers framework, put it plainly: "Comprehension and compulsion are not the same thing."

Better prompting won't fix this. The agent doesn't lack knowledge, it lacks a reason to follow the process. So teams are adding structure around it: plugins that force a plan before code, and review tools that catch the sloppy output. One tested review tool, CodeRabbit, is blunt about its job, catching low-quality "AI slop" that technically works but would be a headache for whoever touches it next.

The practical read for you: a human still has to know what correct looks like. One SRE built a kubectl command with the agent, then caught that a restart-count filter was measuring the wrong thing. The tool is fast. Judgment is still yours.

The bill you can't see

A long agent session shows a huge token count, and leaders panic. Most of that number is often reused context, not fresh work. The agent resends the same system instructions, tool definitions, and project files every turn. When the start of a request matches an earlier one, that stable prefix gets read from cache instead of reprocessed. Cache reads are billed at roughly 10% of standard input cost. So a long, coherent session can stay cheap.

The expensive event is a transition, not a big number. Switch models mid-session, connect a new tool, or restart, and you pay to rebuild the whole prefix from cold. The habit that saves money also improves clarity: put durable conventions in CLAUDE.md, keep the current task in the conversation, and don't switch models as a reflex.

What this means for your team: teach people to watch the ratio of cache reads to fresh input, not the raw token count. If cache reads suddenly collapse, look for a config change before blaming the tool.

More tools makes the agent worse, not better

The instinct is to give the agent every tool and every plugin. That backfires two ways. Stack too many and every response slows down. One tester noticed real latency once a dozen skills and MCP servers loaded at once, most of them irrelevant to the task. Accuracy drops too. The guidance is direct: the agent's ability to pick the right tool degrades once you pass roughly 30 to 50 available tools. Cost is annoying. Misrouting destroys trust, because a confident wrong action looks just like a right one.

Subagents follow the same logic. A specialized instance keeps its messy intermediate work out of the main conversation. Useful, but adding more agents can easily make the workflow worse if you delegate without discipline. The pattern across all of this is the same: give the agent the smallest relevant surface, not the biggest possible one.

The deep cut

There is a difference between which tools an agent can find and which tools it is allowed to use, and treating them as one problem is how an agentic pilot stalls the moment a security review begins. Tool search solves discovery. It ranks tools by relevance. It says nothing about permission. If search is your only filter, every privileged tool that can move money or change an entitlement is one plausible query away from being in play.

The fix that got shipped: you can now add and withdraw tools mid-session without breaking the cache, so the agent's reachable actions become a function of verified state. Grants become logged events you can point to in a review. The question a reviewer actually asks is not "what did the agent do" but "what was it able to do, and who decided that." If you own a product that lets agents take real actions, that log is the thing that gets you through the review. Build it before you need it.

Three questions for your team

1. Do we have one CLAUDE.md checked into the repo, under 300 lines, that every engineer maintains? Or is each person re-explaining our conventions to the agent alone?

2. Who reviews agent-written code before it merges, and what tool or step catches the plausible-but-wrong output? Name the gate.

3. For any agent that can take a real action in our product, can we produce a log of what it was allowed to do and why? If not, what's blocking us before the next security review?