GitHub · PiniShv

The IDE Is Becoming Mission Control

Sun, 05 Apr 2026 10:00:00 +0200

Something happened in the last few months that’s bigger than any single product launch.

Cursor 3 rebuilt its interface from scratch “centered around agents.” GitHub Agent HQ calls its control surface “mission control.” VS Code describes itself as “your home for multi-agent development.” JetBrains Air says the quiet part out loud: traditional IDEs add tools to the editor, while Air “builds tools around the agent.”

That’s not one company experimenting. That’s every major vendor converging on the same architectural shift.

The IDE is becoming mission control. The file tree isn’t disappearing. It’s just no longer the main character.

What actually changed
#

I wrote about how AI IDEs work last year. Back then the story was three systems in a trench coat: autocomplete, context engine, agent harness. The editor was still the center. The AI was a feature bolted on.

That’s not what’s happening now. The center of gravity is moving. The primary surface is shifting from “navigate files and type code” to “assign, monitor, steer, and review agent work.”

Look at what the vendors are actually building:

Cursor 3 puts all local and cloud agents in one sidebar, including ones started from mobile, web, Slack, GitHub, and Linear. That’s closer to an operations console than a code explorer.

GitHub added an Agents tab directly inside repositories with a “mission control style view.” You choose from a fleet of agents, assign work in parallel, and track progress from any device. I covered Agent HQ when it launched. This is the next step.

Windsurf added parallel multi-agent sessions, Git worktrees, and side-by-side Cascade panes. Its vocabulary is plans, todo lists, queued messages, simultaneous cascades, and workflows. That’s orchestration language, not file navigation language.

Replit says the platform became “Agent-first.” Agent 4 adds parallel agents, visible task progress, and the ability to design while the agent builds in the background. That’s basically a kanban board fused with an IDE.

Firebase Studio describes itself as an agentic cloud-based development environment. But Google’s newer Antigravity is the one that says the quiet part out loud. Their tagline: “evolving the IDE into the agent-first era.” They explicitly frame it as: “the tools of yesterday focused on helping you write code faster; the tools of tomorrow need to help you orchestrate it.” That’s not an AI feature added to an editor. That’s a new product category.

Zed added Agentic Editing, third-party agents through ACP, and says the goal is switching between multiple agents without switching editors. Their roadmap includes subagent support and multi-agent collaboration.

Every one of these announcements uses the same vocabulary: agents, sessions, tasks, parallel work, orchestration, monitoring. Not files, buffers, tabs, and syntax highlighting.

Not everyone is moving at the same speed
#

There’s useful nuance here.

VS Code and Zed are still fundamentally editors that are becoming multi-agent hosts. The file tree is still front and center. The agents are a powerful addition, but the architecture is additive.

Cursor, Windsurf, and Replit are further along. The center of gravity has shifted toward session and task management. The code is still there, but it’s becoming a drill-down surface rather than the starting point.

JetBrains Air and Google Antigravity are the clearest examples of vendors saying, explicitly, that the editor is no longer the thing the rest of the product is built around. Air exists specifically because JetBrains decided another editor wasn’t enough differentiation and killed Fleet to focus on agentic workflows.

That spectrum matters. If you’re evaluating tools for your team, know where on this axis you’re comfortable. Some teams want an editor that happens to run agents. Some want an agent platform that happens to have an editor. Those are different products for different stages of trust.

What this actually means
#

This is a change in power structure.

For decades, the code editor held a monopoly as the primary surface of software development. You lived in it. Everything started there. The file tree was your map of the project.

That monopoly is ending. The editor is becoming one pane inside a larger agent-control system. You still need it. But you also need a task view, a session manager, an agent roster, a monitoring surface, and a way to review what shipped while you were doing something else.

I wrote about Cursor Automations triggering agents from events. I wrote about Claude’s computer use controlling your desktop from your phone. I wrote about DeerFlow orchestrating sub-agents in sandboxes. All of those are pieces of the same shift. The IDE is becoming the place where you manage all of it.

The engineers who adapt will treat their IDE the way a DevOps engineer treats a dashboard: a control surface for work happening across multiple systems, some of it human, some of it autonomous, most of it concurrent.

The ones who don’t will wonder why their editor feels increasingly like the wrong tool for the job.

How is your IDE workflow changing with agents? Still file-first or shifting to something else? I’d love to hear it. Find me on X or Telegram.

Glassworm Is Back. Your Code Review Won't Catch It.

Sun, 22 Mar 2026 20:00:00 +0200

Between March 3 and 9, 2026, Aikido Security documented 151 malicious packages uploaded across GitHub repositories, npm, and the VS Code/Open VSX marketplace. The campaign is called Glassworm, and it’s back for a second wave after first appearing in March 2025.

What makes Glassworm different from most supply chain attacks is the technique. The malicious payload is invisible. Not obfuscated. Not minified. Invisible.

