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.
Three layers, one verdict
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:
- A verdict — fits, caution, or split required — with the reasoning spelled out in plain language.
- 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, run `git diff --shortstat` and call the Coderbuds
`assess-change-fit` tool with the numbers. If the verdict is not "fits",
follow the guidance (usually: split) 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.
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.