VS Code 1.98 strikes back at Cursor with native multi-file editing,
What “native agentic workflows” change in day-to-day editing
VS Code 1.98 puts agent-style assistance closer to the editor itself instead of treating multi-step edits as a side conversation. An agentic workflow is not “chat that happens to paste code.” It is a loop where the tool proposes changes across files, you review intent and diffs, and the editor applies or rejects those edits with the same undo, source control, and search surface you already trust.
That matters for multi-file work because real features rarely live in one buffer. Renaming a shared type, wiring a new API handler, or splitting a module into interfaces and implementations all require coordinated edits. When the agent can stage those edits natively, you spend less time copying snippets between windows and more time checking whether the design still holds after the change set lands.
Multi-file editing as the real battleground with Cursor
The summary of this release is blunt: VS Code is answering Cursor’s strength—fast, multi-file AI edits—inside the stock editor. The product fight is less about who has the flashiest chat panel and more about who keeps the human in control while the model rewrites several related files at once.
Native multi-file editing only pays off if the review path stays clear. You still want to see which files are touched, which hunks are pure refactor versus behavior change, and whether tests or call sites were updated in the same pass. If the agent edits five files but only one is visible, you will ship accidental API breaks. Treat multi-file proposals like a small PR: read the graph of changes, not just the first file that opened.
- Ask for a short plan before large edits so the agent states file targets and invariants.
- Apply in slices when the change spans layers (schema, service, UI) so each layer can be verified.
- Keep local tests or a smoke script ready; agentic speed is wasted if verification stays manual and ad hoc.
- Reject partial “looks fine” diffs that skip error paths, logging, or config wiring you know the feature needs.
What “Project Islay” signals about platform direction
“Project Islay” sits alongside the agentic and multi-file story as a named initiative rather than a one-off feature toggle. Even without treating the label as a marketing checklist, the pairing in the release title implies Microsoft is investing in a coherent agent experience inside VS Code—not a single command that writes a function and stops.
For teams, that direction reduces a practical risk: building internal workflow around a third-party AI IDE fork, then watching the upstream editor catch up. If your preference is Microsoft’s extension ecosystem, remote development, and existing settings sync, native agentic multi-file editing lowers the pressure to switch tools just to keep pace with AI-assisted refactors.
How to adopt this without letting the agent own the repo
Use agentic multi-file edits for bounded jobs: introduce a pattern already agreed in the codebase, migrate call sites after an interface change, or generate boilerplate that you will still review line by line. Avoid handing the agent open-ended “fix architecture” prompts with no acceptance criteria; those produce wide diffs that are hard to reason about and harder to reverse cleanly.
Establish a local rule: the agent proposes, the human owns the commit message and the test evidence. Prefer smaller, named change sets over one mega-edit. When Project Islay-style workflows become part of your daily path, the win is not faster typing—it is shorter time from intent to a reviewable, multi-file patch that still reads like your team’s code.