Like many others, I use AI in my day-to-day work as a senior software engineer. I’m probably reaching for my AI assistant before my code editor for any change larger than a few lines of code. It not only saves me time and makes me more productive, it can often lead to better code than doing it by hand. Documented functions and thorough tests, for example, are more likely to exist in the initial implementation if I don’t need to write every character.

I was an AI Skeptic

Leveraging large language models to program isn’t something new, of course; GitHub Copilot has been providing super-powered autocomplete since 2021. However, it is new to me. I was an AI skeptic, favoring my own thinking over outsourcing it to a black box. I had been successful with that approach and saw no reason to change. But with the introduction of AI editors, coding agents, and more, it’s impossible to ignore how quickly the AI space is progressing. My perception of AI was becoming outdated.

Just a few months ago, I decided it was time to reassess my opinions on AI and give it a try. The journey wasn’t a success from day one. I tried multiple tools and nearly gave up before I found Claude Code, the AI tool that actually worked the way I wanted.

Here’s what that journey looked like, my perception of Claude Code, and how I use AI in my work.

Finding Claude Code

I’m a die-hard Neovim user. Not even the best attempts at emulation have tempted me away from Neovim’s monospaced simplicity. Editors like Cursor and Windsurf were non-starters when I began my search for an AI tool.

My failed attempts with other AI tools

I first tried avante.nvim. It approximates Cursor in Neovim through a sidebar chat. Despite having standard AI editor features, like code selection for context, reviewing code changes, and seeing the AI’s reasoning, it quite literally felt like a sidebar to my actual work, not an integrated part of my workflow. There was too much friction between the code and the chat, often feeling like I was just a facilitator between the panels. I didn’t feel like I was missing anything by not trying Cursor directly.

Next, I tried Aider, a terminal-based coding tool that works with practically any model. Following their research, I configured Aider with Deepseek R1 for planning work and Claude Sonnet for executing, later trying other models available through OpenRouter. The flexibility that made Aider appealing also became its weakness: I spent more time tweaking models and settings than coding, and the results were rarely usable.

I figured my use case wasn’t well-suited for agentic coding. Both tools consistently had poor results and ultimately slowed me down. I couldn’t tell if I was using the tools incorrectly, the models were insufficient, or I didn’t know how to prompt effectively. In any case, I needed to get work done and went back to an AI-less workflow.

Then I discovered this Claude Code video

That changed when I came across this video introducing Claude Code:

It was like someone had watched me struggle with my previous attempts and built exactly what I was looking for. It seemingly had everything I wanted: terminal-based, compatible with all tools, fits into all existing workflows, and general purpose.

I immediately paid for a subscription with my own money and haven’t looked back.

Claude Code is an editor

Don’t think of Claude Code as an addition to your IDE. Instead, treat it as a novel editor that handles all the low-level work. Instead of directly editing files, you operate at a higher level by describing problems and verifying implementations.

Your traditional editor becomes your secondary device to review code.

And review code, you will—plenty of code. You’ll review proposals and code changes in the same way you review a co-worker’s pull request. Instead of a packaged pull request, however, you’re more likely to review a stream of proposals and changes.

Your job as the reviewer is to steer the editor toward the best chance of success. Steering early on, before code is written, is the most effective approach. Think of it as taking a ship out to sea: it’s much easier to change a ship’s path on a map before setting sail than when out at sea, fighting the ocean’s current. At least I think so. I don’t have a boat.

But I do have a terminal, and that’s exactly where my two favorite editors live: Neovim and Claude Code.

Don’t overcomplicate using it

My simple setup

I use Claude Code nearly out of the box. I am not a Claude Code power user.

That’s not to say Claude Code is worse with customizations or when running multiple instances in parallel. There are lots of interesting tools to add, and developers who can wrap their heads around multiple Claude Code instances are probably running laps around others at their jobs. I just find the standard setup sufficient and easy to use.

The one customization I make is to use Claude Sonnet full time rather than the default setting: Claude Opus for the first 20% of the API usage limit and Sonnet for the remainder. Opus is generally a stronger model than Sonnet with better reasoning and memory, but on the Claude Max 5x plan, the 20% allocation dries up quickly. I plan to experiment with using Opus full-time, and whether or not I stay under the usage limit during the 5-hour session window will determine if that setting stays. Until then, Sonnet still makes me incredibly productive.

My “three-tab” workflow

I almost always keep Claude Code in Plan Mode until I’m ready to execute an idea. Iterating on a design without getting caught up in small implementation details saves a lot of time. Claude Code is typically smart enough to follow existing code conventions anyway. Keep in mind that the model is often incorrect on the first proposal. Expect to iterate in Plan Mode before coding and again even after code is written.

When I’m working, I use tmux to split projects into three tabs:

1. Claude Code to do my primary work.
2. Neovim to review, verify, and—when necessary—correct work.
3. A shell to run development servers and manage Git.

My step-by-step process

I use each tool in that order, cycling through them as I work on a problem:

1. Prompt Claude Code in Plan Mode with an explanation of the problem and iterate on a solution until it is sound. At least 50% of a problem’s time is spent on this step.
2. Let Claude Code do its thing and auto-accept all file changes.
3. Once all the edits are made, jump into Neovim to verify them.
4. If changes are necessary, go back to Claude Code to request them and verify the changes in Neovim. Repeat until satisfied.
5. Stage the changes in Git and repeat from Step 1, committing everything once a milestone is hit.

My productivity ramps up quickly with this setup, and I remain productive throughout the day. I haven’t been stuck because of configuration issues or tooling problems (the same can’t be said about Neovim). Because Claude Code is usually used with a flat-rate subscription, in contrast to the API-based pricing in the alternatives I tried, I never have to think about unexpected costs.

Final thoughts - who is Claude Code for?

I feel Claude Code is most effective for experienced developers who know what good output looks like. Anyone who’s tried AI tools knows it can output terrible code. Developers need to shape the tool’s initial attempt into something worth committing. This requires understanding code well enough to spot issues and architect a good solution.

If you think that fits your profile, do yourself a favor and give Claude Code a try. It turned my view on AI from doubtful to proponent by striking the right balance between magical and practical. It’s an expensive tool—there’s no getting around that—but it’s worth every bit of its cost.