AI Coding Assistant Team Setup: Rules, Permissions and Review

Without shared rules, every developer's assistant guesses. It can copy a secret into code, run a command that destroys shared data, or pick a different library from everyone else. Nobody can say whether it helps, because nobody measured. A shared AI coding assistant team setup fixes each of these.

Picture a common setup. A product team of 12 developers keeps its backend in one repository and switches on an AI coding assistant for everyone, with one instruction: try it. The setup is made up, but the problems are real.

Four weeks later, a senior engineer lists what went wrong. A pull request contained a payment test key that the assistant had copied from a local settings file into a config file. Another developer approved a database reset script without reading it.

That script wiped the shared staging database, the test copy of the app the whole team uses. Staging was down for 3 hours (made up). Meanwhile new code used three different date libraries, because each assistant guessed differently.

Then the manager asks: is it helping? Everyone feels faster. Nobody has a single number. The rest of this guide builds that setup one layer at a time, using the same team throughout.

A good AI coding assistant team setup is five layers that every change passes through, agreed before anyone starts. Some layers only ask the AI model, the engine inside the assistant, to behave. Others enforce, which means they work even when the model ignores you.

The picture shows the path of one change. Start at the developer and follow the arrows. Notice that every box after the assistant is a check the team agreed in advance. CI (continuous integration) is the server that runs the tests on every pull request. A commit is a saved change in git, and a push sends commits to the shared repository. The main branch is the team's official copy of the code. Branch protection is a GitHub setting that blocks merges into it until required reviews and checks pass.

Think of the assistant as a new joiner at your office. On day one you hand them a sheet of house rules and an access card. The rules sheet is the rules file. The access card is the permissions and logins.

The card opens only the floors the job needs, and never the server room. The security desk that checks bags is the secret check. A senior colleague signing off the work is code review.

Where the picture breaks: a new joiner can tell a manager's instruction from a line scribbled in a random ticket. The assistant cannot reliably tell them apart. That is why the card, not the rules sheet, does the real protecting.

You need six words to follow this guide. Each one gets a plain meaning and an example from the team.

AI coding assistant. A program that uses an AI model to read your code, write new code and often run commands, such as tests, on your computer. Example: a developer asks it to skip lunch orders on public holidays, and it edits four files and runs the tests.

Rules file. A plain text file kept in the repository that the assistant reads at the start of a session. Some teams call it an instruction, context or memory file. Each tool looks for its own file name, so check your tool's documentation.

Permission setting. A rule that says which commands the assistant may run on its own, which need a person to say yes, and which are blocked. Some tools call these an allowlist and a denylist.

Secret. Any value that proves who you are to another system, such as a password, a database login or an API key. An API key is a long code one program sends to prove itself to another. Anyone holding the team's payment key can act as the team.

Tool connection. A link that lets the assistant use another system, such as the issue tracker. Many assistants connect through an open, published standard for these links. A small program called a tool server offers the tools, and the assistant connects to it.

Pull request. A request to merge your changes into the main code, where teammates read and comment before it is accepted. Some platforms call it a merge request. Example: a developer opens a pull request for the holiday change, and a teammate reviews it.

A shared rules file should hold what a new teammate needs on day one: build and test commands, chosen libraries, where things live and what never to touch. Keep it short, specific and in the repository, so every assistant starts from the same page.

Remember the three date libraries? That happened because each assistant had to guess. The model cannot know your team's choices unless you write them down. The team's first version was about 40 lines and covered this:

• What the project is, in two sentences: a Python backend for office lunch orders, with the mobile app in a separate repository.
• How to set up, run the tests and run the linter (a tool that checks code style), as exact commands.
• Conventions: use the dates module in utils for every date, and keep money as whole paise (hundredths of a rupee), never as a float.
• Where things live, and that database changes go only through migration files (small scripts that change the database structure one step at a time).
• Hard rules: never edit the payments folder, never change an existing migration, never put keys in code.
• How to finish a task: run the tests and the linter, then write a short summary of what changed and why.

Notice that each line is something a reviewer can check. A line like "write clean code" changes nothing. "Keep money as whole paise" prevents a real rounding bug, because a float cannot store most decimal amounts exactly.

