Governance
Most companies that adopt AI coding agents do it without a written policy. Then something goes wrong, a secret leaks into a prompt, a junior ships code nobody reviewed, and the policy gets written under pressure, badly. Here is a short policy you can adapt today, and a way to make it stick.
"Use your judgment" is not a policy. It is what you say when you do not have one. Engineers will use AI coding agents whether or not you have a policy, often with personal accounts and no oversight. A short written policy does two things: it tells people what is expected before they guess, and it gives you something to point to when a decision needs to be defended, to a client, an auditor, or a board.
Keep it short enough that people actually read it. These six points cover the decisions that matter:
A policy that lives only in a document gets ignored within a month. The parts that matter should be enforced by tooling, not memory:
A policy that reads like a ban list will get worked around. Frame it as removing risk from something the team already wants to do, not blocking it. Involve two or three senior engineers in writing the first draft, pilot it on one team for two weeks, and fix what is impractical before you roll it out company-wide. Publish the reasoning, not just the rules: engineers follow a policy they understand.
Adapt this to your context, keep the six points, and put it where your engineering handbook lives:
Review the policy every quarter, or whenever a new class of tool shows up. Name an owner, usually a senior engineer or the CTO, who updates it and answers questions. A policy nobody owns goes stale the day it is published.
Yes. The data boundary and the review requirement apply to any tool that sees your code or suggests changes, autocomplete included. The accountability point matters less for a single suggested line, but the data rule does not change.
Treat it as an unapproved tool under the policy. The risk is not the model, it is that company code or data leaves through an account you do not control and cannot audit. Approve a company account for the same tool instead of trying to ban the behavior outright.
Run the same dependency and license scanning you already use for human-added packages, and make sure it also runs on AI-suggested code before merge. Agents do not check license compatibility unless you ask, and they will suggest whatever solves the problem fastest.
Yes, one line: junior engineers must be able to explain any AI-generated code they submit, in their own words, before it is reviewed. It costs nothing to enforce and it is the single best protection against the illusion of competence.
Governance
What an auditor or a technology due diligence team asks about AI-assisted code, what evidence a disciplined team already has, and a minimal checklist to close the gaps.
Foundations
Vibe coding and agentic engineering both use AI to write code, but only one produces software you can put in production. Here is the distinction, and how to move a team to the disciplined side.
Foundations
An AI coding agent is more than autocomplete and less than a senior engineer. This guide gives a clear definition, explains the loop that makes it an agent, and shows what it is not.
A policy is only as good as the rollout and the checks behind it. If you want help adapting this to your context, wiring it into CI, and getting engineering buy-in, that is exactly what I do in advisory engagements.