Team adoption and governance

0:00 Team adoption and governance

Buying licenses for coding agents takes an afternoon. Getting forty engineers to use them well, safely and consistently takes real leadership. In this lecture you will learn how to write an AI development policy people actually follow, which legal and client questions to settle, how to roll out in phases, and how roles and skills shift when agents write much of the code.

0:27 Analogy: the company car policy

Here is an analogy for governance. Think of a company car policy. The company does not ban cars, because people need to travel. It does not hand everyone a sports car and say have fun either. It says which cars are approved, who may drive them, where, that drivers are responsible for fines, and that cars get serviced regularly. Nobody finds that oppressive; it makes driving safe and predictable. An AI development policy is the company car policy for coding agents.

1:02 Policy essentials

Start with a short, concrete policy. One or two pages. Which tools and plans are approved. Where agents may run, for example local agents on internal repositories, cloud agents only on repositories tagged as agent friendly, and never on client code under NDA without written approval. What data must never go into prompts. Which controls every repository needs. And how reviews work for sensitive paths.

1:30 You own what you merge

The most important sentence in that policy is about accountability. The human who opens or approves a pull request owns it, regardless of who or what wrote the code. That single line removes the excuse that the AI wrote it, keeps quality where it belongs, and makes every other rule easier to enforce. Pair it with a simple disclosure norm: note substantial AI assistance in the pull request description.

2:00 Legal and client checks

Next, legal and client questions. Check your vendor's terms on output ownership and whether your plan includes intellectual property indemnity. Agencies should check client contracts for restrictions on sending code to third-party processors. If code or data includes personal information, privacy laws like UK GDPR, or the data protection laws in the UAE and Saudi Arabia, may apply to what you share. Regulated sectors may need vendor risk assessments. None of this is legal advice, so involve qualified counsel.

2:34 Phased rollout

Roll out in phases. Pilot for four to six weeks with volunteers on two or three repositories, keeping the trial log and holding a weekly retro. Then build foundations: instruction files, permission baselines, CI review and the security baseline in every participating repository. Then expand with training on your own codebase and pairing. Finally, operate: a metrics dashboard, a quarterly policy review, and regular re-evaluation, because this market changes monthly.

3:04 Skills shift

Agents shift where engineering effort goes: less typing, more specifying, reviewing and verifying. So invest in those skills. And protect junior development. Juniors still need fundamentals, so adopt an explain before accept rule: anyone submitting agent-written code must be able to explain it line by line. Some teams also schedule regular exercises without AI, so learning continues.

3:29 Case: Karachi reset

A story from a forty-person product company in Karachi. It began as a free-for-all: five tools, no shared setup, and a near miss when someone pasted a production connection string into a chat. The reset: one approved agent plus one AI reviewer, a short policy with the accountability line, instruction files in every repository, and a monthly share session covering one win, one failure and one instruction-file improvement. Leads reported fewer mystery pull requests, and security could finally answer client questionnaires about AI.

4:05 Avoid extremes

Avoid the two extremes. Banning everything drives people to personal tools with no controls at all, which is called shadow AI. Allowing everything produces inconsistent configuration, leaks and unowned code. And a policy without tooling is just a wish: back every rule with defaults in the repository. Measure success with compliance across repositories, reported near misses, and a simple survey asking developers whether the rules are clear.

4:34 Example: new tool, NDA client

A simple example of applying the policy. A developer wants to use a new agent they saw online for a client project under NDA. The policy answers three questions in a minute. Is the tool approved? No, so they submit the short request form. Is this repository eligible for cloud agents? It is tagged no-cloud because of the client contract. Can they use an approved local tool instead? Yes. Nobody had to call a meeting, and the client's code stayed where the contract says it must.

5:11 Scenario: phased rollout, 60 people (illustrative)

Now a realistic scenario with illustrative numbers. A sixty-person software house in Lahore rolls out agents in phases. The pilot runs six weeks with eight volunteers across three repositories. They find that instruction files and permission baselines matter more than which tool they chose, and that juniors accept agent code too quickly. So the expansion includes a two-hour workshop on the team's own codebase, the explain-before-accept rule for juniors, and a monthly share session. Six months later, every active repository has the baseline controls, and the security team reviews the policy each quarter. Common mistake: skipping the pilot and rolling out to everyone on day one.

5:57 Deeper: remove the reason

One level deeper on the Karachi near miss. The connection string was pasted into a personal chat tool to ask for help with a slow query. The reset added two things beyond the policy: a password rotation that same day, and a self-hosted database explain-plan helper so developers never need to paste production details anywhere. Remove the reason for the risky behavior, not just the permission.

6:26 Watch me do it: governance checklist

Watch me do it. I'm filling in the governance checklist for a thirty-person agency with client work in the UK and the Gulf. Approved tools: I list one coding agent and one AI reviewer, with the plan names, and I paste the vendor's data retention and training terms for those plans into the policy appendix. Repository eligibility: I tag internal repositories as agent OK, and every client repository as no-cloud until a client has approved in writing. Two clients already have, so their repositories get the tag. Policy: I publish the one-page policy, and I read the accountability line out at the team meeting: you own what you merge. Controls: I run a script across our repositories to check for four things, an AGENTS dot M D file, a permission baseline, secret scanning and branch protection. Eleven of nineteen active repositories pass. I create tickets for the other eight, each with an owner. AI review: enabled on the eleven that pass, with the tuned guidelines. Training: I book a two-hour workshop that uses our own codebase, not a demo. Metrics: I add AI mode labels to our pull request template and set a quarterly review date. The two gaps I commit to closing this month are the eight repositories missing controls and written client approvals for the remaining accounts.

8:01 Recap

Recap. A short policy with a clear accountability line. Legal and client checks settled early. A phased rollout backed by repository defaults. And deliberate investment in specifying, reviewing and testing skills, while protecting how juniors learn. Your next step: work through the governance checklist in the lesson and pick the two gaps you will close this month.