Changes to the file go through a pull request, like code. When reviewers spot the same assistant mistake twice, the fix is often one new line here. A very long file hides the rules that matter, so prune it as you add.

An AI coding assistant should run safe, local, easy-to-check commands on its own. It should ask before anything that reaches beyond your laptop, and never touch secrets or production. Write the policy once in a shared settings file, so every developer gets the same defaults.

Recall the wiped staging database. Nothing told the assistant to stop, and a tired developer clicked yes without reading the command. A good policy stops that before a person has to catch it.

Whatever tool you use, write the policy in three groups. Then check your tool's documentation for how it expresses each group, and which rule wins when two match. The table shows the team's choices.

The diagram shows the order the team wants for every command request. Notice that the never list is checked first, so a command on it is blocked even if it also matches an allow rule.

Two habits make this stronger. First, run the assistant in a container (a sealed-off environment for one project) that mounts only the project folder. Commands then cannot read the rest of your home folder.

A container is a fence, not a vault. Docker's documentation says containers have networking on by default and can make outgoing connections. So limit outgoing traffic, through an outgoing proxy or firewall rule, to the hosts the work needs, such as your model provider and package mirror.

Second, give each developer a local database for experiments. After the outage, the team changed the reset script to refuse any database that is not local. That script can no longer touch staging, whatever anyone clicks.

Keep secrets safe in four ways: block secret files, scan every commit, give developers only short-lived test keys, and revoke any key that leaks. Revoke means cancel the key at the service that issued it, so it stops working.

Look back at the leaked payment key. The assistant was asked to make the payment test pass. It found the key in a local .env file (a file of settings and secrets for one machine) and copied it into a config file to be helpful.

The model meant no harm. It could see the key, so it used it. Here is the team's fix:

• Block the files: .env files, key files and cloud login folders sit on the never list. This is not airtight, because a script the assistant runs can still open them.
• Scan before commit: a small hook (a script git runs at a set moment) stops any commit that adds a line that looks like a key.
• Scan again on the server: a laptop hook can be skipped, so CI or the code host checks every push too.
• Use weak keys locally: developers get test-mode keys that expire, never the live payment key. Leaking one is an annoyance, not a disaster.
• Revoke first, then clean up: if a key reaches the shared repository, cancel it and issue a new one. Deleting the line is not enough, because old commits and other people's clones still hold it.

The OWASP Secrets Management Cheat Sheet suggests detecting secrets at the developer level, before commit, and revoking exposed keys immediately. GitHub's guide to removing sensitive data also says to revoke or rotate the secret first.

Connect it only to tools the team has approved, give each connection its own login with the least access that does the job, and prefer read-only access. If a connection is not needed for daily coding, do not add it.

Connections are useful. The assistant can read a ticket directly instead of a developer pasting it in. But each connection is one more floor on the access card, so add only floors the job needs.

Be careful with tool servers that run as programs on your laptop. Like any program you start, they run with your user account's rights, so they can read the files you can read.

So a tool server copied from a random web page deserves the same care as any program you install. Read its full setup command, check who publishes it, and add it to the approved list by pull request.

The staging copy uses a database login that can only run SELECT queries (queries that read, never change). Even if the model asks to delete rows, the database itself refuses. That rule does not depend on the model behaving, and a later section shows it running.

Review AI-written code to the same standard as any other code, and make the person who opens the pull request fully responsible for it. Every change needs passing tests, and changes to risky folders need an extra reviewer.

This matters more than it sounds. In a 2022 user study by Perry and others, people with an AI code assistant on security-related tasks wrote significantly less secure code than people without one. They were also more likely to believe their code was secure.

Code that looks finished can make a reviewer relax at exactly the wrong moment. So the team wrote these rules into its contributing guide:

• The author owns it. "The assistant wrote that part" is never an answer in review. If you cannot explain a line, you cannot merge it.
• Small pull requests. The team's limit is about 400 changed lines, so a reviewer can read them properly. The assistant makes big changes easy, which is a reason to split them.
• Read the tests first. Check that they cover the new behaviour, including a case that should fail, such as an order placed on a holiday.
• No quiet test edits. If a change edits existing tests, the description must say why. An assistant asked to make tests pass may change the test instead of the code.
• Extra eyes on risky folders. Changes to payments, login code or migrations need a second reviewer from a named owners list.

