Everything as Code: Unified Operational Management

• Everything as Code is a paradigm that encodes all operational aspects—from infrastructure to CI/CD pipelines—as executable, version-controlled code artifacts.
• It extends traditional IaC by incorporating configurations, security policies, documentation, and observability into a unified, automated workflow.
• EaC promotes reproducibility, traceability, and cost savings by enabling deterministic planning, validation, and execution across the software lifecycle.

Everything as Code (EaC) is an emerging paradigm that generalizes Infrastructure as Code (IaC) across the software delivery lifecycle, treating infrastructure, configuration, pipelines, security policies, compliance rules, documentation, observability artifacts, and, in some formulations, agent context and laboratory experiments, as executable, version-controlled, machine-readable code artifacts (Wei et al., 7 Jul 2025, Piskala, 16 Jan 2026, Yang et al., 6 May 2026). Its unifying premise is that heterogeneous operational concerns should be authored, reviewed, tested, and automated through the same code-centric workflows that govern application software, thereby collapsing disparate management surfaces into a single artifact model (Howard, 2022).

1. Definition and conceptual boundaries

EaC builds on the proven effectiveness of IaC but expands its scope beyond provisioning compute, network, and storage. In Wei et al.’s formulation, EaC advocates that “all operational aspects—including infrastructure, configurations, security policies, and CI/CD pipelines” be represented and managed uniformly as code (Wei et al., 7 Jul 2025). This makes IaC a foundational subset rather than a synonym: IaC remains centered on provisioning and state-management of servers, networks, and storage, whereas EaC extends codification to configuration, governance, observability, analytics, documentation, and related lifecycle artifacts.

This boundary-setting is important because adjacent paradigms are not identical. Configuration as Code complements IaC by codifying OS, middleware, and application-level settings. DevOps and DevSecOps provide cultural and toolchain frameworks, whereas EaC prescribes a uniform artifact model in which every resource, rule, and workflow is authored, versioned, and reviewed as machine-readable code (Wei et al., 7 Jul 2025). A common misconception is therefore to equate EaC with “more IaC.” The literature instead presents EaC as a broader coordination principle spanning provisioning, validation, deployment, operation, and monitoring.

A second boundary concerns abstraction level. Unix’s “everything is a file” remains an OS-level design principle; EaC lifts that spirit into higher-level workflows and, in the agentic AI setting, into agent contexts, memories, tool specifications, and action languages (Piskala, 16 Jan 2026). A third boundary concerns syntax: no new DSL is inherently required. Existing formats such as OpenAPI, GraphQL, Terraform, Mermaid, and markdown already suffice in several EaC formulations (Piskala, 16 Jan 2026).

2. Core abstractions and operational substrate

Two technical lineages underlie EaC. One is the Unix idea that heterogeneous resources should present a uniform interface. In Piskala’s semi-formal model, the set of system resources $R = \{r_1, r_2, \dots, r_n\}$ is mapped to a set of file-like artifacts $F = \{f_1, f_2, \dots, f_n\}$ through a mounting function $M : R \to F$, with each file-like artifact supporting operations $$O = \{\text{read}, \text{write}, \text{exec}, \text{list}, \text{search}\}$$ (Piskala, 16 Jan 2026). In this view, context is retrieved through reads, new knowledge or plans are persisted through writes, and side effects are triggered through exec-style artifacts. The abstraction yields composability, version controllability, and traceability because every action materializes as a file-system artifact.

The second lineage is declarative desired-state management as implemented in Terraform. Terraform uses HCL as a JSON-like declarative DSL in which blocks such as provider, variable, module, resource, and data map to elements of the desired topology. References such as aws_vpc.main.id induce a dependency graph that Terraform models as a directed acyclic graph

$$G = (V, E), \quad V = \{r_1, r_2, \dots, r_n\}, \quad E = \{(r_i, r_j)\mid r_j \text{ depends on } r_i\}.$$

