Why VS Code for PowerShell? Link to heading

While I can’t say I’ve ever been a fan of the ISE, it has long been relied on by PowerShell enthusiasts and admins alike. Since Microsoft deprecated the ISE, it has pushed users toward VS Code and the PowerShell extension. VS Code and the PowerShell extension do bring a lot of useful features when compared to the dated ISE, but how much of that comes from the editor vs. extension? If VS Code disappeared tomorrow, what would we lose? Which features would we really miss?

Which parts of my workflow are essential, and which are just habit?

The more I thought about it and looked into it, the more I realized that most of what I rely on daily isn’t coming from VS Code itself. It’s coming from the layer beneath it.

Where do the Features Come From? Link to heading

VS Code relies on extensions for language support. This means the editor uses the Language Server Protocol (LSP) and Debug Adapter Protocol (DAP) to communicate with the PowerShell extension, which is basically a wrapper for PSEditorServices.

The features I rely on daily come from the same place:

  • Go-to definition
  • Go-to reference
  • Peek definition
  • Diagnostics
  • Auto complete
  • Symbol picker
  • Symbol rename

None of these features are inherently tied to VS Code. They exist because of the language server, PSEditorServices, not the editor itself.

Which means those capabilities are tied to PowerShell and any editor that can speak LSP. Once you see it that way, the role of the editor starts to look very different.

The Editor Is Just a Client Link to heading

Once the language services are separate, the editor stops being the environment and becomes an interface. Installing PSEditorServices on your machine means that interface is now interchangeable. The question then becomes:

Is the center of gravity my editor or my terminal emulator?

For some workflows, the editor may very well be the center of gravity, and that’s a defensible position. For me, and I suspect many admins and ops folks, that center of gravity is the terminal. I don’t need the file explorer if I can programmatically manipulate files from my terminal. I don’t need a source control pane if I am competent with git. I don’t need an integrated terminal if I’m already living inside of one. So my quest took me on a journey to experiment with terminal based editors that speak LSP. Helix is my preferred client so far, but the point is that it doesn’t have to be, nor should you feel stuck in VS Code because Microsoft recommends it, or because you think PowerShell extension only exists there.

Why Terminal-First Aligns Better With How Systems Actually Run Link to heading

If the editor is just a client, then it raises a more important question: where does the system actually live? For me, it’s not in the editor. It’s in the runtime. The scripts I write don’t run inside VS Code. They run in PowerShell. The automation I build doesn’t execute inside an editor, but runs as jobs, scheduled tasks, background services, or in cloud environments. The logs, output, and side effects of that work all happen outside of the editor.

The editor is just a place to shape text. The system lives somewhere else.

That’s why a terminal-first workflow ended up making more sense for me. It keeps me closer to the environment where my code actually runs. From the terminal, I’m not just editing code. I’m executing it, piping it, inspecting it, and interacting with the system in real time. PowerShell sits at the center of that, acting as both a shell and a programming language — which means I can:

  • Execute scripts directly in the context they’ll actually run
  • Pipe outputs between commands and compose behavior incrementally
  • Inspect live system state without leaving the workflow
  • Debug using the same runtime my automation depends on

The terminal isn’t just another interface—it’s the closest interface to the system itself. That changes how the editor fits into the workflow. Instead of being the place where everything happens, it becomes one of several tools that sit alongside the runtime. I can open a file in an editor, make a change, and immediately test it in the same environment it will live in without crossing boundaries between “editor world” and “runtime world.” For me, that alignment matters more than convenience features or UI integration. The tighter the loop between writing, executing, and observing behavior, the more predictable my systems become.

None of this requires abandoning VS Code. It just means recognizing that the editor isn’t the center of the system.

Once that clicks, working in a terminal-first way stops feeling like a downgrade and starts feeling like working closer to the source. The editor stops being a dependency and becomes a choice.