Buying licences is the easy part. It takes an afternoon and a purchase order.
What actually happens next is that five engineers start using the tools five different ways, at five different levels of caution, and within two months your codebase contains four patterns for the same thing and nobody is quite sure which pull requests were read carefully.
Introducing AI into a team is not a tooling decision. It is a standards decision, and the standards need to exist before the tooling is widespread — not after the first incident.
Name the actual risk
Before you write any policy, be precise about what you are protecting against. It is not that the output is bad — much of it is fine. The risks are specific:
Code nobody understands. It works, it passed review because it looked reasonable, and the first time it breaks at 11pm nobody can reason about it.
Convention drift. Generated code has no memory of how your codebase does things. Left unchecked, consistency is the first casualty.
Diluted review. Pull requests get larger and arrive faster. Review capacity does not increase to match, so it quietly gets shallower.
Accountability drift. “That is what it generated” starts appearing in review threads as though it settles anything.
Data leaving. Somebody pastes a production record, or a file containing credentials, into a tool with unclear retention.
Notice that four of those five are about people and process. Only the last is about the tool.
The agreement, on one page
What has worked for me is short enough that people actually read it. Five rules.
1. The author is accountable, always
Whoever opens the pull request owns every line in it. Not the tool, not the prompt. If a reviewer asks why something is written a certain way, “that is what it produced” is not an answer — it is an admission that the code should not have been submitted.
This single rule does most of the work, because it restores the thing that was quietly slipping.
2. Nothing merges that the author cannot explain
If you could not have written it, and cannot now walk someone through it, it does not go in.
This is not about pride. It is about the fact that code you do not understand is code you cannot debug, and you will be the person asked to debug it.
3. Generated code is reviewed to the same standard
No lighter touch, no special category. If anything the review needs to be more alert to one specific thing: does this match how we already do it here? Generated code is plausible by construction, which makes it easy to approve and easy to accumulate.
4. New patterns need a reason
If a pull request introduces an approach that does not exist elsewhere in the codebase, the description says why. Not a veto — a prompt. Most of the time the author will realise there was already a way and switch to it.
This is the rule that prevents the four-patterns-for-one-thing outcome, and it costs nothing.
5. Some things are written by hand
Agree the list explicitly rather than leaving it to judgement:
| Area | Why it is handwritten |
|---|---|
| Authentication and authorisation | Plausible-looking auth code is frequently subtly wrong |
| Anything touching money or eligibility | An error here is not a bug report, it is a client escalation |
| Data model and migrations | Expensive to reverse, and the blast radius is everyone |
| Security boundaries and input validation | Generated code assumes a friendly caller |
Fix review capacity before it becomes the bottleneck
This is the part most teams miss. If everyone produces code faster and review stays the same, review becomes the constraint — and under pressure, constraints get relaxed rather than resourced.
Three things that help:
Cap pull request size. A 900-line pull request does not get reviewed, it gets approved. If generation makes large changes easy, the size discipline has to become explicit rather than incidental.
Ask for the reasoning in the description. Not what changed — the diff says that. Why this approach, what was considered, what the reviewer should look at hardest. Writing that is itself a check on whether the author understood what they submitted.
Let the tooling do the first pass. Have the author run an adversarial review on their own branch before opening it — edge cases, failure modes, concurrency assumptions. It catches the obvious things so human review can spend its attention on design and domain correctness.
Ask authors to mark in the description which parts were generated and reviewed versus written by hand. Not to police anyone — it tells the reviewer where to look hardest, and it makes the accountability rule concrete rather than aspirational.
Settle the data question in writing
Engineers will paste things. Make the boundaries explicit so they do not have to guess:
- Which tools are approved, and what each vendor's retention and training policy is
- That production data, personal information and credentials never go in — including in a stack trace, which is where this usually slips
- What to do when a real record is genuinely needed: anonymise it, or use a local model
Half a page. The failure mode here is not malice, it is that nobody wrote it down and a well-meaning person pasted a customer record to debug faster.
Expect the skill question, and have an answer
Your more junior engineers are the ones this changes most, and not entirely for the better. If someone never struggles with a problem, they do not develop the instinct for where bugs hide.
What I have found workable: be explicit that certain things stay manual for people who are still building fundamentals. Read the stack trace yourself first. Write the tricky logic by hand. Use the tool to check your reasoning, not to replace it.
Frame it as training rather than restriction, because that is what it is. The senior engineers on your team got fast by being slow for several years.
Measure whether it is actually working
Velocity will go up. That is not the interesting number. Watch the ones that tell you whether quality held:
| Signal | What a bad trend looks like |
|---|---|
| Change failure rate | More releases needing a follow-up fix |
| Pull request size | Steadily growing — review is becoming a rubber stamp |
| Review turnaround | Approvals getting faster while diffs get bigger |
| Bugs in generated areas | Concentrating in recently added code |
| What people say | “I am not sure how that part works” appearing in standup |
That last row is the earliest signal and the one no dashboard shows you.
Roll it out in that order
Agree the rules first — one page, with the team, not handed down.
Start with a small group on non-critical work for a few weeks.
Review what actually happened. Where did it help? Where did review get harder?
Adjust the rules based on that, not on what you assumed.
Then widen it, with the standards already established rather than retrofitted.
The point
The teams that get this right are not the cautious ones or the enthusiastic ones. They are the ones that were already disciplined about review, conventions and ownership — because these tools amplify whatever engineering culture they land in.
If your review process was already thin, AI will not break it. It will just reveal how thin it was, considerably faster.
