Every engineering team that’s been around for more than a year or two has the same thing in common: their codebase has conventions. Not the ones in CONTRIBUTING.md (those are usually outdated). The real ones — the patterns the team actually uses. Where state lives. How errors get handled. What services/ means versus lib/. Whether a model gets a serializer or whether the controller composes the response itself. The shape of a job, the shape of a test, the shape of a feature flag.

Those patterns aren’t free. They came out of two years of pull request reviews, three post-mortems, an architecture refactor in 2023, and one slack argument between your two staff engineers that you’d rather forget. They’re load-bearing. They’re how your codebase stays coherent as it grows.

And in 2026, they’re at risk of being quietly diluted.

The thing nobody quite wants to say about AI coding tools

When an AI coding agent writes a PR in your repo, it doesn’t know any of that history. It writes whatever pattern it picked up from public code. Usually close to your team’s pattern. Sometimes meaningfully different. Multiply that across every PR your team ships and your codebase starts to look like a Vendiagram of every public Rails app, every public React app, every public Go service, with your team’s actual patterns surviving in the overlap.

The problem isn’t model quality. The problem is context. The agents are doing exactly what they’re asked to do. They just don’t know what your team agreed on, because nobody wrote it down, because the conventions live in the shape of the code your team has already written.

That’s normally fine, because new humans on the team absorb the conventions by reading the existing code and getting review feedback. But agents write at machine speed. They generate hundreds of lines that all look reasonable against a generic Rails app and don’t quite fit against your specific Rails app. The drift compounds because the gap between “this works” and “this is how we do it” doesn’t get closed at review. Reviewers tire of writing the same comments and start letting more through.

What pinning the index actually does

Scrubby’s job is to be the context layer that closes that gap. It indexes your repo, derives conventions from the actual code, and surfaces them to your AI tools (via MCP) and to your PRs (via the GitHub App). That alone shifts the baseline. But there’s a sharper move available: pin the indexed window to a date before your team started using AI heavily.

When you set an index cutoff date on a repo, Scrubby treats commits made after that date as if they didn’t happen, for the purposes of learning what your codebase looks like. The file tree, the conventions, the segment definitions, the domain classifications, the co-change weights, everything Scrubby derives comes from the cumulative state of every commit up to and including the cutoff. The repo is reviewed against that pinned understanding going forward.

The practical effect: when an agent submits a PR next week, the conventions it’s held to are the ones your team established. Not the ones the model defaults to. Not the ones that drifted in over the last three months. The version of the codebase you and your senior engineers would have signed off on.

It works at the org level

Most teams maintain more than one repo. Scrubby’s cutoff is per-repo, which is the right unit. An API repo and a frontend repo have wildly different conventions and need to be pinned independently. The dashboard rolls up every repo your team has connected, showing at a glance which ones are pinned, what their cutoff dates are, and how their indexing state is doing. If you maintain three services and a frontend, each one stays consistent with itself and with the team’s intent for it.

Cross-repo convention propagation, a pattern learned in one repo automatically flagging violations in another, is on our roadmap. For now, per-repo isolation is the unit, and that already covers the dominant use case.

What this isn’t

It isn’t a way to keep AI out of your codebase. AI is going to keep writing code in your repos; that’s not the question. The question is whether the code it writes adheres to your team’s standards or to a synthetic average pulled from the open-source corpus. The cutoff is how you make that choice deliberate.

It also isn’t a permanent state. The cutoff is meant to be advanced. As your team validates that the AI-assisted code that’s been landing genuinely matches your conventions, you can move the cutoff forward. Or as new senior-led patterns get established, you can re-pin to a later date that includes them. Scrubby will start prompting you to revisit your cutoff after it’s been in place for a while, so the state doesn’t drift into “set and forgotten.”

Try it

If your team is using AI tools meaningfully and has been wondering whether they’re starting to erode the patterns you spent years building, this is the lever. Index a repo, pin the cutoff to a date that predates AI in your workflow, and watch what gets flagged on the next few PRs. Most teams find the answer informative.

Get started with Scrubby or read the docs on how the cutoff feature works in practice.