06-reference

technically infrastructure as code terraform

2026-05-28·reference·source: Technically·by Justin Gage

"All about Infrastructure as Code and Terraform" — @Justin Gage

Why this is in the vault

Third Gage piece logged in the last six weeks (after [[2026-04-16-technically-inference-providers]] and [[2026-05-14-technically-package-managers-ai-labs-acquisitions]]) — he is now a tracked author whose explainer cadence is reliably useful for RDCO. This one is load-bearing for the agent-deployer thesis: it names the exact bottleneck the AI-floods-code wave is creating (infra/platform layer) and gestures at three forward paths, one of which ("further job collapse / democratization of DevOps") is directly the FDE pitch we're building around.

It also gives us a clean teaching artifact for client conversations — when a phData Snowflake/Cortex engagement hits the "how do we govern AI-generated artifacts" question, this piece is a good 10-minute primer to point a non-technical stakeholder at before the IaC/governance conversation.

The core argument

Click-driven cloud infra (AWS console menus) breaks down at any real org because of collisions between teams, no review process, cost drift, and unrecoverable disasters. Infrastructure as Code — most prominently Terraform — solves this by treating infra the same way Git solved multi-engineer code collaboration: enshrine the desired state in text files, route changes through pull requests, get review and rollback for free.

Terraform's specific design: a declarative engine plus a plugin model where providers (AWS, GCP, Azure, GitHub, Snowflake, etc.) teach it to talk to each platform's API. You describe end state, Terraform reconciles. Because providers proliferated, IaC has crept beyond servers into permissions, data warehouse tables, and increasingly anything API-driven. Gage flags the tradeoff: centralization slows local velocity, and HCL is a new language to learn (Pulumi competes here by allowing arbitrary languages).

The closing move is the load-bearing one for us. Gage describes a search-feature build at Prefect where the infra engineer had weeks of slack because application code was the slow path. Today, with AI tooling, application code ships in hours and the infra/platform team becomes the bottleneck. He offers three futures:

  1. Hire more platform engineers (default; he notes infra is theorized as "one of the last four jobs")
  2. Let AI write Terraform (closes the gap but the blade is sharp; needs guardrails and review)
  3. Further job collapse — engineers absorb the infra/.tf responsibility, platform teams shift to strategy/enablement (he draws an analogy to how PM/eng have already collapsed in AI-native shops)

Mapping against Ray Data Co

Strong mapping on three vectors:

  1. Agent-deployer thesis sharpening. RDCO's pitch is "AI agents shipping production work need a human translator who owns the deployment surface." Gage's framing — that AI-generated application code is now cheap and the bottleneck moves to governance/infra — is the same shape one layer up. The FDE we're describing is essentially the human in path 3 (engineer-absorbs-infra) for clients who don't have platform teams to bottleneck on. Worth weaving "infra-discipline-for-AI-output" into the data-team-vertical FDE positioning explicitly; it's the natural objection-handler when a buyer asks "why not just let the agents ship to prod."

  2. phData AI Workforce talking point. The job starts 2026-05-26 ([[01-projects/phdata/career-transition]]). Cortex/Snowflake Intelligence agents that build "agentic systems delivering business value" hit the same governance wall. When a client adopts agentic SQL/dbt generation, the question of "who reviews the .tf for the new Snowflake warehouse / schema / role grants" becomes the gating question. Terraform's Snowflake provider is the canonical answer. This piece is a defensible 10-minute pre-read to send a non-platform-team buyer before that conversation. Concrete tactic: keep a link to this article in the phData onboarding folder once it materializes.

  3. Reinforces the [[2026-05-04-dec-age-of-infra-containers-ai-humans|Age of Infra]] thesis already in the vault. That piece argued CI/CD, containerization, and IaC become the differentiator precisely because the application-code layer commoditized. Gage's "AI shifts the bottleneck to infra" is the same claim, said by a second independent author with a specific tool-level example. Two sources, same observation — promote to working assumption rather than single-source hypothesis.

Where to be careful: Gage names Pulumi as a series C competitor. Worth a separate note on Pulumi specifically if RDCO ever has to make an IaC-language recommendation for a client; don't take Gage's "Terraform is the default" framing as the only call. Also: the "one of the last four jobs" link he drops is worth pulling separately — it's a specific futurist claim about which jobs survive automation, and "infra" being on that list is the kind of anchor the vault wants explicit.

No new tracked-author candidate triggered — Gage is already in the rotation. No sponsor relationship to flag (Technically pieces use Substack's own self-promo line, not sponsored placements).

Related