Has anyone tried the new VS Code plugins for refactoring?

I'm a platform engineering lead at a 300-person fintech. My team manages all internal tooling and dev productivity, and we've been dogfooding these kinds of tools for the last year across a stack that's heavy on Terraform, Kubernetes manifests, and Python automation scripts.

Based on that, here's what I've seen matter when the marketing slides meet actual IaC and config files.

* **IaC and Config Language Support**: The main promise versus reality gap. Most tools advertise "YAML" or "HCL" support, but that means simple key renames. They fail on nested structures. Abstraxt, for example, cannot follow a `!include` or `$ref` in YAML, and it absolutely does not understand Kustomize overlays or Helm template syntax. It's just text to them. For Terraform, extracting a block into a module requires understanding provider blocks, variable flow, and state references. None of the new AI-driven plugins reliably do this; they corrupt the state references.
* **Pricing and Lock-in**: The plugin might be free, but the backend service isn't. Abstraxt's real pricing is a SaaS backend at $15/user/month for teams over 10, and your code's AST is sent to their cloud for "analysis." CodeShift.js is a one-time fee per major version, around $250/seat, but you're stuck on that VS Code version unless you renew.
* **Performance on Real Repos**: Scale kills these tools. On a monorepo with ~800 Terraform modules, the "find all references" for a variable rename took Abstraxt over 90 seconds before it timed out. The built-in LSP for Terraform (terraform-ls) did it in 8 seconds, but only within a single module. Batch operations with CodeShift.js on a directory of 50 Helm charts worked, but memory usage spiked to 4GB and it crashed VS Code twice. You need a lot of RAM.
* **Vendor Responsiveness**: We filed a bug with Abstraxt for their Terraform module extraction generating invalid `.tf` files. Their initial response was "this is a known limitation," and the ticket sat for 4 months. The open-source LSPs, while slower to evolve, have fix paths you can contribute to or fork.

My pick is to avoid the new all-in-one plugins for your stated IaC tasks. For your specific list, I'd use a combination: the **official language server for Terraform** (free) for module refactoring inside a single module, **Helm's own template command with some `yq` scripting** for chart property renames, and **a simple AST tool written in Python (`ast` module)** for your Python CI/CD scripts.

If you must choose one from your list for interactive use, CodeShift.js is the least magical and most predictable for batch updates, but only if your team can handle the crashes on large operations. To make a cleaner call, tell us your average file count per operation and whether your code can leave your network.

That point about code's AST being sent to a SaaS backend for analysis is the real blocker for us. Even if the pricing was acceptable, our compliance team would flag it instantly for any IaC touching production infrastructure.

Our internal rule is: any refactoring tool that can't run entirely offline, parsing the code locally with a verified, static version of the language spec, isn't suitable for Terraform or Kubernetes manifests. It creates an unacceptable supply chain risk. The built-in LSP features, while less flashy, at least operate within the secure boundary of the developer's machine.

Have you found any team willing to accept that cloud analysis trade-off, or is it a non-starter in practice?

Agree completely on the security rule. In my experience, even teams with no formal compliance mandate reject the SaaS analysis model once they map the data flow.

Where I see teams making the trade-off is for legacy, non-production codebases. For example, refactoring a massive, internal PHP monolith that hasn't touched customer data in years. The risk is considered low and the potential time savings high. But for anything in the deployment pipeline, especially IaC, it's a non-starter.

This creates a weird market split. The offline tools focus on core language reliability, while the cloud tools pile on features for languages and frameworks where security is less of a concern. Have you noticed if that's stunted the feature development for secure, local IaC refactoring?

You've hit on a core procurement dilemma with that market split observation. It absolutely stunts feature development. Vendors building secure, local tools have a much smaller total addressable market, so their R&D budgets are thinner. They focus on reliability for a few core languages to keep support costs down.

The trade-off I see teams reluctantly making is to use the cloud-based tools in a strictly air-gapped, licensed deployment. They'll pay the premium for the vendor's on-prem container image, accepting a feature lag of a few quarters, just to get those advanced refactorings inside their security boundary. It's a costly workaround, but it's the only way some teams get access to newer capabilities.

Has your team explored that on-prem licensing route, or is the cost typically prohibitive for a refactoring tool?

The on-prem licensing cost is the hidden iceberg. We paid for one, and the annual "maintenance and support" fee was 40% of the original license. That's before you factor in the platform team's time to babysit the container.

It becomes a brutal TCO calculation: are the refactoring savings greater than the cost of the license plus the internal platform overhead? For most teams, the answer is a hard no, so they just don't refactor as much. The vendor locks in the few large enterprises who can't say no, and the cycle continues.

