The *-as-Code Pattern Is Eating Operations
Every major operational discipline has gone through the same evolution: manual clicks in a dashboard → scripts in a wiki → declarative code in a Git repository, enforced through CI/CD. It happened to infrastructure. Then policy. Then identity. Then documentation.
The pattern that wins every time: manual → scripts → declarative code in Git.
The pattern keeps winning because it always delivers the same four things: automation, repeatability, reliability, and audit trail. Once you define something as code and apply GitOps to it, you gain PR-based review, rollback on merge revert, blame for forensics, and branch protection as a governance gate. It’s not clever — it’s structural leverage.
And the family keeps growing. Here’s the landscape in 2026 — and why the newest member, Harness as Code, might be the most important addition yet.
The *-as-Code Family
Infrastructure as Code
The one that started it all. Terraform, Pulumi, OpenTofu, AWS CDK, Azure Bicep — declare your compute, networking, and platform services in version-controlled files. IaC eliminated server snowflakes. Every environment is reproducible from a single source of truth. Drift detection catches unauthorized changes. PRs become infrastructure review gates.
In 2026, this is table stakes.
Policy as Code
Tools like Open Policy Agent (OPA) and HashiCorp Sentinel let you express governance rules — security boundaries, compliance requirements, cost controls — as testable, enforceable code.
Instead of “don’t deploy public S3 buckets” being a wiki page someone ignores, it becomes a Rego policy that blocks the Terraform plan. Instead of “all containers must run as non-root” being a Slack reminder, it becomes a Kyverno policy that rejects the admission. The policy is version-controlled, reviewed via PR, and enforced automatically. Shift-left governance that actually works.
Identity as Code
SSO configurations, user group memberships, service account definitions, federation trust relationships — these traditionally live in admin consoles where changes are invisible and unauditable. Identity as Code means managing your Okta, Azure Entra ID, or Keycloak configurations through Terraform providers or declarative YAML. Onboarding a new team? That’s a PR that adds them to the right groups with the right app assignments. Offboarding? A PR that revokes.
Access as Code
IAM policies, RBAC role definitions, permission sets, and authorization rules — declared as code rather than clicked through consoles. AWS IAM policies in Terraform. Kubernetes RBAC manifests in Git. Authorization logic expressed in Cedar or OPA rather than scattered if statements across microservices.
When your access rules are code, you can answer “who has access to what and why?” by reading a repo instead of auditing twelve different admin panels.
Management as Code
Runbooks, escalation matrices, incident response playbooks — versioned in Git rather than tribal knowledge in someone’s head. On-call rotations as YAML. Incident response as Markdown with automated triggers. Consistency across shifts, updates through review, history preserved.
Docs as Code
Documentation built from Markdown/MDX in Git repos, deployed through CI/CD, reviewed via PRs. Tools like Docusaurus, MkDocs, and Fern make this seamless. When docs are code, they stay in sync because updating them is part of the same PR that changes the system.
Harness as Code — The Newest Member
Here’s where it gets interesting. Every *-as-code pattern above governs a technical surface — servers, policies, identities, documentation. But what governs the behavioral surface of autonomous AI agents?
Harness as Code is the practice of defining AI agent governance — decision boundaries, autonomy levels, communication rules, escalation paths, tool permissions, and safety constraints — as declarative files in a Git repository, enforced through the same PR-review-merge workflow as everything else.
It’s the natural next step. If your infrastructure changes require a reviewed PR, why would your AI agent’s behavioral boundaries be defined in an unversioned prompt that someone edits directly? That’s the equivalent of manually configuring a production server in 2010.
Harness as Code means agent instructions, constitutions, skill definitions, and governance rules all live in Git. Change an agent’s autonomy level? PR. Expand what tools an agent can access? PR. Every behavioral change goes through code review, gets attributed, and is reversible.
I cover the full 7-layer governance architecture in a separate piece — but the key insight is that Harness as Code doesn’t require inventing new tooling. It requires applying the pattern that already works everywhere else to the newest operational surface: agent behavior.
Why GitOps Is the Multiplier
The *-as-code patterns above are powerful on their own. Combine them with GitOps — Git as single source of truth, changes reconciled automatically — and you get compounding leverage:
- Automation: Merge triggers reconciliation. No manual “apply” steps.
- Repeatability: Clone the repo, get an identical system. Every time.
- Reliability: Branch protection + required reviews = no unreviewed changes reach production.
- Audit trail: Every change attributed, timestamped, diffable, revertable.
But there’s a second-order unlock that changes the entire equation.
The Real Unlock: Once It’s Code, Agents Can Maintain It
Here’s the thesis most *-as-code articles miss — the one that changes the math entirely.
As-code is the prerequisite for agent-maintained. Harness as Code closes the loop.
Automation, repeatability, and audit trails justify the migration to code on their own. But there’s a second-order effect that drastically skyrockets your velocity: once something is expressed as code in a Git repository, an AI agent can maintain it.
Think about what that means:
- Want agents managing your identity? Make identity as code first. Once your Okta configs are Terraform files, an agent can propose onboarding PRs, detect stale accounts, and enforce least-privilege — autonomously.
- Want agents managing your policy? Make policy as code first. Once your governance rules are OPA policies in a repo, an agent can detect compliance drift and propose remediation PRs automatically.
- Want agents managing your infrastructure? Make it as code first. Once your cloud resources are declarative configs, an agent can right-size instances, rotate certificates, and propose cost optimizations — all as reviewable PRs.
- Want agents managing your documentation? Make docs as code first. Once your docs are Markdown in Git, an agent can detect staleness, update API references, and flag broken links.
The pattern is universal: as-code is the prerequisite for agent-maintained. Without code, agents have nothing to operate on. With code, agents get a structured, diffable, reviewable surface they can read, reason about, and propose changes to.
This is where Harness as Code completes the loop. The agents themselves are governed as code — their instructions, boundaries, and permissions live in Git. So you get agents maintaining infrastructure, policy, identity, and docs… while the agents themselves are maintained through the same pattern. Code governing agents governing code.
That’s not a nice-to-have. That’s the difference between a team of five managing ten services and a team of five managing a hundred.
The Bottom Line
The *-as-code revolution isn’t just about automation and audit trails — it’s about creating the surface that agents can operate on. Every domain you migrate to code becomes a domain that agents can maintain. Every domain you leave in dashboards and admin consoles stays a domain that requires human clicks.
Infrastructure was first. Policy, identity, access, docs, and management followed. Harness as Code closes the loop by governing the agents themselves through the same pattern.
The progression: make it code → apply GitOps → let agents maintain it → govern the agents as code too.
That’s not a framework. That’s compound leverage.