{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"a-tool-policy-people-follow","title":"A policy people will actually follow","url":"https://addaly.com/learn/how-software-changed/a-tool-policy-people-follow","position":59,"of":87,"minutes":9,"answer":"A workable tool policy is one page with an approved list, a specific data rule that names a permitted alternative, the author owning every line, review scrutiny tiered by risk.","keyIdea":"A workable tool policy is one page with an approved list, a specific data rule that names a permitted alternative, the author owning every line, review scrutiny tiered by risk, and an explicit ban on measuring individuals by activity counts."},"body":{"format":"markdown","text":"## Two failure modes, both common\n\n**Ban it.** People use it anyway, on personal accounts, without telling anybody, and now nothing is reviewed and nobody knows what left the building. A ban converts a manageable risk into an invisible one.\n\n**Say nothing.** Everybody does something different, sensitive code goes to whatever service somebody signed up for, and the first time anyone thinks about it is during a customer's security questionnaire.\n\nThe useful thing is one page, written once, that a person under deadline pressure can follow. Length is the enemy: a three-page policy is a policy nobody has read.\n\n## The page\n\n```markdown\n# Using AI coding tools here\n\n## Approved tools\n<name>, on the company account. <name>, self-hosted.\nAnything else: ask in #eng-tools first. One message, not a review board.\n\n## Never pasted into an external service\n- Customer data of any kind, including \"anonymised\" samples\n- Credentials, tokens, private keys, connection strings\n- Code from `payments/` or `identity/`\n- Anything a client contract marks confidential (list: docs/contracts.md)\nFor those, use the local model. Setup: docs/local-model.md\n\n## Ownership\nYou own every line you submit, whatever produced it.\nIf you cannot explain a line in review, do not submit it.\n\"The model wrote that part\" is not a defence.\n\n## Review standard, by risk\n- Money, auth, permissions, deletion, personal data, external writes:\n  every line understood by the reviewer. No deadline override.\n- Everything else: normal review.\n\n## Always\n- Read the whole diff before opening a pull request.\n- Verify any new dependency exists and check its publisher. (2 minutes)\n- Say in the description if a change removes a check, widens an exception,\n  skips a test or loosens a type — and why.\n\n## Never\n- Let an agent run with production credentials in the environment.\n- Auto-merge on a bot approval.\n- Use these numbers to assess a person: lines, commits, PRs,\n  acceptance rate, percentage generated.\n```\n\n## Why each section is there\n\n**Approved tools** exists so people do not have to guess, and so the answer is one message rather than a procurement process. A slow approval path guarantees shadow usage, and shadow usage is the outcome you were trying to avoid.\n\n**The data rules** are the part with legal consequences and they have to be specific. \"Do not share confidential information\" is not actionable; a directory list is. Note that the rule points at a permitted alternative, because a prohibition with no path is a prohibition people route around at 6pm on a Thursday.\n\n**Ownership** is the cultural core and it is one sentence. Everything else in this course depends on it holding.\n\n**Risk-tiered review** is what makes the policy survivable. A blanket \"review every line\" is abandoned within a month because it is not affordable. A rule that applies full scrutiny to the ten per cent where it matters is followed for years, and that is the difference between a policy and a poster.\n\n**The never-measure list** protects the team from a well-meaning manager, and it belongs in writing rather than in somebody's head, because the pressure to produce an adoption metric arrives from outside engineering and arrives suddenly.\n\n## Disclosure, which is unsettled\n\nShould a pull request state that a change was generated? Teams disagree, and both positions are defensible.\n\n**For:** it lets a reviewer calibrate. A change the author typed line by line and a change they skimmed warrant different scrutiny, and there is nothing in the diff that distinguishes them.\n\n**Against:** it becomes a status marker, it is unenforceable, it grows meaningless as assistance blends into ordinary editing, and it quietly undercuts the ownership rule by implying the author is less responsible for those lines.\n\nA reasonable middle, which several teams have landed on: do not label provenance, and instead ask the author to state their confidence. \"I have run this against a copy of production and I understand every line\" versus \"first pass, please read the retry logic carefully\". That is more useful to a reviewer than provenance, it is honest, and it is fully compatible with owning the diff.\n\nWhatever you choose, decide it explicitly and write it down. The worst outcome is an unstated norm that some people follow and others do not, because then a disclosure reads as a confession and its absence reads as a claim.\n\n## Review it on a date\n\nPut a date on the page (six months out) and a name. The tools, their capabilities, their data-handling terms and their prices all move faster than any other technology your team depends on, and a policy written against last year's landscape will be wrong in a way nobody notices until it matters.\n\nThe review is twenty minutes. Read the page, ask whether each rule is still the right one, ask whether anybody has been breaking one because it did not fit, and change it. A rule that people break silently is a rule that has already failed; the only question is whether you find out by revising the page or by reading an incident report."},"check":{"question":"A company bans external AI coding tools entirely because of confidentiality concerns. Two years later a security questionnaire reveals widespread use on personal accounts. What did the ban achieve?","options":[{"text":"It reduced usage substantially, so the residual shadow usage is smaller than an open policy would have produced.","correct":false,"tempting":"Assumes deterrence worked without evidence; the finding is widespread use, which is what an ineffective control looks like."},{"text":"It established liability, so responsibility for any leak now sits with individuals rather than the company.","correct":false,"tempting":"Treats a policy as a liability shield, which regulators and clients generally do not accept when the practice was foreseeable."},{"text":"It converted a manageable risk into an invisible one, with no permitted path.","correct":true},{"text":"Nothing, since the confidentiality concern was never real and the policy addressed an imagined problem.","correct":false,"tempting":"Dismisses a genuine concern; the confidentiality risk is real, which is precisely why an unusable rule is expensive."}]},"prev":{"slug":"incidents-and-on-call","title":"Operating a system nobody wrote by hand","url":"https://addaly.com/learn/how-software-changed/incidents-and-on-call"},"next":{"slug":"the-missing-rung","title":"Juniors, and the rung that went missing","url":"https://addaly.com/learn/how-software-changed/the-missing-rung"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'A policy people will actually follow', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/a-tool-policy-people-follow (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"A policy people will actually follow","courseTitle":"How Software Development Changed","module":{"index":6,"slug":"teams-and-delivery","title":"Teams, process and delivery"},"answer":null,"keyIdea":"A workable tool policy is one page with an approved list, a specific data rule that names a permitted alternative, the author owning every line, review scrutiny tiered by risk, and an explicit ban on measuring individuals by activity counts.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"two-failure-modes-both-common","runs":[{"text":"Two failure modes, both common"}]},{"t":"p","runs":[{"text":"Ban it.","b":true},{"text":" People use it anyway, on personal accounts, without telling anybody, and now nothing is reviewed and nobody knows what left the building. A ban converts a manageable risk into an invisible one."}]},{"t":"p","runs":[{"text":"Say nothing.","b":true},{"text":" Everybody does something different, sensitive code goes to whatever service somebody signed up for, and the first time anyone thinks about it is during a customer’s security questionnaire."}]},{"t":"p","runs":[{"text":"The useful thing is one page, written once, that a person under deadline pressure can follow. Length is the enemy: a three-page policy is a policy nobody has read."}]},{"t":"h2","id":"the-page","runs":[{"text":"The page"}]},{"t":"code","lang":"markdown","label":"Markdown","text":"# Using AI coding tools here\n\n## Approved tools\n<name>, on the company account. <name>, self-hosted.\nAnything else: ask in #eng-tools first. One message, not a review board.\n\n## Never pasted into an external service\n- Customer data of any kind, including \"anonymised\" samples\n- Credentials, tokens, private keys, connection strings\n- Code from `payments/` or `identity/`\n- Anything a client contract marks confidential (list: docs/contracts.md)\nFor those, use the local model. Setup: docs/local-model.md\n\n## Ownership\nYou own every line you submit, whatever produced it.\nIf you cannot explain a line in review, do not submit it.\n\"The model wrote that part\" is not a defence.\n\n## Review standard, by risk\n- Money, auth, permissions, deletion, personal data, external writes:\n  every line understood by the reviewer. No deadline override.\n- Everything else: normal review.\n\n## Always\n- Read the whole diff before opening a pull request.\n- Verify any new dependency exists and check its publisher. (2 minutes)\n- Say in the description if a change removes a check, widens an exception,\n  skips a test or loosens a type — and why.\n\n## Never\n- Let an agent run with production credentials in the environment.\n- Auto-merge on a bot approval.\n- Use these numbers to assess a person: lines, commits, PRs,\n  acceptance rate, percentage generated."},{"t":"h2","id":"why-each-section-is-there","runs":[{"text":"Why each section is there"}]},{"t":"p","runs":[{"text":"Approved tools","b":true},{"text":" exists so people do not have to guess, and so the answer is one message rather than a procurement process. A slow approval path guarantees shadow usage, and shadow usage is the outcome you were trying to avoid."}]},{"t":"p","runs":[{"text":"The data rules","b":true},{"text":" are the part with legal consequences and they have to be specific. “Do not share confidential information” is not actionable; a directory list is. Note that the rule points at a permitted alternative, because a prohibition with no path is a prohibition people route around at 6pm on a Thursday."}]},{"t":"p","runs":[{"text":"Ownership","b":true},{"text":" is the cultural core and it is one sentence. Everything else in this course depends on it holding."}]},{"t":"p","runs":[{"text":"Risk-tiered review","b":true},{"text":" is what makes the policy survivable. A blanket “review every line” is abandoned within a month because it is not affordable. A rule that applies full scrutiny to the ten per cent where it matters is followed for years, and that is the difference between a policy and a poster."}]},{"t":"p","runs":[{"text":"The never-measure list","b":true},{"text":" protects the team from a well-meaning manager, and it belongs in writing rather than in somebody’s head, because the pressure to produce an adoption metric arrives from outside engineering and arrives suddenly."}]},{"t":"h2","id":"disclosure-which-is-unsettled","runs":[{"text":"Disclosure, which is unsettled"}]},{"t":"p","runs":[{"text":"Should a pull request state that a change was generated? Teams disagree, and both positions are defensible."}]},{"t":"p","runs":[{"text":"For:","b":true},{"text":" it lets a reviewer calibrate. A change the author typed line by line and a change they skimmed warrant different scrutiny, and there is nothing in the diff that distinguishes them."}]},{"t":"p","runs":[{"text":"Against:","b":true},{"text":" it becomes a status marker, it is unenforceable, it grows meaningless as assistance blends into ordinary editing, and it quietly undercuts the ownership rule by implying the author is less responsible for those lines."}]},{"t":"p","runs":[{"text":"A reasonable middle, which several teams have landed on: do not label provenance, and instead ask the author to state their confidence. “I have run this against a copy of production and I understand every line” versus “first pass, please read the retry logic carefully”. That is more useful to a reviewer than provenance, it is honest, and it is fully compatible with owning the diff."}]},{"t":"p","runs":[{"text":"Whatever you choose, decide it explicitly and write it down. The worst outcome is an unstated norm that some people follow and others do not, because then a disclosure reads as a confession and its absence reads as a claim."}]},{"t":"h2","id":"review-it-on-a-date","runs":[{"text":"Review it on a date"}]},{"t":"p","runs":[{"text":"Put a date on the page (six months out) and a name. The tools, their capabilities, their data-handling terms and their prices all move faster than any other technology your team depends on, and a policy written against last year’s landscape will be wrong in a way nobody notices until it matters."}]},{"t":"p","runs":[{"text":"The review is twenty minutes. Read the page, ask whether each rule is still the right one, ask whether anybody has been breaking one because it did not fit, and change it. A rule that people break silently is a rule that has already failed; the only question is whether you find out by revising the page or by reading an incident report."}]}],"check":{"question":[{"text":"A company bans external AI coding tools entirely because of confidentiality concerns. Two years later a security questionnaire reveals widespread use on personal accounts. What did the ban achieve?"}],"options":[{"text":[{"text":"It reduced usage substantially, so the residual shadow usage is smaller than an open policy would have produced."}],"correct":false,"tempting":[{"text":"Assumes deterrence worked without evidence; the finding is widespread use, which is what an ineffective control looks like."}]},{"text":[{"text":"It established liability, so responsibility for any leak now sits with individuals rather than the company."}],"correct":false,"tempting":[{"text":"Treats a policy as a liability shield, which regulators and clients generally do not accept when the practice was foreseeable."}]},{"text":[{"text":"It converted a manageable risk into an invisible one, with no permitted path."}],"correct":true,"tempting":null},{"text":[{"text":"Nothing, since the confidentiality concern was never real and the policy addressed an imagined problem."}],"correct":false,"tempting":[{"text":"Dismisses a genuine concern; the confidentiality risk is real, which is precisely why an unusable rule is expensive."}]}],"order":[1,0,2,3],"why":null},"prev":{"slug":"incidents-and-on-call","title":"Operating a system nobody wrote by hand","minutes":9},"next":{"slug":"the-missing-rung","title":"Juniors, and the rung that went missing","minutes":9}}}