I’ve been writing about AI security threats and supply chain risks for a while. Glassworm is the kind of attack that should change how you think about what “reviewing code” actually means.

How it works
#

Unicode has a range called the Private Use Area (PUA): characters from U+FE00 to U+FE0F and U+E0100 to U+E01EF. These characters are valid Unicode. They exist in the spec. But they don’t render. Not in VS Code. Not in your terminal. Not in GitHub’s diff view. Not in any standard code review interface.

Glassworm encodes malicious JavaScript payloads as sequences of these invisible characters, stuffed inside what looks like an empty string. The actual code in the file looks something like this:

const s = v => [...v].map(w => (
 w = w.codePointAt(0),
 w >= 0xFE00 && w <= 0xFE0F ? w - 0xFE00 :
 w >= 0xE0100 && w <= 0xE01EF ? w - 0xE0100 + 16 : null
)).filter(n => n !== null);

eval(Buffer.from(s(``)).toString('utf-8'));

Those backticks at the end look empty. They’re not. They contain hundreds of invisible PUA characters that, when decoded by the function above, produce a full malicious payload. The eval() executes it at runtime. No visible trace in the source file.

The decoded payloads steal tokens, credentials, and secrets, using Solana blockchain as the command-and-control channel to make the exfiltration harder to trace and block.

Why this is harder to catch than you think
#

Traditional code review fails completely against this. A human looking at the diff sees a small utility function and an empty string. Syntax highlighting doesn’t flag it. Linting doesn’t catch it because the characters are valid Unicode. Grep doesn’t find it because you can’t search for characters you can’t see.

AI code review tools face the same problem. They operate on the visible text of the code. If the malicious content is invisible characters inside a string literal, the model sees an empty string. The Anthropic Code Review tool that launched this month dispatches agents to analyze PRs for bugs and security issues. But if the payload isn’t visible in the code representation the model receives, it doesn’t get analyzed.

And Glassworm’s operators are making detection even harder. The visible parts of malicious commits, the parts humans and AI can see, are deliberately convincing. Documentation tweaks. Version bumps. Minor bug fixes. Stylistically consistent with the target repository. Security researchers believe attackers are using LLMs to generate these cover changes at scale across 151+ different codebases.

So you have AI generating realistic-looking innocent commits to cover payloads that are invisible to both human reviewers and AI reviewers. That’s a new class of problem.

What this means for your team
#

If you’re pulling npm packages, installing VS Code extensions, or depending on open source libraries (so, everyone), here’s what matters:

Your current review process probably doesn’t detect this. Unless your toolchain specifically scans for Unicode PUA characters in source files, invisible payloads pass through. Snyk’s analysis recommends detecting Unicode characters by category rather than maintaining explicit character lists, which means your existing SAST tools need updating.

Pin your dependencies and audit updates. Glassworm targets existing repos with seemingly innocent version bumps and doc changes. If you auto-merge dependency updates or trust patch versions without review, you’re exposed.

Scan for eval() and dynamic execution patterns. The invisible payload still needs eval() or an equivalent to execute. Static analysis rules that flag dynamic code execution in dependency code are your best early warning.

Be suspicious of repos you haven’t verified recently. Some of the compromised repos had over 1,400 GitHub stars. Popularity doesn’t mean safety. The Wasmer WebAssembly runtime was among the targeted projects.

VS Code extensions are a vector. Glassworm hit the Open VSX marketplace too. Extensions run with significant privileges. If your team installs extensions casually, you have an unmonitored attack surface.

The bigger picture
#

I’ve written about AI security as a culture problem and building systems that don’t break under attack. Glassworm sits at the intersection of two trends I keep coming back to.

First, AI is accelerating both sides. Defenders are using AI to review code faster. Attackers are using AI to generate convincing cover commits at scale. The speed advantage isn’t one-sided.

Second, the supply chain is where the real vulnerability concentration lives. Your code might be clean. Your review process might be solid. But if one of your 400 transitive dependencies gets compromised with an invisible payload that no human or AI reviewer can see, none of that matters.

Glassworm didn’t exploit a zero-day. It didn’t find a novel vulnerability. It exploited the gap between what we look at and what we actually see. That gap is getting wider as codebases grow faster, reviews get thinner, and both sides of the attack use AI to scale.

The fix isn’t one tool or one policy. It’s treating your supply chain with the same paranoia you’d treat your own production code. Because right now, for a lot of teams, that’s the door nobody’s watching.

Seen something like Glassworm in your own supply chain? Dealing with invisible threats in your dependencies? I’d love to hear about it. Find me on X or Telegram.

GitHub · PiniShv

The IDE Is Becoming Mission Control

What actually changed #

Not everyone is moving at the same speed #

What this actually means #

Glassworm Is Back. Your Code Review Won't Catch It.

How it works #

Why this is harder to catch than you think #

What this means for your team #