After experimenting with Cursor, Windsurf, Zed, and other tools, Singh reports getting more done in the editor he already knew. His account is not a benchmark—there are no timed tasks or measured productivity gains—but it raises a useful question: Is a new tool solving a development problem, or has evaluating tools become the project?
The strongest lesson here is not that VS Code beats every AI-first alternative. It is that changing your coding assistant and changing your entire working environment are two different decisions.
The hidden cost of finding the perfect editor
Singh describes a cycle of trying new interfaces, rebuilding settings, checking extensions, and learning how each editor handled AI interactions. He also kept comparing agents: which understood a repository better, which handled multi-file changes more effectively, and whether another update justified another move.
Crucially, he says he was not necessarily dissatisfied with those editors. He kept looking for improvements without always identifying a specific limitation in his existing setup.
That distinction matters. Testing software against a concrete requirement is evaluation. Repeatedly switching because something promising appeared can become maintenance work disguised as progress.
The practical takeaway is to make a new editor earn its migration cost. Before switching, finish this sentence:
If the answer is clear, an evaluation may be worthwhile. If it amounts to “the new demo looked impressive,” consider trying the capability without moving your whole workspace.
“Plain VS Code” does not mean AI-free
Microsoft’s current documentation supports the central premise behind Singh’s return: VS Code can accommodate different AI workflows rather than requiring a single assistant. It documents inline suggestions, agent collaboration alongside code, and an Agents window. It also lists Copilot, Claude, and Codex agent harnesses, with access depending on supported accounts, API keys, and the selected service.
That makes keeping the editor while changing the agent a credible option. It does not mean every integration has identical capabilities, billing, or configuration requirements. Microsoft explicitly separates model choice, agent harness, and access arrangements.
Singh also values the option of running coding tools from the terminal and using local models. Microsoft documents supported local-model options, but that should not be stretched into a promise that any local model replaces every Copilot capability. Likewise, choosing an editor does not determine where inference happens: Microsoft notes that an agent can edit local files while sending model requests to a hosted provider.
The useful flexibility is architectural, not magical. Keep the workbench familiar; evaluate the assistant separately.
There is also no independent feature-by-feature comparison here establishing that Cursor, Windsurf, or Zed has lost its advantages. Singh’s preference supports a personal workflow decision, not a universal ranking.
Remote development is part of the equation
For Singh, the attraction of VS Code extends beyond generating code. Remote access, containers, extensions, and familiar development tools are part of the environment he wants to preserve.
Microsoft’s Remote - SSH documentation confirms that the extension opens folders on remote machines with an SSH server and runs commands and relevant extensions remotely. Source files do not need to be copied to the local computer. Once connected, a new integrated terminal runs on the remote host—an important distinction when executing commands.
Container support needs a little precision. Microsoft documents combining Remote - SSH with the Dev Containers extension to open a remote folder inside a container on supported hosts. Remote - SSH is not, by itself, a blanket replacement for container tooling or a file-synchronization service.
Remote Tunnels offer another route, without requiring an SSH setup. Microsoft documents both the code tunnel command and a desktop interface for enabling access. Connections use an Azure-hosted service, require authentication with the same GitHub or Microsoft account at both ends, and generally need no firewall changes.
There is a practical catch: the host must remain available. A tunnel enabled through the desktop interface stops being reachable when that VS Code instance closes, unless a separately running CLI tunnel provides access. “No SSH configuration” does not mean “no running host required.”
For developers who rely on these workflows, editor evaluation should include remote debugging and extension behavior—not just the quality of an agent’s first response.
Two details worth checking before settling in
Local dictation has privacy boundaries
The source’s description of local voice dictation needs qualification. Microsoft documents on-device desktop speech recognition for Windows x64 and Arm64, Apple-silicon Macs, and supported Linux systems. After the initial model download, recognition can work offline. The web client instead sends audio to Microsoft’s voice service and requires connectivity and GitHub sign-in.
There is another distinction: local audio recognition does not necessarily mean all transcript processing stays local. Microsoft documents optional language-model cleanup that sends transcript text to a Copilot model. Keeping both audio and transcript processing on the device requires on-device recognition and cleanup to be disabled.
Extensions deserve scrutiny, too
VS Code’s extensibility is useful, but an extension is executable software, not decorative furniture. Microsoft states that extensions have the same permissions as VS Code itself and documents publisher-trust prompts for third-party installations.
Its documentation also notes that Settings Sync does not synchronize extensions into or out of remote windows such as SSH, development containers, or WSL. That is a useful troubleshooting detail if a familiar tool appears missing after connecting remotely.
A better way to evaluate the next editor
Singh’s experience suggests a more deliberate approach—not a ban on experimentation:
- Name the missing capability. Choose a real task that your current environment handles poorly.
- Try changing one component first. Where supported, test another agent without replacing the editor.
- Compare completed work. Include setup, corrections, testing, and review—not merely generation speed.
- Test everyday dependencies. Check extensions, terminals, remote access, and debugging before committing to a move.
- Set a stopping point. Decide what result would justify migration, then return to the project.
Regardless of the editor, AI output still needs validation. Microsoft warns that agents can produce incorrect code or misunderstand intent and instructs developers to review changes before committing or merging them. Familiar surroundings do not transfer responsibility to the assistant.
The sensible conclusion is narrower—and more useful—than declaring a winner in the editor wars. Singh reports benefiting from a stable environment while retaining AI assistance. Developers facing the same churn can test that approach without treating it as an industry-wide verdict.
The next editor may genuinely improve your work. It should have to demonstrate that improvement before your existing setup gets an eviction notice.