For a bug fix, the developer first asks for a test that fails because of the bug, and only then for the fix. The test then proves the fix, instead of the two being written to agree with each other.

Package installs need care too. In a 2024 study by Spracklen and others, code models suggested many packages that did not exist. On average, at least 5.2% of suggested packages from commercial models and 21.7% from open-source models were invented.

An attacker can publish a harmful package under such an invented name. That is why installs sit in the ask-first group, and the reviewer checks that each new package is the real, maintained one.

Write a pre-commit hook that reads only the lines you are about to commit, matches them against key patterns, and exits with a non-zero code on a match. Git's documentation says a non-zero exit from this hook aborts the commit.

Here is the team's check in Python. The pay_live_ prefix is a made-up format for live payment keys; use your provider's real prefix. It ran on Python 3.13 and git 2.43.

#!/usr/bin/env python3
import re, subprocess, sys

PATTERNS = [
    re.compile(r"pay_live_[0-9a-zA-Z]{24}"),            # made-up live key format
    re.compile(r"-----BEGIN [A-Z ]*PRIVATE KEY-----"),  # private key file
    re.compile(r"(api_key|secret|password)\s*=\s*['\"][^'\"]{12,}", re.I),
]

diff = subprocess.run(
    ["git", "diff", "--cached", "-U0", "--no-color", "--no-prefix"],
    capture_output=True, text=True, errors="replace",
).stdout

hits, path, line_no, in_hunk = [], "", 0, False
for line in diff.splitlines():
    if line.startswith("diff --git"):
        in_hunk = False
    elif not in_hunk and line.startswith("+++ "):
        path = line[4:]
    elif line.startswith("@@"):
        in_hunk = True
        line_no = int(re.search(r"\+(\d+)", line).group(1))
    elif in_hunk and line.startswith("+"):
        if any(p.search(line) for p in PATTERNS):
            hits.append(f"{path}:{line_no}")
        line_no += 1

if hits:
    print("Commit blocked. Possible secrets at:", ", ".join(hits))
    sys.exit(1)

The git diff command with --cached shows only staged changes, the ones about to be committed. The -U0 option drops the surrounding unchanged lines, and --no-prefix keeps file names plain.

Each block of changes starts with a header such as @@ -1,0 +2,2 @@, which means two new lines starting at line 2. The script counts from there, so it can report a file and line number without printing the key.

It treats a +++ line as a file name only before the first @@ header of each file. A new line of code that starts with ++, such as a C increment, is still checked as code.

To share the hook, commit it in a folder and point git at that folder. Hooks in the hidden .git folder do not travel with a clone. Neither does the core.hooksPath setting, which lives in .git/config. So every developer runs the last command once after cloning.

mkdir -p .githooks
cp check_secrets.py .githooks/pre-commit
chmod +x .githooks/pre-commit
git add .githooks
git commit -m "Add secret check hook"
git config core.hooksPath .githooks   # every developer, once per clone

Check it worked: stage a file whose third line holds a fake live key, then commit. You should see this, with exit code 1:

$ git commit -m "add payment config"
Commit blocked. Possible secrets at: config/payments.py:3
$ echo $?
1

Know its limits before you trust it. Git's documentation says git commit --no-verify skips this hook, and our test confirmed the commit went through. The third pattern also missed password = "hunter2", because it needs at least 12 characters. It also missed keys written as key: value, as in YAML or JSON files.

So the hook is the first net, not the only one. GitHub's push protection can block a push that contains a recognised secret before it reaches the repository. As of 19 October 2026, it needs GitHub Secret Protection for repository-level use and is off by default.

Also as of that date, GitHub's documentation says anyone with write access can bypass push protection by giving a reason, by default. Each bypass creates an alert, but some bypass reasons close the alert at once. So someone must review bypasses, not just open alerts.