A topological sort of $G$ determines safe ordering for create, update, and delete operations (Howard, 2022).

Terraform’s operational loop formalizes another core EaC idea: state reconciliation. Let $S_c$ denote the current state from the state file and $S_d$ the desired state declared in HCL. Terraform computes

$\Delta = S_d \setminus S_c$

to derive create, update, and delete actions, then applies them in dependency order. The canonical workflow is Write $\rightarrow$ Plan $F = \{f_1, f_2, \dots, f_n\}$0 Apply, supported by state files, remote backends, and locking mechanisms such as Terraform Cloud, S3 with DynamoDB locks, or Consul (Howard, 2022). Within EaC, this provides reproducibility, auditability, drift detection, peer review, and controlled roll-out across heterogeneous providers.

Taken together, these lineages suggest that EaC is not merely a naming convention. It is an architectural commitment to representing operational intent through uniform code artifacts and then driving deterministic planning, validation, and execution from those artifacts.

3. Infrastructure in Code and the collapse of specification boundaries

A central development within EaC is Infrastructure in Code (IiC), introduced by Tankov et al. as a response to the friction of maintaining separate IaC specifications alongside application code (Tankov et al., 2021). Under traditional IaC, developers write infrastructure definitions $F = \{f_1, f_2, \dots, f_n\}$1 by hand. Under IiC, they write only application code $F = \{f_1, f_2, \dots, f_n\}$2, from which an IiC tool infers a cloud-agnostic schema $F = \{f_1, f_2, \dots, f_n\}$3 and then generates infrastructure automatically:

$F = \{f_1, f_2, \dots, f_n\}$4

This reduces the separation between application and infrastructure specifications to zero by embedding infrastructural intent in annotations, framework APIs, and DSL constructs already present in the application.

The architecture implied by the paper is a source-to-infrastructure compilation pipeline. Let $F = \{f_1, f_2, \dots, f_n\}$5 be the abstract syntax tree of application code. DSL-specific extraction functions $F = \{f_1, f_2, \dots, f_n\}$6 identify resource intents, which are collapsed into a cloud-agnostic schema and then transformed by provider-specific generators:

$F = \{f_1, f_2, \dots, f_n\}$7

The provisioning pipeline is therefore a pure function of source code (Tankov et al., 2021).

Kotless is the concrete IiC framework presented by Tankov et al. It is an open-source, production-proven, cloud-agnostic serverless framework for Kotlin that supports two cloud providers, three DSLs, and two runtimes. Developer code can be written against Kotless’s own mini-DSL, Spring Boot annotations, or Ktor extension routes, with optional Terraform snippets for cloud-specific events. A Kotlin compiler plugin parses the AST, collects resource intents via DSL-specific adapters, and emits a unified schema whose primary entities are lambdas, static resources, permissions, and two types of HTTP APIs: dynamic routes and static routes. The engine module uses Terraform.kt to execute provider-specific generators in dependency order and emits HCL for AWS or Azure; Google Cloud and Yandex.Cloud support are under active development. The generated infrastructure targets AWS components such as API Gateway, S3, Lambda, and CloudWatch Events, or Azure components such as Functions Proxy, Blob Storage, Functions, and Time Trigger. Runtime execution can occur on the JVM or, for Ktor on AWS, via a GraalVM native binary to eliminate cold-start latencies (Tankov et al., 2021).

The migration study for the Play KotlinLang sandbox illustrates the operational consequences. The application comprised 7,075 lines of Kotlin code and originally ran on two over-provisioned VMs sized to absorb request spikes up to 17 req/s at a cost of \$F = \{f_1, f_2, \dots, f_n\}$850/month, corresponding to an 80 % reduction (Tankov et al., 2021).

4. Taxonomy across the software delivery lifecycle

Wei et al. report a taxonomy of 25 distinct EaC practices organized into six layers. The exposition highlights the following layer structure and representative practices (Wei et al., 7 Jul 2025).

