Two features in Aiden for InfraOps get mistaken for things they're not. The Module Editor gets mistaken for an IDE, and the Module Catalog gets mistaken for the editor. Both mix-ups lead you to evaluate them against the wrong yardstick.
Part 4 of 6 in the Aiden for InfraOps series. Start with the series overview »
The short version
People ask us, reasonably, why the in-product Module Editor isn't as powerful as Cursor, and why the Module Catalog doesn't behave more like an editor. Both questions come from the same place: treating two purpose-built tools as if they were trying to be general-purpose ones. They're not, and the reasons they're not are worth spelling out, because they tell you how to actually use each one.
The Module Editor is a dedicated tool for power users to create and edit Modules. Note the scope: Modules, not appStacks. (If that distinction isn't second nature yet, Modules vs. appStacks lays it out.) Its primary job is making quick changes to a Module without ceremony.
What it is explicitly not trying to be is a competitor to full-featured IDEs like Cursor or VS Code. That's a deliberate position, not an accident of the roadmap. We actively resist the temptation to build a competing IDE, because that's a different, enormous product, and it isn't the problem we're solving.
The analogy we keep coming back to is GitHub's web-based editor. When you need to fix a typo in a README or tweak one line, you don't clone the whole repository, open your local editor, commit, and push. You click "edit" in the browser, make the change, and save. It's a convenience tool for small, in-context changes. That's the Module Editor. It's where you make a quick edit to a Module, not where you'd sit down for a day of deep development.
Here's the candid part, the kind of thing worth saying out loud before a customer discovers it mid-evaluation. The Module Editor's current AI capabilities are not as good as the ones in tools like Cursor. The infrastructure code it generates may not be deployable without some manual intervention. That's the honest state today. If your workflow depends on heavy AI-assisted authoring, do that work in your real IDE and bring the result in. Use the Module Editor for what it's genuinely good at: fast, convenient, in-context edits.
The Module Catalog is a different animal. It's the central, curated library of every Module your organization has approved for use. The clean one-line definition: a library curated by your platform engineer, for the developers in your company. It represents your tenant's entire universe of Modules.
The best analogy here isn't an editor at all. It's a private Artifactory or jFrog instance, but for Terraform Modules. In fact the Catalog can be exposed as a standard Terraform registry — the term most teams already recognize — so your Modules stay consumable the same way any Terraform module is, straight from the tools your engineers already use. It's the trusted shelf of approved building blocks. It can host Modules created privately inside Aiden for InfraOps, and it can pull in Modules from elsewhere. The Catalog is the source of truth for "what blocks are my developers allowed to build with," and curation is the whole value: a developer reaching for storage should find the handful of blessed options, not every Module anyone ever wrote.
That curation role is exactly why the Catalog matters for self-service. Developers consume what's in the Catalog. The quality and shape of that library is what they experience, so it deserves real product thinking rather than a bulk import. (We get into how to author the Modules that belong in it in Authoring Modules for Developers, Not for DevOps.)
The most common structural misunderstanding is assuming the editor and the Catalog are two views of one system. They aren't. The Module Catalog is a completely independent entity from the Module Editor.
The editor is one possible source of a Module. But the Catalog's primary job is to aggregate Modules from many sources: Modules authored in the editor, Modules from GitHub, Modules from public or private registries, and so on. Decoupling them is what makes that aggregation possible. If the Catalog were just "the place you see things you made in the editor," it couldn't be the organization's full universe of approved Modules, which is the entire point of having a catalog.
Practically, this independence means you're not locked into authoring everything in-product. You can bring in high-quality Modules you already trust, curate them into the Catalog, and use the editor only when a quick in-place change is the convenient option. The two tools cooperate, but neither depends on the other.
Judge each tool by its actual job. Don't benchmark the Module Editor against Cursor; benchmark it against "can I make a small change quickly without leaving the platform," and lean on your real IDE for serious authoring until the in-product AI catches up. Don't expect the Module Catalog to behave like an editor; treat it as your curated registry and put your energy into what's allowed in and how it's organized, because that curation is what your developers actually feel.
Get those expectations right and both tools do exactly what they're meant to: the Catalog gives your developers a trustworthy shelf of blocks, and the editor gives your power users a fast way to tweak them. Neither is pretending to be a general-purpose IDE, and that focus is what keeps them useful.
← Previous — Part 3: Modules vs. appStacks: The Producer-Consumer Split
Next — Part 5: Meeting Teams Where They Are: A Terraform Maturity Guide →
See all six parts in the series overview »