Aiden for InfraOps: The Complete Platform Engineering Series
Six posts, one argument: the job of a platform isn't to generate infrastructure code. It's to let a small team safely hand infrastructure to a large one. Here's the whole series in one place.
The short version
- This is the hub for a six-part series on building governed, self-service infrastructure with Aiden for InfraOps.
- The throughline across all six: a clean separation between the people who create infrastructure and the people who consume it is what makes self-service safe at scale.
- Read it in order for the full argument, or jump to the part that matches the problem in front of you.
- It covers team archetypes, the force-multiplier value model, modules vs. appStacks, the module catalog, onboarding by Terraform maturity, and how to author modules developers actually want.
Earlier this year the StackGen engineering team wrote a set of points of view on how platform engineering actually works — why teams buy a platform, where the value really sits, and the design decisions that make or break developer self-service. This series turns those into six posts you can read start to finish or dip into as needed.
One idea ties them together. A platform earns its keep when it lets a two-person team support a thousand developers without drowning, and the mechanism underneath that leverage is the same every time: separate who builds infrastructure from who uses it, then give each group the right tool. Everything below is a facet of that single idea.
Part 1 — Platform Engineering Teams: Enablers vs. Accelerators
There's no single "platform team." Most are either Enablers chasing true developer self-service or Accelerators speeding up TicketOps without giving up control. Knowing which you are decides whether a platform fits. Read Part 1 »
Part 2 — The Force Multiplier: How Two Engineers Support a Thousand Developers
The value of a platform isn't code generation — generative AI already does that. It's acting as a governance, curation, and safety layer so a small platform team can support a large organization. The honest test: could your platform team run the whole company on it without headcount growing in lockstep? Read Part 2 »
Part 3 — Modules vs. appStacks: The Producer-Consumer Split
Modules are the reusable Lego blocks a platform engineer authors; appStacks are the deployable applications developers assemble from them. Keeping the two separate is what makes guardrailed self-service possible at all. Read Part 3 »
Part 4 — Why Your Module Catalog Isn't an IDE (and Shouldn't Be)
The Module Editor is a quick-edit tool, not a rival to Cursor. The Module Catalog is a curated library — usable as a standard Terraform registry — not an editor. Judging each by the wrong yardstick leads teams astray. Read Part 4 »
Part 5 — Meeting Teams Where They Are: A Terraform Maturity Guide
Greenfield, brownfield with no Terraform, or a mature IaC estate — your starting point decides your first move. A practical map from where you are to a curated catalog and applications expressed as appStacks. Read Part 5 »
Part 6 — Authoring Modules for Developers, Not for DevOps
The biggest predictor of whether self-service works: do your modules hide complexity and expose intent? Two anti-patterns to avoid, three principles to follow, and what "good" looks like when developers get safe building blocks instead of a 200-variable panel. Read Part 6 »
Where to start
If you're deciding whether a platform fits your team, start with Part 1 and Part 2. If you're already building one, Parts 3, 4, and 6 are the design core. If you're planning a migration, Part 5 is the practical path. Wherever you begin, the destination is the same: a curated catalog of hardened modules and applications expressed as appStacks — the producer-consumer split that lets developers move fast without being able to do real damage.
That's the whole point of Aiden for InfraOps, and it's the thread running through all six posts.
