Delfen
All articlesAI in Practice

The approved module library — the runway your AI actually runs on

The policy gate from part three will pass a clean S3 module every time an AI assistant writes one — however many times the same pattern gets reinvented from scratch. The gate catches wrong. It doesn't catch waste. That's a different problem, and it isn't solved with another check.

Jacques Domenie·17 July 2026·6 min read

Ask an AI assistant for an S3 bucket module and you'll get one that's correct — right encryption, right versioning, right public-access block. Ask again next sprint, in a different repository, and you'll get another one, just as correct, and just as new. The policy-as-code gate from part three of this series will pass both. It's built to catch a wrong configuration, not a redundant one — so it has nothing to say about the fact that somebody just paid an AI, a reviewer's attention, and a CI run to reinvent something that already existed, correctly, somewhere else in the codebase.

The gate catches wrong. It doesn't catch waste. That's a different problem, and no amount of tightening the policy check solves it — because the check only ever sees one plan in isolation. What stops the reinvention is upstream of the gate: a place validated patterns go to become reusable, that both engineers and AI assistants know to look in before they write anything new.

Validated once is not reusable yet

A pattern that passes the gate today proves it's compliant today. It doesn't make it discoverable tomorrow, by a different engineer, or by an AI session that has never seen your codebase before. Spotify's own platform team named this tension with what they call the "golden path" — internal, well-adopted templates for new services. In a separate account of what fleet-wide change used to cost them, they describe a single Java-runtime migration that took eight months and roughly 2,000 semi-automated pull requests to land — before the fleet-management automation they built specifically because that cost was too high to pay repeatedly. Spotify doesn't tell it as a golden-path-drift story, but the lesson generalizes anyway: a path stops being golden the moment nobody's maintaining what walks it.

The lesson generalizes past Spotify's scale: validation is a moment, a library is a maintained place. The gap between "this configuration is compliant" and "the next author reaches for this instead of writing their own" is exactly the gap an approved module library is built to close.

What an approved module library actually is

Concretely, for Terraform shops, this is HCP Terraform's private module registry: modules published from source control, versioned with semver, documented with a required README. Since HashiCorp's 2023 release of the terraform test framework (native since Terraform 1.6, with mocking added in 1.7), you can also configure the registry to run a module's tests on every commit before you tag a release — worth being precise about what that buys you: it's a discipline your team switches on, not something the registry enforces on its own. HCP Terraform will still publish a module version with no tests attached to it at all; a broken test doesn't block a thing unless your workflow is built to check before it tags. Deprecation and revocation are separate, deliberate acts, not silent rot: deprecating a version is available on the Standard tier, revoking one on Premium — either way, a module's decline is a decision someone made, not a thing that happened.

The loop closes with the gate from part three: HashiCorp's public Sentinel policy library ships a reference policy, built on the tfconfig and tfrun imports, that inspects a plan's module calls and can block any configuration sourcing a module from outside the private registry. Deutsche Bank runs exactly this pattern at genuine scale — more than 3,000 developers self-serving across 200-plus landing zones, with the registry made mandatory by policy rather than convention. Their own case study quotes Thomas Chalmers, Assistant Vice President of Cloud Engineering, calling the shift to a trusted private registry "a paradigm shift" in how the bank ships infrastructure. Vodafone Italy's case, smaller in scope, is sharper on the payoff: setup times fell from three months to one week once compliant patterns moved into the registry instead of living in tribal knowledge.

Two adjacent products are worth naming precisely, because the choice between them isn't cosmetic. Backstage Software Templates scaffold whole services — the "new microservice" button, not a bucket module — and it's genuinely good at that job; call it what it is, though: still a CNCF Incubating project, not Graduated, and the widely-quoted "3,000 companies" figure describes companies that have adopted Backstage somewhere, not companies running it at Spotify's own internal maturity. AWS took the opposite bet with Proton — a managed, opinionated golden-path product — and AWS itself is retiring it, support ending October 2026, new customers turned away since a year before that. A vendor with unlimited engineering budget couldn't make a golden path stick if nobody chose to walk it.

Your library's second consumer doesn't read the wiki

Here's the part that makes this a 2026 architecture decision and not a 2020 one: HashiCorp's Terraform MCP server, generally available since June, ships tools that let an AI assistant search and read from your private module registry directly — not just the public one. By default, the server points at the public registry only. Wiring it to yours, via a registry-private toolset, is a decision an architect makes on purpose. HashiCorp's own description of the payoff is direct: assistants that connect this way "discover approved modules, understand your organization's patterns, and generate compliant code automatically" — the reinvention this article opened with stops being the default outcome and becomes something you have to go out of your way to cause.

This inverts who the module's documentation is actually for. A README used to be a courtesy to the next engineer, half-read at best. Now it's the only context an AI session has before it decides whether to reuse your module or invent a new one from a public example it found somewhere else — which means a stale README doesn't just confuse a junior developer once. It mis-informs every AI session that reads it, at whatever rate your team generates infrastructure code. Staleness used to spread at the speed of onboarding. It now spreads at the speed of autocomplete.

How module libraries die

Three failure modes, all documented by people who hit them, not by me guessing:

Sprawl into mega-modules. HashiCorp's own platform-maturity guidance names the trap directly: "the path of least resistance is often to create a new module instead of trying to reuse one," and the fix — forcibly consolidating scattered patterns — tends to overcorrect into a small number of brittle, do-everything modules that are harder to change than the sprawl they replaced.

Wrapper modules that add ceremony, not value. Microsoft's Mark Tinderholt, author of Mastering Terraform, documents the anti-pattern of a module that wraps a single resource with no added logic. His concrete example is a Bicep module rather than a Terraform one — the anti-pattern doesn't care which IaC language it's written in — but the number is the point: copy-instantiated 21 times, each instance adding indirection with nothing underneath it.

The golden cage. Nilesh Jayanandana named the tension in November 2024: golden path versus golden cage. It sharpened a year later when Bryan Ross, Steve Fenton, and Matt Menzenski each wrote their own version of the same warning as contributors to a shared CNCF platform-engineering writing effort — not independently, but converging on the same diagnosis anyway: a path built for control instead of consumption gets walked because it's mandatory, not because it's good, and every workaround it forces just moves further from view. Ross's framing is the sharpest test I've found for whether your library has crossed that line: "the real measure of a successful platform isn't adoption, but whether developers would choose your platform even if they weren't required to."

Start with one module

Not a platform initiative. One module: your team's single most-duplicated pattern, the thing that gets rewritten in every new project because nobody's sure whether the old version still works. Give it an owner, a semantic version, a .tftest.hcl test file, and a README that states what it does and what it deliberately doesn't. Publish it to the registry. Point the registry-sourcing Sentinel policy from part three's gate at it, so the gate now has something correct to point people toward, not just violations to catch. Then connect the private-registry toolset to whatever your team uses to write infrastructure with AI.

Here's the falsifiable test, and it costs nothing to run: ask your AI assistant to scaffold your team's standard service. If it reaches for a public module instead of yours, you've just learned your runway exists on an architecture diagram and nowhere else — the machine didn't ignore your standard. It never found it.

Next

The network and failure-domain decisions that don't show up in any Terraform plan — until the day they're the only thing that matters.

If you want the series as it lands, subscribe below.

If you can't beat them, lead them.

Sources & further reading

Continue reading

Get the next article in your inbox.

One deep-dive per week. Free. No pitch. Unsubscribe anytime.

Subscribe to the Delfen Briefing →
← Back to all articles