Rules for AI-Assisted Coding on a Team

Sooner or later a team member asks, "Can I use an AI assistant for this?" Or a pull request arrives with 600 lines the author cannot explain. A lead needs a calm, written answer before that happens. This lesson gives a lead's view: what to allow, what to review harder, the risks, how to help juniors, how to measure effects honestly, and a one-page policy you can adapt.

This lesson is about team habits and judgement, not about any one product. Tools, features and terms of service change quickly, so I name no products. Read the earlier lessons of this series for the thinking tools used here: review habits, Lesson 3, laws and biases, Lesson 7 (Goodhart's Law matters for measuring) and a security mindset, Lesson 14. For the technical side of building with models see Securing LLM applications, AI Engineering Lesson 0 and prompt injection and safe tools, Lesson 1.

Words used in this lesson

• AI coding assistant means a tool that suggests or writes code, tests or explanations from your prompt and your code.
• Agent (here) means an assistant that can also take actions: edit files, run commands, call tools. Power brings risk.
• Prompt is the text and code you send to the tool.
• Accountability means that a named person answers for the result.
• Provenance means where something came from. For code: who wrote it, from what source, under what licence.
• Licence is the legal terms for using someone's code.
• Least privilege means giving a tool only the access it needs for the task.

The principle: the author owns the code

Google's code-review standard has a simple idea at its centre: reviewers should approve a change once it definitely improves the overall health of the code. Whoever submits a change is saying "this makes the system better". That sentence does not change when a tool typed the lines. So the first rule of a policy is:

Everything else follows from this. If the author owns the code, then the author must read it, test it and be ready to change it.

What to allow

Decide in advance and write it down. A sensible, cautious start (adapt it):

The right columns differ by company. Some legal teams forbid certain tools entirely. Ask first.

Review generated code harder, not softer

Generated code has a specific danger: it is fluent. It looks clean and confident even when it is wrong. A few review habits help:

1. Keep changes small. Google's guide says small changes are reviewed faster and more carefully, and have fewer bugs; it suggests about 100 lines is usually fine and about 1,000 is usually too large. An assistant makes big changes easy, so a lead must hold the line: split it.
2. Read every line as if a stranger wrote it. The author's first job is to review the output before anyone else sees it.
3. Tests first, or at least tests that can fail. Ask: "Show me the test failing, then passing." A test written by the same tool from the same code may only repeat the code's mistake.
4. Check the details that look right: off-by-one errors, missing error handling, wrong time zones, invented function names or options, outdated library usage, silently swallowed exceptions.
5. Do not accept new dependencies without the package checks from Lesson 1. Assistants sometimes suggest packages that do not exist or are not what you expect. A fake package name that someone registered later is a supply-chain risk (OWASP lists Supply Chain among its LLM risks).
6. Watch for copied code and licences. You cannot always see where a suggestion came from. Ask your legal team what your policy is, and do not paste large unexplained blocks.
7. Review the tests too. Generated tests are often shallow: they assert what the code does, not what it should do.

Security risks

Two risks come up again and again in the OWASP list for LLM applications, and both apply to your developers' tools and to products you build:

• Improper output handling. Treating model output as trusted. Code from a model should be treated like code from the internet: read it, run it in a safe place, and never pipe it straight into a shell, a database or production.
• Excessive agency. Giving a model more power than the task needs. An agent that can read your whole disk, use your cloud credentials and push to the main branch is a large risk if it is tricked by text in a file or a web page (see prompt injection).

Practical rules for a team:

1. No secrets in prompts or in files an agent can read. Use secret managers and keep .env files out of agent reach.
2. Least privilege for agents. A separate workspace or container, a read-only token where possible, no production credentials, and a branch that cannot merge without human review.
3. Human approval for risky actions: deleting data, changing infrastructure, publishing packages, sending messages to customers.
4. Treat content the agent reads as untrusted. A README, an issue or a web page can contain instructions aimed at the tool.
5. Log what the agent did so a review can see commands and changes.

Growing juniors in the age of assistants

The risk for a junior is not that they will use a tool. It is that they will stop building understanding. A lead can protect learning without banning anything:

• Ask them to explain the change in their own words in the pull request. If they cannot, the review is a teaching moment, not a rejection.
• Use "what have you tried, and what do you think the options are?" (Lesson 9) before offering an answer, whether the answer comes from you or from a tool.
• Give some tasks to do without the assistant, on purpose, like practising scales on an instrument. Say why.
• Pair on one tricky piece and read generated code together.
• Praise good questions and good tests, not volume of code.

Measuring the effect honestly

Leaders will be asked: "Is it working?" Be careful.

• Goodhart's Law (Lesson 7): when a measure becomes a target, it stops being a good measure. If you reward "lines of code" or "number of pull requests", an assistant will help you win the number and lose the quality.
• Use the team-level delivery measures from Lesson 4 (how often you ship, lead time, failure rate, time to recover) and look at them before and after a change, over months, with other changes in mind. A rise in speed with a rise in failures is not a win.
• Ask people. A short, regular survey ("What does the assistant help with? Where does it waste time?") is cheap and often more useful than a dashboard.
• Watch review load and rework: if reviews get longer and more bugs come back, the assistant may be moving the cost to reviewers.
• I did not review published studies, and results differ by task, team and tool. Do not quote a percentage to your manager unless you read the source yourself.

A one-page team policy (template)

# Using AI assistants on <team name>Status: draft | accepted    Owner: <name>    Review date: <date, in 3 months>## Principles1. You own what you commit. You can explain it and you tested it.2. Generated code gets the same review as any code, and more care in   security-sensitive areas.3. Private data and secrets never go into prompts or agent-readable files.## Allowed- <explaining code, drafting tests, boilerplate, ...>## Needs a second reviewer- <auth, payments, crypto, input parsing, migrations, ...>## Not allowed- Pasting customer data, secrets, keys or internal documents into tools  that security has not approved.- Merging changes you cannot explain.## Agents- Sandbox or container, least privilege, no production credentials.- A human approves deletes, infrastructure changes, publishing, messages.## Tools- Approved tools and settings: <list, with the link to security's decision>.- To ask for a new tool: <how>.## Review- Keep changes small. Show the test failing, then passing.- Say in the pull request description if a tool wrote a large part.## Measuring- We look at team delivery measures over time. We do not rank people by  output counts.

Review it in three months. This area changes quickly and a policy that never changes will be wrong.

Interview questions

Key takeaways

• The author owns every line they commit, whoever or whatever typed it.
• Write a short policy: what is allowed, what needs a second reviewer, what is never allowed, how agents are limited.
• Generated code is fluent, not necessarily right. Keep changes small, read every line, and ask for tests that fail first.
• Keep secrets and private data out of prompts. Give agents least privilege, a sandbox and human approval for risky actions.
• Protect junior learning: explain in your own words, ask what they tried, and practise some tasks without the tool.
• Measure team results over time, not per-person output counts. Do not quote numbers you did not read in the source.
• Review the policy every few months, because tools and rules change.

What's next

Next: Scaling teams, ownership and on-call, Lesson 16. Practise: copy the policy template, fill in the "Allowed", "Needs a second reviewer" and "Not allowed" lists for your own team in 30 minutes, and ask two teammates what they would change.