TL;DR

AI coding tools are now default behavior for most developers, not an experiment. If you manage a team and you haven’t formalized this, you have ungoverned spend, security exposure, and inconsistent behavior happening right now. The fix isn’t to take the tools away — it’s to pick one, pay for it centrally, encode your policies into the AI itself using instruction files and skills, and govern the control folder rather than individual usage. Here’s the framework I’d implement.

The Problem Nobody Wants to Admit

A question I’ve been seeing more often: how do you govern AI coding tools when developers are already using half a dozen of them, nobody knows which ones, and engineering leadership has basically blessed the chaos by saying “everyone uses these.”

The problems that follow from ungoverned AI tool adoption are predictable:

  • No visibility — you don’t know which tools are in use, which models are being invoked, or what company data is being sent where
  • No cost control — individual teams are expensing seats without any baseline or budget
  • No security review — none of this went through your normal vendor assessment process
  • No consistency — the AI one developer uses knows your coding standards; the one another developer uses doesn’t

The instinct is to play defense. Lock things down, force review, slow it down. That instinct will fail. Developers using AI tools are 30-40% more productive by any reasonable measure. You taking that away isn’t a neutral act — it’s a significant productivity regression your competitors won’t make. The goal isn’t control for its own sake. The goal is getting the benefits of AI tooling without the exposure.

The Framework

This is a six-step approach. Steps 1-3 get you from chaos to stability in a few weeks. Steps 4-6 are the ongoing operating model.

Step 1: Pick one tool, make it the official option

Start with policy and centralization around a single tool. Make it company-paid and explicitly signed off by leadership. Not “we tolerate this” — “we pay for this and it’s our approved tool.”

The specific tool matters less than the act of centralizing. You need:

  • A single vendor relationship your procurement team understands
  • A single security assessment that covers the tooling
  • A single billing line your finance team can see

For most mid-size engineering orgs, GitHub Copilot is the right answer. It integrates with VS Code (where most developers already work), the per-seat cost is predictable, and — critically — it supports the configuration patterns that make the rest of this framework possible. The fact that it gives access to Claude Sonnet 4.6, Gemini, and GPT-4o in one subscription is also a meaningful advantage over picking a single-model tool.

The developers using Cursor or Claude Code in parallel aren’t your immediate problem. Get the official tool in place first.

Step 2: Find your champions and put them in charge of centralization

Every team has a few people who are the loudest about AI tools. Find them. Put them in charge of centralization. Give them a list of requirements and policies, and ask them to bake those policies into the AI of every repo.

This is the key insight that most governance rollouts miss: you don’t govern AI tools by telling humans the rules — you govern them by teaching the AI the rules.

Every major AI coding tool reads a repository-level configuration file on every request. For GitHub Copilot that’s .github/copilot-instructions.md. For Cursor it’s .cursor/rules. For Claude Code it’s .claude/. These files tell the AI your architecture, your conventions, your security requirements, and your explicit anti-patterns.

If your champions spend two hours writing a good copilot-instructions.md for your core platform repo, every developer touching that repo gets those constraints applied automatically — without any human gatekeeping, without any additional tooling, without any process overhead.

I’ve written in detail about how to structure these instruction files and layer them with purpose-built skill documents in Getting Started with GitHub Copilot: What Actually Works. The short version: write the brief you’d give a new senior engineer on day one. If it’s not in that document, the AI doesn’t know it.

Step 3: Give every repo a baseline instruction set

This is where centralization becomes durable. Your champions don’t need to audit every developer’s individual usage — they need to maintain a set of instruction files that get applied every time the AI is invoked.

The minimum viable instruction set for a repo:

# [Project Name] — AI Assistant Instructions

## Architecture
[2-3 paragraphs describing what this system is, how it's structured, and what
the major components are]

## Engineering Principles
- [Specific to your team. Examples below]
- Tests are required for all new business logic
- SQL queries go through the ORM layer, never raw strings
- Secrets via environment variables only — never in code
- All new services must expose /metrics for Prometheus

## Anti-Patterns (Do Not Do These)
- Do not use deprecated API X — use Y instead
- Do not commit directly to main — all changes via PR
- Do not use the legacy authentication module in /auth/v1 — use /auth/v2

## Security Constraints
- Never output credentials, tokens, or connection strings
- PII data must stay in the [specific encrypted storage system]
- Do not suggest dependencies with known CVEs

This is not a lengthy document — it’s a targeted one. 200-400 lines covering the things a new engineer would need to know to not immediately break something.

The AI memory system post covers how to extend this further with pattern-specific skill documents. Skills are separate files the AI loads on demand — useful for domain-specific knowledge like “how we write Terraform modules” or “how we do database migrations” without cluttering the main instruction file.

Step 4: Form an AI council

