Agentic Coding and the Weakness of Extensions for IDEs

A few weeks ago we got a warning about extension marketplaces. The reported story was that a cryptocurrency developer, using the Cursor AI IDE (which is a fork of Visual Studio Code) noticed that he was short a considerable amount of cryptocurrency; about half a million dollars worth. What happened? He realised his development system had been hacked and so he asked investigators to help.

The malicious code was traced to a VS Code extension, that ostensibly added Solidity language support — which is used for writing smart contracts within Ethereum. The extension, after it had been installed, downloaded a script that effectively gave remote control (via ScreenConnect in this case) to an attacker. The extension itself was just a carrier.

Now, obviously, once you see the term “cryptocurrency,” most people will assume that there are no lessons to be learnt — because, well, obviously, cryptocurrency is just a scam anyway and anyone working on it is somehow problematic. But hold on a moment.

How many times have you looked to add extensions for a new project, especially in VS Code, and saw multiple extensions that could be what you need? For example, one is named “C# Tools,” another says “C# Additions,” and yet another says “C# Essentials.” What to do? Yes, you look at the number of downloads. But our cryptocurrency developer in the story above saw that the valid and invalid extension had a similar number of downloads — in fact, the fake one was higher up in the ranking list of Solidity extensions. Bot activity had simply inflated the statistics, but the attackers also understood Open VSX’s ranking algorithm well enough to fool the system.

The problem isn’t that one piece of a complex system can be attacked. The problem is that an IDE with a plugin extension model was never meant to be used as a permanent solution at the scale it has been.

In the case of Cursor AI, because it isn’t a Microsoft product, it can’t use the Visual Studio extension marketplace. Instead, it uses the competing open VSX marketplace, which is a “vendor-neutral registry for VS Code extensions.” Microsoft’s reputation requires it to carefully police its marketplaces. Understandably, there is slightly less scrutiny in an open marketplace. This is the usual security vs. innovation trade-off. As this excellent Java Brains video points out, even if the code is clean on GitHub, by the time it is packaged into an extension, it might have become adulterated.

I mentioned in an early review of Augment Code that swapping extensions in and out not only destabilised VS Code, but the UI actually couldn’t tell you which extensions were active. The platform became completely inconsistent. I think a routine in Augment noticed the issue first:

👁 Image

Extensions don’t work as peer systems properly, so they can’t really share state information.

I also mentioned that Cursor, being a fork of VS Code, had consequences — the most obvious one being that you can’t work directly with the .NET debugger in the IDE. This means the many fans of Cursor AI usually have Visual Studio Code open too, in order to work with C#. The fact that a popular IDE is built on top of another one, which then can’t use the existing marketplace, should immediately be a red flag.

Let’s not get tangled up in security issues. After all, these problems exist everywhere. What we need to focus on is the design issues around the IDE ecosystem. It requires trust through third parties, or the Sauron eye of Microsoft, to check everything. Ultimatel,y the problem is that a temporary coping mechanism is being leaned on to deliver mainstream functionality for LLMs. There really needs to be building platforms at a lower level, which will allow more IDEs to be developed with secure open source components that can naturally encompass innovation with AI.

Visual Studio Code has been successful as a transition from single-language code editors, but it is now an architectural dead end.

Agentic AI in the Terminal to the Rescue?

We should thank VS Code for ushering in LLM boosted development, but we are now in the Agentic Era. While I’ve already indicated in various reviews over the last few months that there is quite a lot of variation with the various terminal-based Agentic Command Line Interfaces, they represent a fresh design perspective while being much less complex than a fully blown IDE.

That’s why Claude Code is, so far, the product that has made the biggest splash of the year. It’s too early to tell whether Anthropic’s Model Context Protocol (MCP) represents a more robust way to extend tooling abilities, but the innovation in this area is healthy.

In reality, the Agentic terminal doesn’t replace a code editor, but it does take the pressure off using the IDE as the sole platform for a fully AI-boosted workflow. IDE design issues need not weigh down LLM development as well.

Conclusion

The Agentic Command Line Interface gives us a chance to explore better workflow designs, independent from the current IDE ecosystem. Whether it is successful or not, it has given developers a chance to reflect on the options that best help them use LLMs in their everyday work.

We already have enough to worry about with bias in LLM weightings, hallucinations, token expense, etc. We can’t really be expected to spend bandwidth on IDE issues too. LLMs included as extensions to IDEs just add unnecessary instability.

There is room for a quite considerable redesign of the developer’s workbench with LLM assistance, while leaving IDEs to do what they were built for — to allow humans to hack code.