The New IDE Is Not an Editor

Something shifted in how serious development teams are working, and it did not happen gradually. When a company reports compressing months of engineering into days on a 50-million-line codebase, that is not an autocomplete story. That is a different kind of tool doing a different kind of job. The IDE as most developers know it was not part of that workflow.

This is our read on what is happening. It is not a product review, and it is not a formal study. It is an observation shared by a lot of engineers and founders we talk to: the terminal is becoming the development environment, and the tools driving that shift are Claude Code, OpenAI's Codex CLI, Google's Gemini 3.5 CLI, and xAI's Grok CLI. VS Code is still excellent at what it was designed to do. The question is whether what it was designed to do is still the primary job.

The IDE Was Built Around a Human at the Keyboard

This is not a criticism of VS Code. It is one of the best-designed developer tools ever built. But it was designed around a specific assumption: a human is writing every line, and the tool's job is to make that human faster and less error-prone.

That is why it has syntax highlighting, autocomplete, a debugger, an integrated terminal, and a Git panel. Every feature compensates for a human limitation. It reduces the friction between intent and implementation — but it still assumes the human is the implementer.

JetBrains, Sublime, Vim — same design philosophy, different execution. The editor is an extension of the developer's hands. That was the right model for a long time. The best developers were the ones who knew their editor deeply and moved through code quickly. Speed and familiarity were the competitive advantage.

That model is not broken. It is just no longer the only model available.

The Bottleneck Has Moved

Here is what we are seeing in the teams that have adopted CLI-first AI tools seriously: the expensive part of development is no longer writing. It is deciding what to write, reviewing what was written, and catching what was missed.

When you can describe a task and have it executed across your entire codebase, the bottleneck moves upstream. It becomes the quality of the prompt, the clarity of the spec, the rigour of the review. The cursor-on-screen work, the file-to-file navigation, the manual function authoring: that is the part that is being automated.

Not every task looks like this yet. But the tasks where it does are growing in number and complexity. And teams that have restructured around this pattern are shipping faster with fewer people doing the line-by-line work.

What the New IDE Actually Looks Like

The new development environment has four qualities that make it different from anything that came before.

It is terminal-native. There is no GUI. You open a shell, you describe what needs to happen, and the agent works. The codebase is its context window, not a file you navigate to.

It has full repository awareness. A traditional editor knows the open file. Maybe the imports. The new tools read everything: every module, every test, every config. This is how a 50-million-line migration becomes a one-day task instead of a two-month project.

It executes rather than suggests. Early AI tools offered autocomplete. You accepted or rejected, line by line. These tools do not wait. They run, hit a build error, fix it, run tests, fix what fails, and return a finished diff. The loop runs inside the agent, not inside your head.

It converses. You review the output, give feedback, the agent adjusts. The session in the terminal is the development session. Not a file. A conversation with an outcome.

No editor was open. No file was navigated to. That is a development session.

The Tools Representing This Shift

Four tools are defining what CLI-first development looks like in 2026. They each come from a different ecosystem, and that matters for the teams evaluating them.

We are not picking a winner here. Each of these tools is well-suited to different teams and different infrastructure choices. What they share is the paradigm: agent-centric, terminal-first, full-codebase-aware. Naraway can help you pick and implement the right one

Cursor and Windsurf Are the Bridge, Not the Destination

Cursor and Windsurf deserve credit. They are the best GUI coding environments available and they have genuinely changed how developers work. Both are VS Code forks rebuilt around AI as the primary interface. The editor is familiar, but the AI is not a plugin — it is the core of the experience.

These tools are not wrong. They are transitional in the sense that the trajectory of the industry runs past them. The GUI editor with AI built in is one generation behind the agent that operates without an editor at all. Teams using Cursor today are primed to move further when they are ready. The direction is clear even if the pace varies.

What This Actually Means If You Run a Team

This shift does not mean hiring fewer developers and calling it done. It means the role changes. What makes a good engineer in an agentic workflow is different from what made a good engineer in an editor-centric one.

How to Start Without Disrupting Your Sprint

The teams making this shift well are not doing it all at once. They are starting with low-risk, high-repetition tasks and building from there.

Start with something contained

• Pick one task type your team does every sprint: test generation, migration scripts, API scaffolding, documentation
• Run it through Claude Code or Codex CLI on a branch, review the output against what a developer would have produced
• The first task teaches you more about what these tools can actually do than any amount of reading

Treat prompting as a team skill

• The agent's output quality is directly tied to how well you describe the task and the context it needs
• Write prompts that include: what the codebase does, the conventions it follows, and what done looks like
• Share good prompts across the team the way you would share reusable functions

Redesign your review process for larger diffs

• Agent-generated diffs are often wider than human ones — your PR review process needs to adapt
• Focus reviews on architecture and edge cases, not syntax, which the agent handles well
• Use the agent to self-review: ask it to identify what it might have missed before you look

VS Code will not disappear from desktops any time soon. Neither will JetBrains or Vim for the developers who know them deeply. But the frontier of how software gets built has moved, and it moved fast. The teams working at that frontier are not opening files and writing functions. They are opening a terminal and describing outcomes. The distinction sounds subtle. In practice, it is a different job. We help you make that shift