In my last post, I wrote about how senior developers are getting disproportionate productivity gains from AI-assisted development. Multiple 2026 studies confirm the pattern: the more experienced a developer is, the greater the productivity impact. A Fastly survey put a specific number on it — senior engineers generating AI-assisted code at 2.5 times the rate of junior developers.
The people who know their craft the most are extracting the most from these tools. That’s great news for individual senior developers. It’s a management problem waiting to happen.
The Divergence Problem
Walk into almost any large engineering organization today and you’ll find the same pattern: AI adoption is wide but uneven. One team is deep into GitHub Copilot. Another is on Kiro because someone made that call when they were building AWS infrastructure. A couple of senior engineers have gone rogue with Claude Code and are shipping at a pace that makes their colleagues nervous. And there’s always at least one team that’s barely using any of it.
The result isn’t just inconsistency. It’s divergence: in patterns, in code quality, in how decisions get made, in what the codebase looks like six months from now.
And here’s the specific bottleneck that doesn’t get talked about enough: when your best AI-adopters are merging code faster, they flood the review pipeline. Research from Faros AI found that teams with high AI adoption merge 98% more pull requests. PR review time increases 91%. The individuals are winning. The team is struggling to keep up.
Individual AI skill, uncoordinated, creates new team friction.
Step One: Pick One Tool
Before you can operationalize anything, your team needs to be on the same tool. This isn’t a small ask. There are real switching costs and real preferences involved. But shared assets, shared patterns, and shared workflows only work if the team is reading from the same playbook.
Tool selection isn’t a technical decision. It’s a team decision. Start by understanding how your team actually works: the shape of your backlog, the size of your codebase, how developers spend their time. Then let developers try the leading options. What people will actually adopt and stick with matters more than what looks best in a comparison matrix.
The market has settled into three broad categories, each with a different fit:
- IDE-integrated assistants (GitHub Copilot) — best for teams deeply embedded in an existing ecosystem, where inline suggestions and chat fit naturally into the current workflow
- Agentic IDEs (Cursor, Kiro) — best for teams doing complex, multi-file, spec-driven work, where the tool plans before it codes
- Terminal/CLI agents (Claude Code, GitHub Copilot CLI) — best for teams doing deep codebase reasoning, automation, and multi-step architectural work across large codebases
Factor in your existing relationships too. If you’re already on GitHub Enterprise, that’s a real consideration. Not because it should be the only factor, but because it affects cost, procurement, and support in ways that matter when you’re rolling something out across a team. The tooling landscape is also moving fast: Amazon Q Developer’s IDE plugins are being sunset in favor of Kiro, so if you’re in the AWS ecosystem, the direction of travel is already decided.
Then standardize on what fits. Not what someone mandated, not what’s newest, not what the loudest developer on the team prefers. What your team will use consistently — because consistent use of a good tool beats sporadic use of a great one every time.
Treat AI Assets Like Engineering Assets
Here’s where most teams stop short. They pick a tool, maybe share a few prompts in a Slack channel, and call it done. That’s not operationalization. That’s just hoping.
The real leverage comes from treating your AI assets — your instruction files, your agent definitions, your prompt templates, your MCP configurations — with the same engineering discipline you apply to your code. That means:
- Version control them. They live in the repo. They get reviewed. They get merged through your normal process.
- Own them. Someone is responsible for keeping them current. They’re not a one-time setup, they’re a living artifact.
- Evolve them. When your team learns something — a better pattern, a common mistake the agent makes, a new architectural direction — the assets get updated.
This is a mindset shift. Your AI configuration isn’t a dev tool preference. It’s an engineering asset that shapes every line of AI-assisted code your team produces.
For larger organizations, go further. Distribute your assets as first-class packages. Shared instruction sets, agent definitions, and prompt templates can be published as npm packages, IDE extensions, or tool-specific add-ins that teams pull in rather than build from scratch. That way your standards don’t live in one team’s repo and get copied imperfectly across the org. They have a source of truth, a version, and an owner.
Encode Your Standards
The most powerful thing you can put in those assets is your team’s actual standards.
Your coding conventions. Your architecture patterns. Your naming decisions. Your approach to error handling. The things that currently live in someone’s head, in a wiki nobody reads, or in code review comments that get repeated every sprint.
All of that can be encoded into your agent instructions. When the agent knows how your team works, it produces output that looks like your team wrote it. Not generic AI output that has to be substantially reworked to fit your codebase.
And go further than coding conventions. Feed your agents your Architecture Decision Records. If your ADRs live in the repo, your agents can consume them as context. That means your architectural decisions — why you chose event sourcing, why you’re not using a certain pattern, what your service boundary rules are — become active inputs to every AI-assisted change, not just archival documents. Your governance becomes participatory.
This is the difference between a tool that generates plausible code and a tool that generates your code.
Review the Shape of What Agents Produce
Putting standards into your assets isn’t a one-time configuration. You have to close the loop.
Establish a lightweight ritual. Not a heavy process. Periodically review what your agents are actually producing. Not just “did the code pass review?” but “is the code consistent with our patterns? Is the agent drifting? Are there things it keeps getting wrong that we should correct in the instructions?”
This is a new kind of engineering discipline, but it fits naturally alongside things teams already do. It can live in a retro, in a periodic architecture review, or as a standing agenda item for your tech lead. The cadence matters less than the habit.
Think of it as tending the asset. The agent’s behavior is a function of what you’ve told it. If the output is drifting, the instructions need updating.
No YOLO
This is the non-negotiable underneath all of it: AI-generated code always has a human in the loop. Always.
There’s an irony worth naming here. GitHub Copilot CLI ships with a literal --yolo flag that hands full control to the agent: no confirmations, no review gates, just go. Every big conference demo runs this way: presenter on stage, agent in full autonomy, crowd watching code appear. It’s impressive. It’s also not how you run production software.
The tools are optimized for the demo. Your job is to optimize for the codebase.
When code breaks in production, leadership doesn’t call Claude Code. They call you.
Not because the tools aren’t capable. They’re increasingly capable. But because the failure modes of AI-generated code are specific and subtle. It builds what’s quick rather than what’s right. It introduces the vulnerabilities that new programmers make. It can look correct while violating invariants that only a domain expert would catch.
The senior developers getting outsized productivity gains aren’t shipping AI output directly. They’re directing it, reviewing it, and applying the judgment that comes from a decade of production experience. That judgment is the check.
Your job as a manager isn’t to slow down the AI-adopters on your team. It’s to make sure the review culture scales with the adoption. Faster generation requires stronger review habits, not weaker ones.
The Real Goal
This isn’t about getting every developer to use AI the same way. People will find their own rhythms, their own preferred interactions, their own areas where the tools help most.
The goal is a shared foundation. Your team’s agreed patterns encoded in the tools everyone is using. Your architectural decisions as active context, not forgotten documents. AI-generated code that enters the codebase looking like it belongs there.
Individual AI skill will keep diverging. The senior developers will keep pulling ahead, and that’s fine. Your job as a manager is to make sure that divergence in skill doesn’t become divergence in the codebase.
The teams that figure this out won’t just have developers who are better at AI. They’ll have a codebase that reflects it.