From Emacs to Cursor, the end of your IDEs is near

Emacs in 1976, then Vim, Sublime Text, Atom, VSCode, and today Cursor: for fifty years, the code editor kept evolving, yet it always stayed on the developer's machine.

And it stayed there for one real reason: the latency between the keyboard and the screen forced every keystroke to give an immediate visual response.

With agents, we're no longer the ones typing the code. We write prompts, launch agents and review what they produce.

In other words, the keyboard is now only used to write instructions.

So the local IDE has no structural reason to exist anymore, and it ships in with a pile of problems we shouldn't accept in 2026: a machine that saturates the moment you parallelize, secrets lying around everywhere, an exploding supply chain attack surface.

In this article, I lay out why I think we're going to stop coding locally and what the dev environment that takes over should look like.

Why we used to code locally

The local IDE exists because we need zero latency between keystroke and visual feedback.

When every character you type has to trigger autocomplete, the linter and the type-checker and then repaint the screen without you noticing, a remote editor at 80ms is simply unusable and the brain feels it immediately.

That's the only serious technical reason to code on your own machine, because the rest of the stack moved to the cloud a long time ago: builds, deployments, execution, CI, storage.

The editor stayed glued to the dev's machine solely because of this keystroke-latency issue.

But we don't type the code anymore

These days, my workflow when I code looks like this: I write a prompt, I launch an agent, I let it run while I do something else, I review the diff it produces and either approve it or redirect it for another iteration.

The keyboard is no longer used to write code, it's used to write instructions.

And writing instructions is prose that has no need for sub-frame latency. The only historical justification for the local IDE just collapsed.

And if these agents manage to produce code you can actually ship, it's because we've learned to feed them the right context at the right moment.

Without that layering, they drift in every direction and the whole workflow falls apart.

I already wrote about this in 2023 in The new era of programming: the developer would become a conductor while LLMs handled the implementation details.

We're there, and a conductor doesn't need their podium sitting on their personal MacBook.

What staying local actually costs

Once the "latency" justification falls, you can honestly look at the balance sheet of what you keep by staying local, and it's not good.

A machine that saturates the moment you parallelize

An agent that codes is a build running in the background, tests executing, a dev server restarting and a pile of files being watched continuously.

So if you run three of them in parallel on a MacBook, you end up with fans at full blast, swap going through the roof, the IDE lagging, and usually one of the three agents timing out on a command.

But the real win with agents is precisely being able to parallelize them: while one refactors a module, the second can write the matching tests and the third can prepare the PR.

The usual workaround is to use git worktrees to have each agent work in an isolated copy of the repo. That cleanly handles branch conflicts, but doesn't change the fact that the builds, the dev servers and the test suites still share the same CPU and the same RAM.

We just pushed the problem one level down. We can now run three agents without them stepping on each other on Git, but the machine itself is still capped by its physical resources.

Locally you're capped by your machine, when you should be capped only by your own ability to review what the agents produce.

Secrets lying around everywhere

If you run history | grep API_KEY on any dev machine that has been running for a few months, the result is telling: .env files at the root of every project, export OPENAI_API_KEY=sk-... fired off into a terminal and forgotten in zsh history, and AWS or GCP credentials in clear text in ~/.aws/credentials and ~/.config/gcloud/.

No rotation, no audit, no isolation. It's amateur hour by any prod standard.

And the worst part is that every agent you launch on this machine inherits all those accesses by default without you realizing it.

The supply chain attack surface

The case that really got my attention recently is Get Shit Done (GSD), a Claude Code companion tool whose creator turned out to be malicious and slipped malware that exfiltrated credentials from the machine into an update.

The community ended up forking the project to get a clean version, but in the meantime any dev who had installed the booby-trapped update was handing their keys directly to the attacker.

And it's far from an isolated case:

• Mistral AI's source code was put up for sale on underground forums after a supply chain attack.
• GitHub suffered a breach because of a compromised IDE plugin on one of their developers' machines.
• event-stream in 2018, ua-parser-js in 2021, and all the typosquatted npm packages that come out every month.

The underlying problem is that when an agent asks for permission to install a new package, most of the time we approve without reading the package-lock.json diff.

And the velocity of agents mechanically accelerates the rate at which we install third-party code on our work machine.

And the stakes are anything but trivial. Cybercrime already costs around $10.5 trillion per year in 2025, and attack volume in early 2026 is up 10 to 20% over last year, close to historical records. At the level of a single organization, the average cost of a data breach hovers around $4.5 to $4.9 million, and every minute of downtime runs between €4,000 and €7,500.

Our dev machine has become an ultra-sensitive environment where we install anything without thinking, and yet it's precisely the place where all our keys to production systems are sitting.

What comes next

Cloud environments that orchestrate agents

The editor disappears in favor of an interface whose only role is to launch agents, watch their work as it streams, interrupt them and redirect them when they head in the wrong direction.

Each agent runs in its own throwaway sandbox with scoped, revocable credentials, the source code never touches your machine, and npm install happens in the agent's isolated environment rather than yours.

It's exactly the same logic as with a human. When you hire a developer, you don't let them push straight to production: you put in place guardrails, processes, reviews and docs so they can make mistakes within a frame where the error has only a limited business impact. Agents work differently from us, but the problem is exactly the same: they make mistakes, and those mistakes can hit your business. So they too need a dedicated environment that reduces the blast radius of what they break.

There are already early signs of this with Devin, Cursor Background Agents, Codex Cloud or Claude Code running inside GitHub Actions, but they're still positioned as a complement to the local IDE rather than as its replacement.

I think the shift will happen quickly because the pressure comes from both sides at once: developers want to parallelize more tasks while CISOs want to stop seeing API keys and production source code lying around on personal MacBooks that meet no security standard.

What we're building at Maleus

That's precisely the gap we're trying to fill at Maleus, with a cloud dev environment where agents run in isolated sandboxes and you drive everything from the browser, without ever having to open a terminal on your own machine. Concretely, that means:

• a cloud dev environment provisioned per project, with its backend, dependencies and runtime managed on the platform side, fully replacing the local setup
• strict process isolation where secrets live in the environment and are injected only into the backend process that actually needs them, rather than being exposed on the filesystem or in the shell of every peripheral tool running alongside
• a grace period on npm install that prevents a freshly published package from being executed immediately, neutralizing the typical attack window of a compromised supply chain
• automatic package updates delegated to a cloud agent that checks diffs and CVEs before applying, rather than a local npm update that blindly trusts the registry
• a kernel-level sandbox for each agent, isolating it from the rest of the environment and denying it access to anything it doesn't explicitly need for the current task
• code visualization directly in the browser, with diffs and review integrated in the same place as agent orchestration
• agent piloting from that same web interface, where you launch an agent, watch it work, interrupt it or redirect it without ever leaving the browser

This is probably the direction the entire dev toolchain will take over the next two years.

The local IDE will survive only for the niche cases where keystroke latency remains critical: game dev, embedded, certain low-level debugging contexts.

Conclusion

The local IDE is an artifact of an era when we typed the code, and that era is no longer ours.

I'm not saying it'll disappear tomorrow, habits take time. The transition will probably happen in steps: first long-running agents in the cloud, then review in the cloud, then everything else.

But it has no structural reason to exist anymore, and it actively worsens the security problems we all have right in front of us without really wanting to look at them.

The dev environment of the next few years will be cloud and multi-agent, and the interface will look more like an orchestrator than an editor.

Which means that the whole "editor + extensions + local linters" value chain is on borrowed time, and that's probably where to build for the years ahead.