The Quiet Death of the IDE: Why 46% of Developers Fell in Love with a Terminal

I uninstalled three VS Code extensions last October. Cursor's AI panel, GitHub Copilot, and a Copilot-adjacent autocomplete plugin I'd been carrying since 2023. I didn't plan to. I was debugging a race condition in Engram's memory retrieval pipeline and realized I'd spent twenty minutes switching between the terminal and Cursor, copying context back and forth like a human clipboard.

So I just stayed in the terminal. That was six months ago.

The Numbers Nobody Expected

The Pragmatic Engineer's 2026 developer survey landed in March, and the results surprised even the people who ran it. 906 respondents (median 11 to 15 years of experience, not juniors chasing trends) picked their most loved AI development tool.

Claude Code: 46%.

Cursor: 19%.

GitHub Copilot: 9%.

That's not a preference. That's a landslide. And the JetBrains AI Pulse survey (10,000+ developers, globally weighted) backed the sentiment angle: Claude Code pulled a 91% customer satisfaction score and a net promoter score of 54. For context, any NPS above 50 is considered excellent in enterprise software.

Copilot still leads on raw adoption because it ships pre-installed with VS Code and gets bundled into enterprise agreements. Distribution wins quarters. Satisfaction wins years.

What I Didn't Expect

I assumed I'd miss the IDE. I didn't.

I assumed I'd miss inline autocomplete. I do, sometimes, for boilerplate. But here's the thing I was wrong about: I thought the IDE was my development environment. It wasn't. It was a middleman.

When I was using Cursor, every interaction with AI went through an adapter layer. The AI saw what the extension decided to show it. Open tabs, maybe. The current file, definitely. But my git history? Only if I pasted it. My running Docker containers? Never. The MCP servers I use to connect to Supabase, GitHub, and my memory engine? Cursor couldn't touch them.

The terminal doesn't have this problem because the terminal IS the environment.

# This is my actual workflow now
# Claude Code sees everything my shell sees
git log --oneline -20 | head
cat .claude/settings.json
claude "refactor the memory retrieval module to batch requests"

That last command kicks off an agentic loop. Claude Code reads the codebase, runs tests, checks the git diff, opens a PR. It doesn't ask me which files to look at. It figures it out the same way I would: reading the code, running grep, checking imports.

The Composability Argument Is Deeper Than Unix Philosophy

Everyone talks about pipes and composability when they explain terminal tools. That framing is correct but shallow.

The real shift is this: terminal-native AI tools inherit the full capability surface of your machine. IDE plugins inherit only what the extension API exposes.

MCP (Model Context Protocol) made this concrete. There are now over 10,000 public MCP servers. I run six in my daily workflow: GitHub for PRs and issues, Supabase for database queries, Exa for web search, filesystem for local operations, and two custom servers for Engram and my pipeline automation tool Ouija.

In Cursor, connecting to an MCP server required a plugin, a config file, and a prayer. In Claude Code, I add a JSON block to .claude.json and it just works. The tool shows up in Claude's tool list. No adapter. No translation layer.

I built an entire autonomous publishing engine (GhostWriter, the system writing this post) using Claude Code and MCP. It proposes topics, researches them, writes drafts, runs a humanization pass, pushes MDX to my portfolio repo, and cross-posts to LinkedIn. Try wiring that up through an IDE extension.

Four Workflow Patterns That Only Work Terminal-Native

Parallel agents. I run four or five Claude Code sessions simultaneously using git worktrees. Each session gets its own branch, its own scope, its own CLAUDE.md instructions. One refactors the API layer. Another writes tests. A third updates documentation. They don't conflict because git handles the merging. You can't do this in an IDE without opening four IDE windows and manually managing state.

CI/CD integration. You cannot run an IDE extension in a GitHub Actions pipeline. Period. Claude Code runs headless. I use it in CI to generate PR descriptions, run code review, and flag security issues. The same tool I use at my desk runs in my deployment pipeline.

Token efficiency. A benchmark I keep coming back to: Claude Code used 33K tokens to complete a task that consumed 188K tokens in Cursor. That's 5.5x fewer tokens for the same outcome. IDE plugins waste context on extension metadata, editor state, and UI scaffolding that the model doesn't need.

Scriptable workflows. I have a shell script that runs git diff HEAD~1 and pipes it to Claude Code for a security review before every push. Seven lines of bash. The equivalent in an IDE requires a custom extension, a webview panel, and an activation event handler. One of these took me two minutes to write. The other would take a weekend.

What IDEs Still Do Better

I'm not going to pretend this is all upside.

Visual debugging is better in an IDE. Full stop. Setting breakpoints, inspecting variables, stepping through call stacks. VS Code and JetBrains do this better than any terminal debugger I've used. When I'm tracking down a gnarly state mutation in a React component, I still open VS Code.

Rich diffs are better in an IDE. Color-coded side-by-side comparisons with inline commenting. git diff in the terminal is functional, but scanning a 400-line diff is easier with syntax highlighting and collapse controls.

Real-time collaboration. VS Code Live Share has no terminal equivalent. When I pair program, I pair in an IDE.

And honestly, for pure typing speed on boilerplate, Copilot's ghost text is still the fastest path. Tab, tab, tab through a React component scaffold is faster than describing it to an agent.

I'm still not sure giving up the IDE entirely is the right call for everyone. For me, the trade worked. For a frontend engineer who lives in component files all day, maybe not.

The Split Is Permanent

Here's my actual take, and it's one you can argue with: the IDE isn't dying. It's being demoted.

The IDE used to be the center of gravity. You coded in it, you debugged in it, you searched in it, you version-controlled in it. It was the operating system of software development.

That center shifted. The terminal is where the thinking happens now. Planning. Architecture. Multi-file refactors that touch six services at once. The IDE is becoming a viewer. You open it to review diffs, set breakpoints, do the visual work that terminals genuinely can't match. Then you close it.

Steve Yegge described it as moving from "coding by hand" to "managing agent workflows." He's right, but I'd push further. The IDE was built for the first paradigm. The terminal was accidentally built for the second.

GitHub seemed to sense this. Then they injected ads into 1.5 million pull requests through Copilot in March 2026. A developer in Melbourne found promotional "tips" for Raycast hidden in HTML comments inside his PR descriptions. Microsoft called it a "programming logic issue." The developer community called it something else.

When your AI coding tool starts selling ad space in your pull requests, the trust equation changes permanently. That's not a bug. That's a business model revealing itself.

Where This Lands

I run most of my development through Claude Code now. Four to six terminal sessions, each with its own context, its own MCP servers, its own slice of the codebase. When I need to debug visually, I open VS Code. When I need to pair, I open VS Code.

But the creative work, the architecture decisions, the "figure out what's wrong and fix it" work? That happens in a terminal with an AI that can see my entire machine.

46% of developers in that survey felt the same way. Not because terminals are cool. Because they're composable. And in a world where your AI agent needs to touch git, databases, APIs, file systems, and CI pipelines in a single session, composability isn't a philosophy.

It's a prerequisite.