This doesn’t need to be a committee with a charter and a quarterly budget review. It needs to be a small group — 2-3 people — whose job is:

  1. Keep the instruction files up to date as the codebase evolves
  2. Limit developers to 2-3 company-blessed model options (not every model under the sun)
  3. Review and accept changes to the central instruction set

The AI landscape is moving fast enough that you need designated people paying attention to it. The models available today aren’t the models that will be available in six months. Your council’s job is to keep the organization using the best options within guardrails — not lock in a single model forever and call it done.

Limiting to 2-3 options isn’t about being the AI police. It’s about reducing the attack surface of models you’ve actually evaluated, and ensuring prompts and instruction files are tuned for the models you’re actually using. An instruction file written with Claude’s behavior in mind may give subtly different results with GPT-4o. Limiting options means you can actually test that your constraints work.

Step 5: Govern the control folder, not individual usage

The .github/ folder, .cursor/ folder, and .claude/ folder are the control plane for AI behavior in your repos. These are the files that determine what the AI knows about your system, what constraints it operates under, and what patterns it applies by default.

If you’re going to assess anything, assess these files. Gate changes to them with a pull request process and a review from your AI council. A developer who modifies the copilot-instructions.md for your payment processing service is changing the behavior of the AI for everyone who touches that service — that warrants a human review.

The AI context window audit post is useful background here — it covers exactly what the AI reads and in what order, which helps you understand what can be overridden at the repo level vs. user level vs. workspace level.

Practically: you’re looking for two things in these files.

  1. Correctness — does the instruction set accurately describe the current state of the system?
  2. Missing constraints — what security or architectural constraints should be in here that aren’t?

This review takes 30 minutes per repo when you do it on a cadence. It’s infinitely cheaper than auditing individual developer session logs or prompt histories.

Step 6: Lead with enablement, not enforcement

This is more of a posture than a step, but it determines whether the whole thing works.

You’re not the cops. You don’t work for the NSA. The developers on your team are using these tools because they make them meaningfully better at their jobs. Your role is to get a tool they can trust, ensure they’re using it inside a safe process (PRs, code review, deployment gates, tests), and give the AI enough context about your environment that it makes good decisions by default.

The framing that works: “I’m here to make sure you can use this at full speed without worrying about whether it’s going to get us into trouble.” That is a genuinely different message than “I’m here to make sure you’re complying with policy.” They lead to different outcomes.

Practically, this means:

  • Make the approved tool better than the unofficial alternatives — invest in your instruction files, keep them current, add skills for common patterns. If the official toolchain is visibly superior, adoption follows.
  • Don’t require human approval for AI-assisted code — require human approval for code, which you already do through code review. The AI is a tool, not an actor.
  • Treat AI suggestions like any other code — it goes through your SDLC, your CI/CD, your tests. That’s the gate. The AI producing it isn’t a special category.

The MCP Layer: Teaching the AI Your Environment

There’s one more piece worth covering for teams with self-hosted infrastructure or internal tooling: Model Context Protocol (MCP) servers.

MCPs allow you to extend an AI assistant with live access to your systems. Instead of asking the AI to guess what’s running in your Kubernetes cluster, you give it a tool that can actually query the cluster. Instead of pasting in Confluence pages, you point it at your internal documentation system.

For governance purposes, this matters because it shifts the AI from “confident guesser” to “informed actor.” An AI that can read your actual infrastructure state is less likely to suggest something that conflicts with what’s actually deployed.

The practical setup: create a service account with read-only access to your lower environments, configure the relevant MCP servers, and let the AI investigate rather than guess. The read token for dev/staging is enough — you don’t need (and shouldn’t have) AI tooling with write access to production.

This is covered in the environment manifests and AI context post if you want the implementation pattern.

What This Looks Like After 90 Days

If you execute this framework:

  • Week 1-2: Tool selected, procurement in flight, champion group identified
  • Week 3-4: Baseline instruction files written for your 3-5 highest-traffic repos
  • Week 5-8: Instruction files rolled out across remaining repos, council formed, change process established
  • Week 9-12: First iteration of refinement — what’s missing or wrong in the instruction sets, based on the output developers are actually getting

At 90 days, you have a centralized toolchain your security team has reviewed, per-repo AI constraints that enforce your architectural and security standards automatically, and a small group keeping it current. Developers haven’t lost productivity — most have gained it, because the AI now has enough context about their actual systems to be useful by default.

The costs you were worried about at the start — ungoverned spend, data exposure, no inventory — are now manageable. You know what you’re paying, you know what data is in scope, and you have a process for keeping the AI’s behavior consistent with your standards.

That’s the whole framework. The tooling exists. The instruction file conventions exist. The main thing missing in most orgs is the decision to treat AI governance as an infrastructure problem rather than a policy problem. Once you make that shift, the path forward is pretty clear.

Related: if you’re setting up Copilot for your own use rather than a team, Getting Started with GitHub Copilot covers the personal configuration layer in detail.