If you’re leading an engineering team in 2026, you’re probably navigating the same paradox everyone else is. AI tooling has made individual developers measurably faster, but team-level velocity hasn’t moved as much as you’d expect. The individual gains made are getting eaten up somewhere else in the development workflow. But where?!

Most of that gap lives in code review, onboarding, and the often invisible tax of cleaning up code that doesn’t fit your current code conventions. Codebase intelligence, which is what Scrubby provides, closes that gap directly. This post is about why and how.

The Bottleneck: A Compounding Problem

Faros AI’s research on the productivity paradox in AI-driven development found that downstream bottlenecks are absorbing the value AI tools create at the individual level. Writing code faster doesn’t help if the code that’s written needs to be reviewed or rewritten a bunch of times.

If you’ve been a tech lead long enough you know what those bottlenecks look like in practice. The same structural review comments appear on PR after PR, often versions of “this should be in services/, not at the top level.” Co-changes get missed regularly, where a model gets updated but its serializer doesn’t, and the bug shows up two sprints later.

These aren’t problems any individual engineer can solve because they’re knowledge problems. Specifically, they’re problems caused by the fact that the most important knowledge about your codebase isn’t written down anywhere, it lives in the heads of the senior engineers who happen to be free to review the PR that day.

What Scrubby Brings to the Team

Scrubby builds an index of your repository that captures the knowledge that isn’t explicitly stated in your code or your docs; e.g., which files are part of which domain, which domains depend on which others, which files historically change together, and which conventions your team actually uses (versus which are aspirational or an unfollowed mandate). Scrubby then makes that knowledge available in two places:

  1. In the AI editor your team is already using through MCP. When a developer’s agent is about to write code in your repo, it can ask Scrubby what the conventions are for the code it’s touching and get a real answer that impacts it’s output.
  2. In every pull request, through a GitHub App. When a PR opens, Scrubby reviews the changeset against your codebase’s patterns and posts findings directly on the PR.

At a team level, the change is that the connective-tissue work compresses. Your leads spends less time on structural review and back-and-forth with contributors, and fewer co-changes get missed.

The Metrics to Watch

We’ve seen a few patterns hold up consistently across teams that adopt Scrubby.

PR cycle time/time-to-merge drops, especially the first-review iteration. When AI agents have your conventions baked in, the code they produce is closer to mergeable on the first push, reducing the number of review rounds.

Onboarding time shortens and improves. New developers don’t spend their first month or months learning the team conventions or repo patterns through trial-and-error. The conventions are surfaced as they write code instead of being learned through accumulated PR feedback. (I covered the mechanics of this in how AI speeds up developer onboarding.)

Co-change misses drop sharply. Scrubby’s analysis explicitly checks whether expected co-changes are present, which other tools have no clue about and can lead to bugs that don’t surface for a while and are hard to trace to their responsible PR or commit.

Where It Matters

If your team has any of the following dynamics, Scrubby’s effect compounds quickly:

You have a complex legacy codebase. Larger codebases have more conventions and more domain boundaries. The cost of every individual missed convention is higher because the codebase is harder to mentally model.

You’re hiring or onboarding actively. The faster you can get new engineers writing code that fits, the faster they become net-positive contributors to the team.

Your team uses AI agents heavily. AI agents amplify whatever context they have access to. Without codebase intelligence, that amplification works against you. With Scrubby, it works in your favor.

You have multiple repos with shared conventions. Scrubby’s global domain layer carries cross-repo knowledge that gets better over time. Conventions discovered in one of your team’s repos can inform analysis in another.

Roll-Out

The smoothest adoption path looks roughly like this:

  1. Start with one repo. Install Scrubby’s GitHub App and connect the MCP server for the engineers actively working in it. Let it index. Watch the first week of PRs come through with Scrubby’s analysis attached.
  2. Pay attention to the findings. Scrubby surfaces patterns your team is already enforcing implicitly. Some of them will be conventions you didn’t realize were that consistent. Some will be conventions that have drifted and could use a discussion.
  3. Loop in feedback. When a finding is wrong or outdated, dismiss it. Scrubby uses that signal to update its understanding. The system gets more accurate the more it’s used.
  4. Expand to more repos. Once your team trusts Scrubby’s findings on the first repo, add more repos to update and improve Scrubby’s understanding of your team’s conventions.

The Bigger Picture

The teams that are going to get the most out of AI tooling over the next few years are the ones who give their AI tooling the best context. Models are commoditizing and Scrubby is the context layer that turns a generic AI assistant into one that knows how your team builds software. For an engineering lead, that’s the difference between AI tools showing up in individual productivity reports and AI tools showing up in team-level outcomes, which is what moves you org forward.

Sources: