Published on

My IDE Journey: From JetBrains to Claude Code

The tools we choose shape not just our code, but our thinking. This is the story of my journey through three distinct IDE philosophies, each teaching me different lessons about productivity, control, and the relationship between developer and machine. What began as a quest for efficiency ended as a discovery that sometimes, less truly is more. ⌨️

The Philosophy of IDEs: Beyond Feature Lists 🧭

IDEs as Philosophies of Work

Every integrated development environment embodies a distinct philosophy about how humans should interact with code:

JetBrains: The Integrated Excellence

  • Philosophy: "Everything you need, perfectly integrated"
  • One-button perfection for every task
  • Language-specific optimization at its finest

VSCode: The Universal Adapter

  • Philosophy: "One tool for every language"
  • Lightweight portability across all projects
  • Configuration as code, synced everywhere

Neovim + Claude Code: The Keyboard-First Future

  • Philosophy: "Less is More, AI is your pair programmer"
  • Two windows: chat and diff
  • Full keyboard control, unified mental model

Phase 1: JetBrains Era - "The All-in-One Solution" 🏢

The First Encounter with Professional Tools

When I first started serious coding, the transition from basic editors was dramatic. JetBrains IDEs represented a quantum leap in productivity:

The Promise of Integration:

  • PyCharm for Python—intelligent completion that seemed to read my mind
  • IntelliJ IDEA for Java—refactoring that just worked
  • WebStorm for JavaScript—built-in tooling for the entire frontend ecosystem
  • One-Button Everything: Run, debug, test, deploy—all with single keystrokes

What Made It Awesome:

The sheer power of having everything integrated was intoxicating. Function completion wasn't just autocomplete—it understood context, suggested better patterns, caught errors before compilation. Grammar checking went beyond syntax to suggest idiomatic code. Click one button and watch your application run with full debugging capabilities.

For a beginner, this was transformative. No need to configure build systems, set up debuggers, or chain together command-line tools. The IDE handled complexity, letting me focus on learning the language itself.

The Cracks Begin to Show

But as projects grew more complex, patterns emerged that couldn't be ignored:

The Multi-IDE Problem:

  • Python project? Open PyCharm
  • Java service? Switch to IntelliJ
  • Frontend work? Launch WebStorm
  • Each IDE: different memory footprint, separate configuration, unique keymaps

The Configuration Nightmare:

Cross-language projects—increasingly common in modern development—became painful. A typical microservices project might include:

  • Python backend (PyCharm)
  • Java services (IntelliJ)
  • React frontend (WebStorm)
  • Shell scripts and configs (?)

The result? Configuration fragmentation. Each IDE maintained its own:

  • Code style settings
  • Keymap customizations
  • Plugin configurations
  • Database connections

Keeping these synchronized manually was tedious and error-prone. I found myself constantly context-switching not just between languages, but between entirely different mental models of how to navigate code.

The Resource Cost:

Running multiple JetBrains IDEs simultaneously consumed significant system resources. Opening a simple configuration file meant launching a multi-hundred-megabyte application. The integrated excellence came with a heavyweight price.

The Realization

The disadvantage we couldn't endure: fragmented configuration across language silos. When working on hybrid projects became the norm rather than the exception, the JetBrains model showed its age. We needed something that could handle all languages with consistent configuration and reasonable resource usage.

Phase 2: VSCode Transition - "The Unified Environment" 🌐

The Lightweight Revolution

Visual Studio Code emerged as the answer to JetBrains' fragmentation problem:

The Universal Solution:

  • One editor for everything: Python, JavaScript, Rust, Go, Markdown—all in one window
  • Lightweight footprint: Fast startup, reasonable memory usage
  • Settings Sync: One configuration, synced across all machines via GitHub/Microsoft account
  • Remote Development: SSH into remote machines and code as if local

The Workflow Transformation:

For the first time, I could:

  1. Open a monorepo containing backend + frontend + infrastructure code
  2. Use consistent keybindings across all file types
  3. Share settings between work laptop, personal desktop, and remote servers
  4. Switch between projects instantly without heavyweight IDE launches

Extension Ecosystem:

VSCode's plugin system created unprecedented flexibility:

  • Language servers for intelligent completion in any language
  • Formatters, linters, debuggers—all installable on-demand
  • Themes and customization without IDE vendor lock-in
  • Community-driven innovation at incredible pace

The Mouse Problem Emerges

Years passed. VSCode became my daily driver. Configuration syncing was seamless. Remote development was flawless. But a new frustration grew:

Inconsistent Keyboard Control:

Different plugins had different interaction models:

  • File explorer: arrow keys and enter
  • Search panel: custom keybindings
  • Debugger: mix of keyboard shortcuts and required clicks
  • Git integration: some commands via keyboard, others mouse-only
  • Settings UI: heavily mouse-driven