They leak because a rule sees only the command's text, not what the command will do. They misfire because a pattern broad enough to catch every secret also catches harmless commands. This small model of a deny-first policy shows both.

from fnmatch import fnmatch

NEVER = ["*.env*", "*id_rsa*", "*prod*"]
ALLOW = ["pytest*", "ruff check*", "git status*", "git diff*"]

def decide(command):
    if any(fnmatch(command, p) for p in NEVER):
        return "never"
    if any(fnmatch(command, p) for p in ALLOW):
        return "allow"
    return "ask"

for c in ["pytest -q", "cat .env", "pytest --env-file .env",
          "git push", "python3 show_config.py",
          "pytest tests/test_products.py"]:
    print(f"{c:30} -> {decide(c)}")

Before you read the output, predict which of the six commands this policy gets wrong. Running it with Python 3.13 prints this:

pytest -q                      -> allow
cat .env                       -> never
pytest --env-file .env         -> never
git push                       -> ask
python3 show_config.py         -> ask
pytest tests/test_products.py  -> never

The never list wins, so pytest --env-file .env is blocked even though it starts with pytest. That is the order you want. But pytest tests/test_products.py is blocked too, only because the file name contains prod.

The worse case is python3 show_config.py. If that script prints the .env file, the rule cannot know, and it only asks. A developer who clicks yes without opening the script has leaked the secret. The allow list leaks wider still. Allowing pytest runs whatever code the assistant just wrote into a test file, with no question asked. That is why live keys stay off the laptop.

This toy is not how any particular tool matches rules, so check your tool's documentation. The lesson carries over, though: text rules are a filter, and the container and the missing live keys are the real limits.

Give the assistant's connection its own database login that has only SELECT rights on the tables it needs. The database then refuses any change to those tables, whatever the model asks for. OWASP's excessive agency page uses this exact example of a read-only tool given too many rights.

We ran this on PostgreSQL 16.15 against a two-row orders table:

-- As the database owner, on the staging copy
CREATE ROLE assistant_ro LOGIN;
GRANT SELECT ON orders TO assistant_ro;

-- Then, logged in as assistant_ro
SELECT count(*) FROM orders;       -- returns 2
DELETE FROM orders WHERE id = 1;   -- ERROR:  permission denied for table orders

In the same test, the read-only login also could not create a table in the public schema. A schema is a named folder of tables, and public is the default one. PostgreSQL 15 and later lock it down by default in new databases. Databases upgraded or restored from older versions keep the old rule that lets every login create tables in public. There, run REVOKE CREATE ON SCHEMA public FROM PUBLIC as the owner.

Any login can still make temporary tables, which vanish when it disconnects. In a real setup, give the login its own password, store it outside the repository, and point it at the staging copy with fake data only.

The rules file only asks the assistant to stay out of the payments folder. On GitHub, a CODEOWNERS file plus a branch protection rule turns that request into a merge requirement for people and assistants alike.

# .github/CODEOWNERS
# The last matching line wins, so the catch-all line goes first.
*              @example-org/backend
/payments/     @example-org/payments-owners
/migrations/   @example-org/db-owners

GitHub's documentation, checked on 19 October 2026, says the file can live in the .github folder, the root or the docs folder. The last matching pattern takes precedence, so a catch-all line placed last would override the payments owners.

Code owners must have write access to the repository. The file must stay under 3 MB, or GitHub does not load it.

Then protect the main branch. Turn on required pull request reviews, Require review from Code Owners, required status checks for CI, and dismissal of stale approvals when new commits change the diff.

One trap: by default, branch protection does not apply to repository admins. Turn on "Do not allow bypassing the above settings" if the rules must apply to everyone.

Measure outcomes, such as time to merge and bugs found later, and compare them with a baseline from work done without the assistant. Do not rely on how fast people feel, because feelings and stopwatches can disagree.

A 2025 study by Becker and others shows why. Sixteen experienced open-source developers did 246 real tasks in large projects they knew well. Each task was randomly allowed or not allowed to use early-2025 AI tools.

Before starting, the developers expected AI to cut their task time by 24%. Afterwards, they believed it had cut it by 20%. Measured, tasks with AI took 19% longer.