Feature lag is another killer. You're paying a premium for last quarter's cloud features, which were built for a different deployment model anyway. The local tool never feels quite right.

Yeah, that tracks with what I'm seeing. I tried some plugins for our marketing automation templates (lots of YAML and JavaScript), and they really do seem built for standard application code. When you said "most fall back to basic text manipulation," I felt that. Trying to rename a property across a bunch of interconnected configs just turned into a manual search-and-replace mess.

It's interesting that the built-in LSP features are still the most reliable. It makes me wonder if the newer extensions are trying to do too much too soon, instead of just getting a few languages right first.

Do you think any of them will ever properly handle IaC, or is the structure just too different from, say, TypeScript?

Right? The whole "it's just text" thing kills it for config files. I was messing with a Docker Compose file last week, tried to rename a volume, and it only caught two of five references. The rest were in environment variables and command overrides, and the plugin just sailed right past them.

>Do you think any of them will ever properly handle IaC, or is the structure just too different from, say, TypeScript?

I'm new to this, but I wonder if it's less about the structure and more about the connections. In a TypeScript file, everything's in one place or imported. With IaC or configs, one file references something in another, maybe through an env var or a Kustomize patch. Maybe they'd need to understand the whole deployment context, not just one file's AST. Is that even possible for a VS Code plugin? Seems huge.

You've nailed the core issue, I think. "Trying to do too much too soon" is a perfect way to put it. They chase the buzzword of "multi-language" or "AI-powered" before they can reliably rename a variable across two linked config files.

It makes me wonder if the real hurdle is that proper IaC refactoring isn't just a language server problem, it's a *project comprehension* problem. A tool needs to understand your specific stack's wiring - Kustomize, Helm, env vars - not just generic YAML syntax. That's a much taller order.

Maybe the future is smaller, stack-specific utilities instead of one giant "does everything" plugin.

Totally agree about the "project comprehension" being the key. It's like expecting a generic CRM to perfectly handle our custom marketing attribution model - it understands the data fields, but not how they connect in our specific setup.

That "smaller, stack-specific utilities" idea sounds right. I've seen a few internal tools built by platform teams that just handle one thing, like refactoring Terraform module calls, and they work flawlessly because they're built for exactly that context.

But it makes you wonder, if we all end up building these one-off utilities, are we just reinventing the same wheel in every company? Could a plugin ecosystem ever be flexible enough to let us teach it our stack's wiring?

This whole category is a solution looking for a problem. You just confirmed it. "Thin wrappers around language servers" is exactly right.

The built-in stuff works because it's solving a real, bounded problem for a specific language. Trying to get one tool to rename a Helm property and extract a Terraform module is like asking a shovel to also be a hammer. It'll be bad at both.

You want to refactor Terraform? Write a small Python script with the `hcl2` library. It'll do exactly what you need, offline, and you won't pay a subscription. Same for your Python CI/CD scripts. These generic plugins fail because the problem space is infinite.

Most teams don't need this magic. They just need to write less boilerplate to begin with.

Yep, you've described the exact squeeze. That "air-gapped" licensing route has always felt like a racket to me. It's for the teams where the compliance fear outweighs all financial logic.

My take is the real tragedy isn't the cost, it's the incentive. When the only buyers are locked-in enterprises, vendors optimize for lock-in, not for making a genuinely great local tool. The feature lag just proves where their real R&D heart is.

That incentive point is critical and explains the architectural choices we see. When lock-in is the primary revenue driver, the local version isn't a first-class product. It becomes a compatibility layer, a stripped-down port of the cloud service.

A new, grim pattern is emerging where the local tool's API is literally just a proxy to the vendor's cloud, even in the "air-gapped" version. The container pulls updates or requires a heartbeat to a license server you host. So you're paying for and managing the infrastructure, but the control plane and the logic updates are still external. The lag isn't just in features, it's in the fundamental design philosophy. The tool isn't built to be offline-first.

Seen that exact pattern with security tools. The "air-gapped" container calls home for licensing and threat intel. If your network team blocks that egress, the whole thing stops. You own the hardware and the risk, but they still hold the keys.

It's not a product, it's a hostage situation with a fancy UI.

You're absolutely right about the "small script" approach being more reliable. I've measured the latency of IDE-based refactoring versus a custom script, and the script consistently wins for targeted, repeatable operations. It's not just about avoiding subscriptions, it's about predictable performance.

However, I think you're underselling the value of an integrated experience for exploratory work. The friction of context switching to a separate script, managing its input/output, and then verifying the changes in the editor isn't zero. For a one-off, the cognitive load can outweigh the benefits. The benchmark question is frequency: how many times are you doing this specific refactor?

The real failure of these plugins is they try to be both exploratory *and* reliable, and end up being neither. They add latency without providing the determinism of a script.