VSCode's Command Palette (Ctrl+Shift+P) helped—many operations could be triggered via keyboard. But not all. Some functionality existed only in right-click menus. Some buttons in extension UIs had no keyboard equivalents.

The VIM Plugin Disappointment:

I tried vim plugins for VSCode. They provided modal editing within text buffers—but that was it. The moment you needed to interact with sidebars, panels, or extension UIs, you were back to the mouse. The unified mental model I craved remained elusive.

The AI Agent Revolution

Then came the Code Agent era:

  • GitHub Copilot showed AI could write boilerplate
  • Cursor IDE demonstrated AI-first editing
  • Claude Code brought LLM agents to the command line

This introduced a new paradigm: conversational coding. Instead of clicking through UIs, you could describe what you wanted and have AI execute the operations.

The Realization

The disadvantage we couldn't endure: forced mouse dependency breaking keyboard flow. When you're deep in concentration, every time your hand leaves the keyboard to grab the mouse, you lose momentum. For developers embracing VIM's modal editing philosophy, VSCode's mouse requirements felt like constant friction.

But more importantly: AI agents pointed to a simpler future. If an LLM could read code, understand intent, and make changes, maybe we didn't need complex IDE UIs at all.

Phase 3: Neovim + Claude Code - "The Keyboard-First Future" ⌨️

The Minimalist Awakening

The transition to Neovim + Claude Code wasn't about adding features—it was about removing everything that wasn't essential:

The Two-Window Paradigm:

My entire development environment now consists of:

  1. Terminal window running Claude Code: The AI agent chat interface
  2. Second terminal showing diffs: What changed, what's being modified

That's it. No sidebar. No file explorer UI. No extension panels. Just:

  • Natural language conversation with AI
  • Code diff review
  • Full keyboard control via VIM keybindings

The Workflow:

# Terminal 1: Claude Code
$ claude-code
> "Add error handling to the API client in src/api.rs"
> "Run the tests and fix any failures"
> "Refactor the database module to use async/await"

# Terminal 2: Watch changes
# Use lazygit or git diff buffer to review changes

What This Achieves:

Unified Mental Model:

  • VIM navigation everywhere—file jumping, code editing, window management
  • One keybinding system to memorize
  • Muscle memory transfers across all operations

AI as Pair Programmer:

  • Claude Code searches files, makes edits, runs tests
  • Review changes in diff view, approve or iterate
  • Focus shifts from "how to implement" to "what to implement"

Context Preservation:

  • No UI chrome consuming mental bandwidth
  • Two windows = two clear contexts (conversation + code)
  • No hidden sidebars, no surprise popups
  • Terminal environment = scriptable, automatable, transparent

The Specific Advantages

1. Full Keyboard Control:

Every operation maps to VIM logic:

  • File navigation: :e, fuzzy finding via telescope/fzf
  • Code jumping: gd (go to definition), gr (references)
  • Window management: Ctrl+w combinations
  • Terminal integration: :terminal or tmux panes
  • Git operations: fugitive plugin or CLI commands

2. AI-Augmented Workflow:

Claude Code handles:

  • Complex refactoring across multiple files
  • Test generation and fixing
  • Documentation writing
  • Code review and suggestions
  • Terminal command execution

You handle:

  • High-level design decisions
  • Code review and approval
  • Intent specification
  • Final verification

3. Resource Efficiency:

  • Neovim: ~10-50MB memory usage
  • Claude Code: CLI tool, minimal overhead
  • Total: Fraction of VSCode or JetBrains footprint
  • Instant startup, no indexing delays

4. Remote Development Natural:

  • SSH + terminal = perfect remote development
  • No protocol overhead (unlike VSCode remote)
  • Same configuration everywhere (dotfiles)
  • Works over slow connections

The Learning Curve Reality

This approach isn't without costs:

Time Investment Required:

  • Learning VIM motions takes weeks to feel natural
  • Configuring Neovim requires understanding Lua/Vimscript
  • Building efficient Claude Code prompts requires practice
  • Debugging without visual debugger UI needs mental model shift

Not Everything Is Easier:

  • Visual debugging (breakpoints, watch windows) more complex
  • GUI-heavy tasks (database browsing) need separate tools
  • Team members may not understand your workflow
  • Some tooling assumes IDE integration

But Here's The Key:

The disadvantages we cannot endure drive tool changes. For me, mouse dependency and fragmented mental models became intolerable. The time investment in VIM + Claude Code was worth it because it solved the friction I couldn't accept.

For others, the advantages of visual debugging or integrated database tools might outweigh keyboard efficiency. That's perfectly valid—different disadvantages matter to different people.

The "Less is More" Philosophy