Layer	Highlighted practices
Infrastructure Provisioning and Management	Infrastructure as Code, Storage as Code, Network as Code
Platform and Orchestration	Platform as Code, Orchestration as Code, Environments as Code
Application Design and Development	Pipeline as Code, Docs as Code, Architecture as Code
Data and Database	Data as Code, Database as Code
Security and Compliance	Policy as Code, Security as Code, Compliance as Code, IAM as Code, Privacy as Code
Observability and Analysis	Monitoring as Code, Dashboards as Code, Analytics as Code, SLO as Code, Detection as Code

The taxonomy matters because it frames EaC as a lifecycle-wide system rather than a set of isolated tooling trends. Infrastructure Provisioning and Management codifies the substrate on which applications execute. Platform and Orchestration codifies higher-level runtime and workflow coordination. Application Design and Development extends version-controlled artifacts to pipelines, architecture models, and documentation. Data and Database codifies schemas, migrations, pipelines, and lineage. Security and Compliance turns governance and regulatory controls into executable checks. Observability and Analysis makes metrics, alerts, dashboards, SLO definitions, and detection logic reviewable and versionable (Wei et al., 7 Jul 2025).

Wei et al.’s conceptual model places these practices across the DevOps sequence Plan $F = \{f_1, f_2, \dots, f_n\}$9 Code $M : R \to F$0 Build $M : R \to F$1 Test $M : R \to F$2 Release $M : R \to F$3 Deploy $M : R \to F$4 Operate $M : R \to F$5 Monitor. Within that model, Policy as Code validates IaC and CaC before provisioning, Security as Code and Compliance as Code integrate as pipeline steps, and observability practices feed operational telemetry back into SLO definitions and detection rules. The overlaps are explicit rather than accidental: $M : R \to F$6 and $M : R \to F$7 appear as structural relationships rather than tool-specific coincidences (Wei et al., 7 Jul 2025).

5. Agentic, policy-centric, and file-centric extensions

In the agentic AI setting, EaC generalizes from infrastructure and delivery artifacts to context and capabilities themselves. Piskala characterizes this as the point at which memories, tools, APIs, models, and even diagrams are cast as code files in a unified namespace (Piskala, 16 Jan 2026). Three patterns are highlighted in coding agents: conversation history as files for durable memory, context retrieval by traversing and reading files rather than opaque vector indexes, and “skills” stored as markdown or API-spec files instead of hard-coded tool bindings. The paper cites multi-agent research at Anthropic (2025), where lead agents and sub-agents communicate entirely through file-like memory, and the “skills” mechanism in Claude Code, where dropping a markdown API spec into /services gives the agent a new capability without changing tool-registry code (Piskala, 16 Jan 2026).

Policy as Code provides a concrete automated loop within this broader perspective. ARPaCCino combines LLMs, RAG, and deterministic tooling to synthesize Rego rules from natural-language policy descriptions, validate them with opa check, preprocess IaC with terraform plan -json, evaluate compliance with OPA or Conftest, and iteratively patch IaC until compliance is reached (Romeo et al., 11 Jul 2025). Its modular architecture comprises a RAG Agent, Policy Synthesis Agent, Rule Checker Agent, IaC Preprocessor Agent, Policy Validator Agent, and Correction Agent. The evaluation reports syntactic correctness rate, semantic accuracy, violation detection precision/recall, and repair success rate. In a Terraform-based case study with 5 policies and a Proxmox provider, Qwen3:30b achieved syntax 0/5 for LLM-only, 0/5 for +RAG, and 4/5 syntax with 4/5 semantic accuracy under Agentic RAG; GPT-4o achieved syntax 0/5 for LLM-only and +RAG, and 5/5 syntax with 5/5 semantic accuracy under Agentic RAG; Claude Sonnet 4 achieved 5/5 syntax and 5/5 semantic accuracy in all three settings. Average Agentic RAG tool-call counts were RAG 4.4 and tools 11.4 for Qwen3:30b, RAG 3.8 and tools 9.0 for GPT-4o, and RAG 3.2 and tools 7.8 for Claude (Romeo et al., 11 Jul 2025).

