A year ago I wrote about getting the most out of Cursor IDE. I’ve since moved most of my development to Claude Code, Anthropic’s CLI tool. This is what I’ve learned.
Why a CLI beats an IDE plugin
Cursor, Windsurf, Copilot - they’re all plugins or forks of Visual Studio Code. They’re embedded in a text editor, which sounds like an advantage but creates constraints.
Claude Code runs in the terminal. It reads files, writes files, runs commands, and manages git. It doesn’t need to understand your IDE’s extension API, it doesn’t fight with other plugins, and it doesn’t break when your editor updates.
The terminal is also a better interface for AI-assisted development than a sidebar chat. You’re already in the terminal for git, builds, tests, and deployments. Having the AI in the same environment means it can do all of those things directly rather than generating code for you to copy-paste.
Self-modifying workflow
Claude Code’s CLAUDE.md files and custom skills make it configurable. You can tell Claude how you want it to work - commit conventions, testing requirements, documentation rules, deployment steps - and it follows them. Skills are custom commands that trigger specific workflows. Hooks run shell commands in response to events like tool calls or file changes.
There’s also a growing library of community skills. Product management toolkits for writing PRDs, code review workflows, test-driven development guides, debugging frameworks. You install them and they become slash commands in your terminal.
The result is an AI assistant that adapts to your workflow rather than forcing you into its own. You modify a few files and Claude changes how it operates.
Context management
The biggest challenge with any AI coding tool is the limited context window. Cursor’s approach is indexing your codebase and RAG-searching for relevant files. Claude Code takes a different approach.
Open in the parent folder
I keep all projects in an org-level parent folder and open Claude Code there. Instead of working in a single project, Claude has access to everything - backend, frontend, infrastructure, shared libraries. I use @ references to pull specific projects into context when needed.
This mirrors the parent folder trick from Cursor, but the CLI makes it more natural. There’s no workspace configuration or multi-root setup - just open a terminal in the right directory.
Plan files
Claude Code writes implementation plans to files in a user-level plans folder. These plans persist across sessions. A new Claude session can read the plan from a previous session and pick up where it left off.
I symlink the plans folder into my parent org folder so Claude can always access plans regardless of which project directory I’m working in. Plans become shared context across all projects.
Document-on-merge skill
I wrote a Claude Code skill - a custom command - that runs when merging a PR. It generates a markdown document covering what changed, why, what was tested, and any decisions made. These documents are saved in a tasks folder accessible to future Claude sessions.
This solves the “context loss between sessions” problem. When a new session starts work on a related feature, it can read the postmortems from previous work and understand the history without me re-explaining it.
Best practices
Commit frequently
Same advice as with Cursor, but even more important. Claude Code can make sweeping changes across many files in a single turn. Commit after each logical change so you can roll back cleanly. Feature branches, small commits, rebase later.
Be specific about what you want
Claude Code works best with clear, scoped instructions. “Fix the authentication bug” is vague. “The JWT token isn’t being refreshed when it expires, causing 401 errors after 1 hour - fix the token refresh logic in the auth middleware” gives it everything it needs.
Use plan mode for anything non-trivial
For any task that touches more than 2-3 files, ask Claude to plan first. It’ll explore the codebase, understand the patterns, and propose an approach before writing code. This catches architectural mismatches early rather than after you’ve accepted 10 file changes.
Read what it writes
The CLI shows you exactly what it’s doing - every file read, every edit, every command. Don’t auto-approve everything. Read the diffs. The AI is good but it’s not infallible, and catching a wrong assumption early saves time.
Constraints to know about
Limited context window. Despite improvements, Claude can lose track of requirements in long sessions. Keep sessions focused. Claude’s built-in todo list helps for tracking tasks within a session, but markdown plan files are better for anything that needs to survive across sessions. Write plans to files, not conversation history.
Speed. Claude Code can be slower than Cursor for simple completions. It’s making full API calls, not doing local inference. For quick edits, sometimes it’s faster to just type. Use Claude Code for the thinking-heavy work - architecture, debugging, multi-file refactors - and your editor for the rest.
Downtime. Claude’s API goes down. It happens. Have alternatives ready.
Alternatives and backups
Codex from OpenAI is worth having set up. The newer OpenAI models are strong for code, and having a second tool means you’re not blocked when one provider has issues.
OpenCode or Kilocode with OpenRouter give you access to a range of models. Kimi K2 is particularly capable for reasoning-heavy tasks, though I’d be cautious using it with proprietary corporate data - it’s a cloud-hosted model from Moonshot AI in China, and the data handling policies aren’t as transparent as US/EU providers.
The broader point: don’t depend on a single AI provider. The tools move fast and having alternatives means you’re never stuck.
What’s next
The gap between AI coding tools is narrowing. Cursor, Claude Code, Copilot, Codex - they’re all converging on similar capabilities. The differentiator is workflow integration, not raw model quality.
Claude Code’s advantage is that it treats the terminal as the interface rather than trying to bolt AI onto an editor.