The Blueprint, Not the Bricklayer's Instructions

Opening Scene

A blueprint describes what a finished building should ultimately look like: this wall here, this door there, without specifying the exact sequence of individual actions a bricklayer must take to get there. A detailed instruction sheet, by contrast, specifies the exact step-by-step sequence: lay this brick, then this one, then this one. Both can produce the same building, but they represent genuinely different approaches. Infrastructure as code tools embody this exact same distinction between declarative and imperative approaches.

In Plain English

Declarative infrastructure as code describes the desired end state — “this database should exist, with these settings” — and leaves the tool to figure out exactly how to get there, including detecting and reconciling any difference from the current state. Imperative infrastructure as code specifies the exact sequence of steps to execute — “create this database, then set this setting” — requiring the author to account for the starting state explicitly. Most modern IaC tools favor a declarative approach, since it’s generally easier to reason about and reconcile over time.

The Old Way

Before declarative IaC tools were widely available and preferred, infrastructure automation was often built imperatively:

• Early infrastructure automation was often built as imperative scripts, executing a specific sequence of steps rather than describing a desired end state.
• There wasn’t yet a well-established preference for declarative tools that could automatically reconcile a described end state against whatever the current, actual state happened to be.
• Imperative scripts sometimes failed or produced unexpected results when run against an environment that didn’t match the exact starting state the script assumed.

Imperative, sequence-based automation, without a declarative alternative that reconciles automatically, is what modern declarative IaC tools directly address.

What’s Changing (and Why AI Is the Reason)

1. Organizations increasingly favor declarative IaC tools specifically because they reconcile a desired end state automatically, rather than requiring precise, sequence-dependent scripting.
2. This connects directly to the idempotency principle covered in Article 5, which is a natural, expected property of well-designed declarative tools.
3. As AI-assisted infrastructure code generation, covered in Article 19, becomes more common, declarative definitions are generally easier for both humans and AI tools to generate and verify correctly than sequence-dependent imperative scripts.

The Metaphor, Fully Extended

The Brick Mold	Infrastructure as Code Concept
A blueprint describing the finished building’s desired state	Declarative code describing the infrastructure’s desired end state
A detailed instruction sheet specifying exact sequential steps	Imperative code specifying an exact sequence of execution steps
The bricklayer figuring out how to reach the blueprint’s goal	The tool figuring out how to reach the declared end state
Both producing a result, but genuinely different approaches	Both producing infrastructure, but genuinely different approaches

Quick Recap

• Declarative IaC describes a desired end state; imperative IaC specifies an exact sequence of steps.
• Declarative tools generally reconcile automatically against the current state, while imperative scripts assume a specific starting point.
• Most modern IaC tools favor a declarative approach for its easier reasoning and reconciliation.
• Declarative definitions are generally easier for both humans and AI tools to generate and verify correctly.

Where This Fits in the Series

Article 3 covered the core distinction between declarative and imperative infrastructure code. Article 4 turns to a benefit this approach unlocks: a revision history for the building itself.