Policy as Code for Developer Platforms - Does automated governance improve coding excellence or mainly create friction?

  This page is still in draft state. Please note that the content may be subject to change.

As developer platforms grow in complexity, governance through documentation and manual review no longer scales. Policy as Code promises automated, machine-checkable enforcement of rules — but does it actually improve coding excellence, or does it mainly create friction? This topic investigates the trade-offs.

• Background
• Objective(s)
• Possible Research Question(s)
• Sources (Example)

Background

As software delivery increasingly depends on standardized platforms, CI/CD pipelines, cloud infrastructure, and internal developer platforms, governance can no longer be handled only through documentation, conventions, or manual review. Instead, teams increasingly encode rules and constraints directly into machine-checkable policies. This approach is commonly described as Policy as Code.

Policy as Code promises a compelling trade-off: stronger consistency, compliance, and security without relying entirely on manual enforcement. At the same time, it may introduce its own costs in the form of added complexity, false positives, reduced flexibility, and friction for developers. In current platform engineering discourse, Policy as Code is increasingly treated as a foundational capability for scalable platform governance. CNCF describes it as an important building block for platform engineering, while tools such as Open Policy Agent provide a general-purpose framework for expressing and evaluating policies across services, APIs, CI/CD pipelines, Kubernetes, and infrastructure definitions. (CNCF: Introduction to Policy as Code)

This topic explores whether Policy as Code actually improves coding excellence in practice, or whether it mainly adds overhead and rigidity.

Objective(s)

You research how Policy as Code is used in modern developer platforms and whether it genuinely improves software quality — or mainly gets in the way. Based on your research, you design and run a small coding experiment that lets you observe the effects of Policy as Code first-hand.

A proof of concept could look like this, for example: You set up a small but realistic development workflow — say, a containerized microservice deployed via a CI/CD pipeline to a Kubernetes cluster or a cloud environment. You then define a set of machine-checkable policies using a tool like Open Policy Agent (OPA), Kyverno, or Checkov — for instance, policies that enforce security baselines (no containers running as root), naming conventions, resource limits, or dependency constraints. You run the workflow twice: once without any policy enforcement, and once with policies active. You then compare the outcomes along dimensions like …

• Quality and security: Did the policies catch real issues (misconfigurations, insecure defaults, missing labels) that would have gone unnoticed otherwise?
• False positives and friction: How often did policies block legitimate changes? How much time did developers spend understanding and resolving policy violations?
• Developer experience: Did team members perceive the policies as helpful guardrails or as bureaucratic obstacles? (A short survey or structured reflection could capture this.)
• Maintainability: How much effort went into writing, testing, and maintaining the policies themselves?

The goal is not to prove that Policy as Code is universally good or bad, but to identify under which conditions it helps — and when it becomes overhead that teams will eventually work around.

Possible Research Question(s)

• What kinds of development rules and quality constraints are suitable for implementation as code-based policies, and which are better left to human judgement?
• How does Policy as Code affect developer productivity, autonomy, and perceived friction?
• To what extent can Policy as Code improve consistency, compliance, and software quality in developer platforms?
• Under which conditions does Policy as Code become an effective support mechanism rather than bureaucratic overhead?

Sources (Example)

1. CNCF (2025): Introduction to Policy as Code. Overview of the Policy as Code approach and its role in platform engineering. https://www.cncf.io/blog/2025/07/29/introduction-to-policy-as-code/
2. Li et al. (2026): An Empirical Study of Policy-as-Code Adoption in Open-Source Software Projects. Large-scale study analyzing 399 GitHub repositories to understand real-world PaC tool adoption patterns, co-usage, and governance practices. https://arxiv.org/html/2601.05555