What changes when policy is written down formally
Policy as code means expressing authorization rules in a structured, versioned format that a machine can evaluate directly — rather than as a natural-language document that engineers interpret and reimplement in scattered application code. The immediate benefit is consistency: the same rule is evaluated the same way everywhere it applies, instead of being reinterpreted slightly differently in each service that needs it.
The less obvious benefit is reviewability. A policy expressed as code can be diffed like any other change: a reviewer can see exactly what a proposed change permits that the previous version did not, rather than trying to infer the practical effect of a paragraph of prose. It can also be tested — a policy change can be run against a suite of known requests before it ships, to confirm it does not accidentally open access it was not meant to.
The discipline it requires
Treating policy as code only pays off if it is actually held to the standards of code: changes go through review, a history of who changed what and when is preserved, and the policy that ran in production for a given decision is identifiable after the fact — not just the current version, but the exact version in force at the time. A policy engine that silently applies 'whatever the latest rules happen to be' at evaluation time makes past decisions impossible to re-verify once the policy has moved on.