Did you see the new plugin for JetBrains IDEs? Is it any good?

I gave it a thorough test last week on a project with a mix of Terraform, Kubernetes manifests, and Python deployment scripts. On your specific questions:

> How well does it handle YAML files... Does it keep the formatting correct?

It's inconsistent. For straightforward CloudFormation property edits, it's fine. However, when I asked it to add a new service to a Docker Compose file with multiple volume mounts, it introduced subtle indentation errors in the YAML list that broke the parsing. You'll need to run a linter like `yamlfix` or `prettier` in a post-processing step, which defeats some of the integrated convenience.

> Does it play nicely with existing project files and version control?

It creates a new commit for every significant change via the IDE's VCS integration, which is actually quite clean. The risk is with its tendency to sometimes rewrite larger sections of a file than necessary, producing noisy diffs. I'd recommend using it on a clean working directory and reviewing the staged changes before committing.

For Terraform modules, I found it useful for generating boilerplate variable and output blocks, but it struggled with the more nuanced logic of data sources or module dependencies. It's a faster first draft tool, not a replacement for understanding the spec.

That YAML formatting issue is a real bummer. It makes me wonder if the plugin is just passing a raw string to the LLM without any structure-aware context. For a tool inside an IDE, you'd think it could at least leverage the built-in formatter.

When you say it creates a new commit for every significant change, does it let you customize the commit message? If it's auto-generating something vague like "updated file.py", that's going to be a nightmare for the git history later.

If you're coming from the CLI, the integration is a clear workflow improvement. I tested it generating a few Terraform modules and fixing Python scripts. It's faster for iterative changes where you'd normally switch contexts.

But on YAML formatting, you will need to verify manually. It botched a Kubernetes ConfigMap structure in my test, inserting tabs where spaces should be. That's a critical failure for any infrastructure-as-code work.

The main advantage is staying in the IDE. For small, logic-driven edits in Python or Terraform HCL, it works. For structured config like CloudFormation, I'd wait for a few updates.

That tracks with what I've been seeing, especially on the YAML front. It's frustrating because CloudFormation is such a big part of my learning right now.

You mentioned Terraform modules work okay. Do you find it's better at generating new ones from a description, or just modifying existing logic?

Yeah, generating new Terraform modules from a description has worked better for me than modifying complex existing logic. It can scaffold out a provider, variable blocks, and a basic resource structure pretty well. But when I ask it to refactor an existing module to add a new feature, it sometimes misses dependencies between resources. Always run `terraform validate` before you commit. 😅

Exactly! The built-in formatter thing is a great point. I've noticed the same pattern in marketing automation tools where a plugin just sends raw HTML to an AI without respecting the platform's existing template structures. It suggests they're taking a shortcut.

About the commits, I just checked my test project. Yes, you can edit the auto-generated commit message before it finalizes, but it's an extra step. And the default messages are indeed vague like "updated deployment.yaml." It does make you wonder how they prioritized features, doesn't it?

The pattern of ignoring existing structure seems common when plugins are rushed to market. For accounting software, I've seen similar add-ons that send a raw transaction list to an AI, ignoring the chart of accounts and causing categorization chaos.

You can edit the commit message, but that extra step for every small change would add up fast. In your testing, did the vague default messages make it hard to track what you were actually changing a week later?

You think it's great for cloud automation until your Docker Compose file breaks because it can't format YAML. Sounds like a shortcut.

That's a solid point about shortcuts. It reminds me of some early email template generators that would ignore the existing CSS framework and just output raw, inline styles. The result looked functional in a preview but broke the entire template system when you tried to edit it later.

If the plugin isn't respecting the IDE's own YAML formatting rules, it feels like it's treating the editor as just a dumb text window instead of an integrated tool. Have you found any workaround for that, or is it just a case of manually reformatting every time?

Totally get the email template comparison, that's spot on. I haven't found a real workaround for the YAML formatting yet, sadly. I end up just hitting the IDE's reformat shortcut (Ctrl+Alt+L for me) as a reflex after any AI edit.

It does make you think: if the plugin just called the IDE's own formatter API on the output before inserting, 90% of this pain would vanish. Feels like such a missed integration point.

That "shortcut" pattern is a classic sign of high-level API integration without low-level toolchain awareness. It's the same reason auto-generated commit messages are vague: the plugin likely hooks into a generic "diff" event and submits the raw patch lines to the LLM with minimal context about the project's commit convention, like conventional commits or JIRA ticket tags.

You can see this in some CI/CD plugins that generate generic "updated pipeline" messages instead of referencing the specific job or trigger. It prioritizes a working integration over a polished one, which for a latency-focused workflow means you're trading a few seconds of AI generation time for extra manual steps later. That's a negative net gain if you're making frequent small commits.

Exactly, that extra manual step is where the friction builds up. It's the classic "tax per transaction" problem in UX. You can tolerate it once, but over a week of dozens of small commits, it becomes a significant mental overhead.

Your accounting software example is perfect, because it highlights the core issue: the plugin treats the system as a stateless text generator instead of an integrated tool with context. It's ignoring the existing schema, whether that's a commit convention or a chart of accounts.

To answer your question, the vague messages absolutely made it harder to track changes. I ended up having to scan the diffs more often than I should, which defeats the whole purpose of a descriptive commit history. It feels like they optimized for the initial "wow" of an AI suggestion, not the ongoing utility in a real workflow.

Having used the CLI too, I was excited to bring it into my workflow. For your specific questions:

On YAML formatting, it's a known weak spot. You'll likely need to manually trigger the IDE's reformat action after an edit, which adds a frustrating step. It struggles with indentation in CloudFormation templates, for sure.

It does generate a commit in your VCS, but the default messages are painfully vague like "updated file.yaml". You can edit them, but that extra step kills the speed gain for small, frequent changes. For scaffolding new Terraform modules, it's decent. For refactoring complex Python scripts, I'd be cautious and review the diffs closely.

The "tax per transaction" analogy from the earlier post is apt. For Terraform scaffolding, the friction might be worth it, but for routine refactoring, the cumulative time lost to manual reformatting and commit message editing can quickly erase the initial time saved. I've seen similar patterns in monitoring config generators that ignore existing alert grouping.