Agents write the code. You set the standard.
Coderbuds Standards is our opinion of what good code delivery looks like — applied automatically, with nothing to configure. Your coding agents check their work against the standard before opening a pull request, and Coderbuds reports whether the standard held. It's on by default for every team; one switch turns it off.
From watching your work to shaping it
Dashboards tell you what happened. Standards change what happens next. When an AI coding agent is about to open a pull request, it can ask Coderbuds whether the change fits how your team ships — and get an answer it can act on immediately: open it, trim it, or split it first. The expensive loop of open → stall in review → "too big, please split" → rework collapses into a pre-flight check that takes seconds, before any reviewer's time is spent.
Two standards before review starts
Reviewable size
Does the code surface fit in one useful review? Tests, prose, generated files, assets, and moved code are discounted so the standard judges what a reviewer actually has to understand.
Scope coherence
Does the change present one outcome to approve? One review goal fits, two prompt a check that they must ship together, and three or more should be split — even when the diff is small.
How the size standard is calibrated
The Floor
Hard limits nobody should cross. A pull request beyond ~8,000 changed lines is effectively unreviewable — the verdict is always split required.
The Coderbuds Standard
Our opinion of good, applied by default. Changes over 400 lines get a caution — the point where review quality measurably drops — even if your team habitually ships bigger.
Your Observed Norms
Derived from your last 90 days of merged PRs: median and p75 size, and how long each size takes your team to merge. Context that makes the verdict concrete, not generic.
The layers answer different questions. The floor is physics. The standard is aspiration — data about your own habits can never tell you to do better than you already do. The norms are honesty: they show the gap between how you ship and where the standard points.
The pre-flight fit check
The standard is enforced through assess-change-fit, a tool on the Coderbuds MCP server. Your coding agent passes the size of its working diff and gets back:
- One overall verdict — fits, caution, or split required — plus the separate size and scope results that produced it.
- Scope coherence — the agent lists the distinct outcomes a reviewer must approve. Supporting UI, API, migrations, tests, and docs for one behavior count as one goal, not five.
- Your team's norms — "your median merged PR is 320 lines; large PRs take you ~40h to merge vs ~3h for small ones — splitting ships sooner."
- Review-queue pressure — how many PRs are already waiting on a reviewer, so agents don't pile onto a saturated queue.
- Reviewable-surface awareness — agents can pass
test_linesandmoved_linesso the verdict discounts test coverage and relocated code — a raw line count punishes tests and double-counts refactors.
verdict: caution
"This change (612 lines) exceeds the Coderbuds 400-line standard —
review quality drops off sharply beyond that size."
"Trim or split to stay inside the 400-line standard."
Wiring it into your coding agents
Connect the Coderbuds MCP server, then add one instruction to your repo's agent guidance (e.g. CLAUDE.md):
Before opening a PR, call Coderbuds `assess-change-fit` with
`git diff --numstat` and the distinct review goals in the working change.
If the verdict is not "fits", follow the guidance and record the decision
before opening anything.
That's the whole setup. From then on, every change your agents ship starts with a check against your box.
Proven in Slack, not taken on faith
Advice that nobody remembers is just noise. Coderbuds records every fit check and links it to the pull request that followed, so the standard is accountable. Enable the Change Fit Advisor agent and it posts a summary to Slack when there's something worth saying:
📋 Pre-flight fit checks: 12 run this week (8 fit, 3 caution, 1 split required).
✅ 2 advised changes were reduced or split before opening.
⚠️ Advice ignored: PR #4242 opened at 6,900 lines after a split_required
verdict — still awaiting review 28h later.
👻 3 large PRs opened without a pre-flight check.
You see adoption (are agents checking?), compliance (was advice followed?), the cost of ignoring it (the stalled PR is the receipt), and coverage gaps (repos not wired in yet). When the standard holds, it stays silent.
If 400 is wrong for your team, it moves
An opinion you can only obey is a rule. When an agent overrides a verdict it records what it did and why with record-change-fit-decision — and a run of those overrides is the argument against the standard, in writing. Once the record shows a threshold firing on changes that keep turning out fine, Coderbuds moves the line itself and tells you in the weekly digest:
🛡️ Standards: 9 fit checks, 3 ignored. Size standard moved
400 → 800 lines, on 10 recorded overrides.
The new number is the median size of the overrides themselves — the size your team keeps deciding is fine, not a guess — capped so one enormous change can't carry the line with it. Split required verdicts never count: no amount of overriding those will talk Coderbuds into blessing an unreviewable change.
Automatically, it only ever moves up — Coderbuds will never quietly make itself noisier. But you don't have to wait for the evidence: if you already know your number, set it with set-change-fit-standard, tighter or looser, and from then on it's yours and Coderbuds stops adjusting it.
One switch, not a settings farm
There is deliberately nothing to configure. Coderbuds Standards is on for every team from day one; if you'd rather rely only on your own observed norms, untick Coderbuds Standards under Team Settings → Agent Context. As we add further opinions of good code — review turnaround, deploy cadence — they'll be part of the same standard and the same switch.