Reducing my IDE to two terminal windows wasn't about minimalism for aesthetics. It was about:

Cognitive Load Reduction:

  • Fewer UI elements = less visual parsing
  • One keybinding system = less mental context-switching
  • AI handles implementation details = more time for architecture thinking

Intentionality:

  • Every tool present is there by choice
  • Every keybinding is deliberately mapped
  • Every workflow is consciously designed

Flow State Optimization:

  • Hands never leave keyboard
  • Context switches minimized
  • AI pair programming maintains momentum when stuck

The Transformation: From Tool User to Workflow Creator 🚀

This journey mirrors my Arch Linux experience—moving from consuming pre-built solutions to creating personalized workflows.

Phase 1 (JetBrains): Accept the integrated solution, trust the vendor's choices

Phase 2 (VSCode): Customize extensively, but within the extension ecosystem's constraints

Phase 3 (Neovim + Claude Code): Build your environment from primitives, control every aspect

The pattern is clear: each transition trades convenience for control, pre-built for personalized.

Who This Journey Is For

This workflow makes sense if:

  • ✅ You're comfortable with command-line environments
  • ✅ You value keyboard efficiency over visual tooling
  • ✅ You work on cross-language/hybrid projects frequently
  • ✅ You're excited about AI-assisted coding
  • ✅ You enjoy configuration and workflow optimization
  • ✅ You have time to invest in learning VIM

This workflow might not fit if:

  • ❌ You primarily work in a single language/ecosystem
  • ❌ Your team relies heavily on IDE-specific features
  • ❌ Visual debugging is critical to your workflow
  • ❌ You prefer pre-configured tools over customization
  • ❌ Learning curve time feels like wasted effort

And that's okay. The goal isn't to convince everyone to use VIM and Claude Code. The goal is to recognize when a tool's disadvantages have become intolerable for you personally, and have the courage to explore alternatives.

Looking Forward: The AI-Native Development Era 🌟

We're at an inflection point in software development tooling:

The Old Model:

  • IDE provides features: completion, refactoring, debugging
  • Developer drives all actions via mouse/keyboard
  • AI (Copilot) assists with suggestions

The Emerging Model:

  • Developer describes intent conversationally
  • AI agent executes operations: search, edit, test, refactor
  • Developer reviews and guides via natural language
  • Keyboard-driven review and approval

Claude Code represents early days of this model. Future iterations might:

  • Better context awareness: AI understands entire codebase architecture
  • Proactive suggestions: "I noticed this pattern, should I refactor?"
  • Multi-file reasoning: "These three modules should be redesigned together"
  • Test-driven AI: "I'll write tests first, then implement"

The two-window paradigm (conversation + diff) might be the future interface—not despite its simplicity, but because of it.

Conclusion: Embrace Your Intolerable Disadvantages 🎯

The IDE journey taught me this lesson:

Tool changes aren't driven by missing features—they're driven by disadvantages you can no longer tolerate.

  • I left JetBrains when configuration fragmentation became intolerable
  • I left VSCode when mouse dependency broke my flow
  • I adopted Neovim + Claude Code when AI-assisted keyboard-first coding became possible

Your intolerances might be different:

  • Maybe visual debugging is non-negotiable
  • Maybe team collaboration features matter most
  • Maybe integrated tooling reduces cognitive load for you

That's the point. The best IDE is the one that eliminates your friction points, even if it introduces trade-offs others wouldn't accept.

The Meta-Lesson

This journey parallels the Arch Linux philosophy:

  • Windows/macOS ↔ JetBrains: Integrated, opinionated, just works
  • Linux ↔ VSCode: Configurable, extensible, cross-platform
  • Arch Linux ↔ Neovim + Claude Code: Built from primitives, total control

In both cases, the progression is:

  1. Convenience first: Accept pre-built solutions
  2. Flexibility emerges: Discover configuration possibilities
  3. Creation mindset: Build personalized workflows from scratch

Each step requires more investment but returns more alignment with your thinking.

Final Thoughts

If you're doing small cross-language projects and excited about AI-assisted coding, I think this workflow will resonate with you. The combination of:

  • Unified VIM keybindings across all operations
  • AI pair programming via Claude Code
  • Minimal UI reducing cognitive load
  • Complete control over your environment

...creates a development experience that feels more like conversation with your codebase than operating an IDE.

But remember: the greatest minds appreciate wisdom in choices different from their own. Whether you choose JetBrains for integration, VSCode for flexibility, or Neovim + Claude Code for keyboard-first AI assistance—do it with full awareness of what you gain and what you trade.

Happy coding, happy learning, happy creating! 💻✨🤖

This marks my current IDE journey as of October 2025. The tools will evolve, but the principle remains: when disadvantages become intolerable, embrace the change.