These results situate Policy as Code within EaC as more than a static rule repository. The workflow becomes code generation, deterministic checking, state extraction, compliance evaluation, and repair in a closed loop. The design lesson emphasized in the paper is that deterministic tooling closes the loop and mitigates hallucinations; another is that a human-in-the-loop should be maintained for critical rules until semantic verification automation matures (Romeo et al., 11 Jul 2025).

6. Experiment-as-Code, benefits, limitations, and open problems

Experiment-as-Code extends EaC into AI-driven scientific discovery by encoding experiments as declarative configurations that compile down to device-level APIs (Yang et al., 6 May 2026). In this stack, a configuration declares resources and high-level steps, then passes through parsing, static analysis, DAG lowering, and code generation:

$M : R \to F$8

The systems layer performs type checking, capability compatibility checks, range checks, invariant enforcement, dependency-cycle detection, resource assignment, and job orchestration. Runtime execution depends on a centralized lab-state database, a workflow engine, and a device shim layer that translates high-level operations into vendor APIs while capturing telemetry and error codes (Yang et al., 6 May 2026).

Across the literature, several benefits recur. EaC improves reproducibility because definitions are versioned artifacts; auditability because changes can be reviewed and replayed; safety because declarative plans can be checked before execution; scalability because orchestration and optimization can be automated; extensibility because new devices, services, or practices can be introduced through schemas, shims, providers, or mounted files; and traceability because, in the IiC formulation, every cloud resource can be traced back to a line in source (Tankov et al., 2021). In practice, Terraform contributes declarative planning, stateful execution, and provider-agnostic extensibility; IiC contributes boilerplate elimination and smoother migration from legacy framework APIs; file-centric agentic designs contribute durable memory and uniform interaction surfaces; and Experiment-as-Code contributes a path from AI-generated intent to physical execution (Howard, 2022, Piskala, 16 Jan 2026, Yang et al., 6 May 2026).

The limitations are equally consistent. Not all infrastructural aspects can be safely inferred: NoSQL schemas, dynamically assembled pipelines, intricate network topologies, capacity planning, and data residency may not be recoverable from source alone. Complex application logic with runtime-constructed resources resists static analysis. Vendor-specific extensions and exotic cloud services may require manual IaC fragments, even when mixed IaC + IiC deployment is possible (Tankov et al., 2021). In file-centric agentic systems, non-text data must be serialized and deserialized in code, large corpora require specialized search indexes beyond naive grep, and real-time protocols such as websockets or gRPC streams may need wrapper processes exposing them as file streams (Piskala, 16 Jan 2026). In lab automation, device shims and capability schemas are nontrivial to implement, semantic completeness is difficult, formally proving that compiled configurations always imply safe device actions remains open, and networked labs introduce synchronization, partition, and trust-boundary problems (Yang et al., 6 May 2026).

Open directions therefore span multiple strata of the paradigm. Tankov et al. identify tooling for languages beyond Kotlin and non-serverless target models such as Kubernetes manifests and VM clusters as fruitful areas for future work (Tankov et al., 2021). Wei et al. call for machine-readable JSON or OWL encodings of the taxonomy and conceptual model, AI-assisted maintenance of emerging “X as Code” categories, longitudinal case studies on deployment frequency, lead time, and compliance cost, and deeper reference architectures for multi-cloud and hybrid scenarios (Wei et al., 7 Jul 2025). The aggregate picture is that EaC is best understood not as a single tool category, but as a general systems principle: encode operational intent as code, make it machine-analyzable, and let planning, validation, execution, and governance proceed from that shared substrate.