The authors say experimental artefacts cannot be fully ruled out, and it is one setting with one generation of tools. It does not prove AI always slows people down. It does show that impressions are not data.

You can pull real numbers from GitHub with its gh command-line tool. This fetches your last 200 merged pull requests with their open and merge times:

gh pr list --state merged --limit 200 \
  --json number,createdAt,mergedAt > prs.json
python3 merge_time.py

Then merge_time.py turns each pull request into hours from opened to merged. It needs Python 3.11 or newer, which reads the trailing Z in GitHub's timestamps.

import json
from datetime import datetime
from statistics import mean, median

prs = json.load(open("prs.json"))
hours = [
    (datetime.fromisoformat(p["mergedAt"])
     - datetime.fromisoformat(p["createdAt"])).total_seconds() / 3600
    for p in prs
]
print(f"{len(hours)} PRs, mean {mean(hours):.1f} h, median {median(hours):.1f} h")

On six made-up pull requests, one of which waited two weeks for a reviewer, it prints this:

6 PRs, mean 61.3 h, median 7.0 h

The mean (the average) says 61.3 hours, but five of the six merged within 10 hours. The median (the middle value) says 7.0 hours, which matches what most people saw. So report the median, and count reverts and later bugs beside it.

The team ran a six-week pilot: four volunteers used the assistant under the new rules, and the other eight did not. The pilot's median time to merge was 19.5 hours against 22 hours, with 3 reverts against 1 (all made up).

The manager's honest summary was: slightly faster, slightly more rework, from a small group of keen volunteers. Volunteers often like the tool most, so the gap may shrink for everyone else. She kept the rules, tightened the test-first habit and booked another check in three months.

Onboard developers with the shared settings already in the repository, a short session on the rules, and a guided first task. People copy what they see in their first week, so make that week a good example.

1. 1

   Ship the defaults with the repository

   The rules file, permission settings, approved connection list and hook folder all live in the repo. After cloning, one git config command turns on the hook.

2. 2

   Run a 90-minute session

   Walk through the three permission groups, the secret rules and the review rules, using the team's real mistakes as examples.

3. 3

   Pair on a first task

   Each developer does one small ticket with a pilot member watching, from the first request to a merged pull request.

4. 4

   Tighten, never quietly loosen

   Developers may make their own settings stricter. Loosening a shared rule needs a pull request and a reason.

5. 5

   Review the setup every month

   Read the month's review comments and incidents, then update the rules file and permission lists.

Watch junior developers closely. The assistant can help them learn, but it can also let them merge code they do not understand. So the team asks juniors to explain each change in their own words in the pull request.

Stricter rules for sensitive repositories

The team's payments service handles refunds and stores masked card details from its payment gateway. A mistake there costs money and trust, so it gets stricter rules:

• The assistant may suggest code but may run no command except the tests.
• No tool connections at all in this repository.
• Every pull request needs two approvals, and branch protection requires one from a payments owner in CODEOWNERS. Only the payments owners have write access here, so both approvals come from them.
• Real customer data never goes into a prompt. Test data is generated, never copied from production.
• Before use, the team checks where its model provider processes code, and whether that matches its contracts and the data laws it follows.

Some teams switch the assistant off entirely for certain repositories, and that is a valid choice. The rule is simple: the more a mistake costs, the less the assistant may do alone.

Explain it as layers of control around a fast but unreliable writer, and say where each layer is enforced. Interviewers want to see that you think about risk and evidence, not that you know a favourite tool.

1. 1

   Ask about the team and the risk

   How many developers, which repositories, and what happens if bad code ships. A payments team and a marketing site need different rules.

2. 2

   Describe the shared context

   One rules file in the repository with build commands, conventions and hard rules, reviewed like code, and labelled as a request.

3. 3

   Draw the permission groups

   Allow, ask first and never, with never checked first. Add a container with only the project folder, and no live keys on laptops.

4. 4

   Show the enforced checks

   A secret scan before commit and again on push, CI tests, read-only logins, and branch protection that requires code owner review.

5. 5

   End with measurement

   A pilot group, a baseline, and median time to merge, reverts and later bugs, all chosen before the pilot starts.