I was a top 0.01% Cursor user.
Here's why I switched to Claude Code 2.0.

It's March of 2023. Github Copilot is our frontier of AI coding.

ChatGPT is still a novelty. Model improvement isn't taken for granted.

GPT-4 gets released.

Instantly it's clear that this is paradigm shifting.

We could create a loop of AI thinking with some tools to search the web and write code for us. The smell of AGI is in the air!

We decide to call these loops "agents". I was lucky enough to help build the first AI agent AutoGPTwhich went mega viral and is to this day the fastest growing repo to 100k stars.

But it didn't really work. If you got lucky, every once in a while you could get an almost working tic tac toe game.

For anything more complex? Forget about it.

Cursor came along in 2023 with promises. I tried and churned in October 2023 and again in May 2024. Good old copy and paste from ChatGPT was still better.

Then in September 2024 Cursor Composer came out.

From that moment, 90% of my code became AI generated.

I lived in that editor. I pushed it to its limits, wrote an internal guide on best practices that I never published, and figured out every trick: surgical cursor placement, context window management, Cursor rules, the perfect prompting patterns for different scenarios.

I had found the answer to all my problems. I even got an email from the team that I was a top 0.01% Cursor user.

I tried Claude Code earlier this year. Churned.

The workflow felt like a step backward from what I had built with Cursor. The model wasn't quite there yet, I still needed to know what was going on in the code more often than not.

Why would I ever use a tool that's barely as good and a 10x worst UX?

Enter Claude Code 2.0.

The UX had evolved. The harness is more flexible and robust. Bugs are fixed. But that's all secondary.

The truth is that whatever RLHF Anthropic did on Opus 4.5 completely changed the equation. We've now evolved to the next level of abstraction.

You no longer need to review the code. Or instruct the model at the level of files or functions. You can test behaviors instead.

I built a genetic algorithm simulator with interactive visualizations showing evolution in real-time including complex fitness functions, selection pressure, mutation rates, and more in 1 day. I didn't write a single line of the code.

Here are the types of things people are building with Claude Code:

Other things I've recently built with Claude:

A skeptic on Twitter asks:

Until a month ago, I shared the sentiment. Here's my answer:

Recommendation: Use Cursor as your default if you're

a) an organic coder who finds abstracting all code away to behavior scary, or
b) want to learn how to code.

Use Claude Code if you

a) never plan on learning and just care about outputs, or
b) are an abstraction maximilist.

There is a VSCode extension for Claude Code which can ease your transition. But the UX still isn't near as good as Cursor. And it defeats the purpose.

You should be abstraction maxxing.

Claude Code with Opus 4.5 for most tasks. Planning, code generation, complex refactors, architectural decisions.

Cursor with GPT 5.2 / Sonnet 4.5 when I need tight feedback loops. Learning, UI perfection, small changes.

ChatGPT for a few things: (a) programming related questions that don't need project context (like setting up an A100 VM in Azure), (b) second opinions on plans, and (c) when I don't understand an output or need clarification on something Claude said.

Ghostty as my terminal. Made by the cofounder of HashiCorp. Fast, no flickering, natively supports terminal splitting, better text editing experience, and native image support.

Wispr for voice to text. If you work from home or have your own office, not having to type all the time is valuable. Begone Carpal tunnel. I need to be in a certain mood to use it.

It was written in the scriptures. Buckle up.

Here's some tips I've picked up over time on context management:

1. "spawn a subagent to do deep research on this topic" Spawn subagents for parallel work. They do not pollute the main agent's context. They can individually do work and add just the valuable context from their work to the main agent's context.
2. /compact - Others are iffy about compacting, but often the tradeoff to stay in the same chat and eat the compacting is worth it. Their system for compacting is smart.
3. /transfer-context That said, after compacting enough times or doing any task not directly related, quality will degrade. Don't be afraid to create new chats. If you need to transfer context, just tell the model to give you a prompt to put into another model with the related context for the task with the files (for anything advanced create md files, although I find managing these md files to be annoying). Here's a gist of my /transfer-context command.
4. /contextShows you how much context you have left. You'll get a report like this:

   

   Claude will also tell you when you're running low on context.

   

   Make the decision to compact or to switch chats at this point. Don't wait until it hits 0% as it will degrade your outputs, and if it compacts in the middle of a task it will forget potentially relevant context that you've given it even in the last chat.
5. Maintain focus: one chat = roughly one task. If a chat is focused on a single task it will have more relevant context. The definition of a 'task' is miles broader than what it used to be. Test the limits and see what works for you.
6. Generating things in a chat that already has context will always perform best, whether it's docs, tests, or related code. Sometimes for one off changes (like a bug fix), I'll do them within the chat context, commit changes, and then rewind the conversation back to save context.

Use /resume to continue from a previous chat.

Note on context limits: Claude Code has a 200k context limit. You hit the wall faster than alternatives like Codex (400k) or Gemini (1M).

Your time spent planning is directly proportional to agent output.

Rule of thumb: a good prompt will save you 3 minutes of time on follow up prompts and debugging for every 1 minute you spend planning.

Shift+Tab twice: Enter plan mode. I use it, but only for larger tasks or when the exact shape of what I want it to be is unclear. Note: plan mode saves to a .md in the global ~/.claude folder, which isn't accessible within your repo. I'll either ask Claude to create a plan.md in the repo after plan mode, or skip plan mode entirely and plan in-chat.

After creating your plan, use our /interview-me-planmd command which interviews you in depth about your plan before building. (See this X post, I've also tried it myself and found it genuinely effective.)

Opus 4.5 is amazing at explaining things and makes stellar ASCII diagrams. My exploration involves asking lots of questions, clarifying requirements, understanding where/how/why to make changes.

Backwards compatibility: Models are currently, RLHF'd so far into oblivion that you need to explicitly ask it to not maintain backwards compatibility.

Watch out for overengineering: Claude models love to do too much. Extra files, flexibility you didn't ask for, unnecessary abstractions. Be as explicit with what NOT to do as possible. Pete puts it well: "We want the simplest change possible. We don't care about migration. Code readability matters most, and we're happy to make bigger changes to achieve it."

Keep in mind: Coding agents are better at creating new files than editing existing ones. It can often be valuable to tweak the seed prompt and reset all the code from scratch.

There's a classic XKCD about programmers spending a week automating a task that takes 5 minutes.

With agentic coding, this equation has flipped. Closing the loop is now almost always worth it. The cost of automation has collapsed. What used to take a week now takes a conversation.

If you find yourself doing something more than once, close the loop. If you spend a lot of time doing x thing, close the loop.

• Make commands for repeated prompts
• Make agents for repeated work
• Update your claude.md
• Make prompts in .mds (like Cursor rules!)
• Change tsconfig and other config files

The only way you or the model know that you're right is if you can verify the outputs.

Before, you had to be in the code. Then with Cursor, you had to approve every edit. Now, just test behaviors with interface tests.

Interface tests are the ability to know what's wrong and explaining it.

For UI this means looking, for UX this means clicking around, for API this means making requests. And checking the responses.

A good way to think about closing the loop is to make it easy for you to verify by making it easy for the agent to verify.

For large refactors: Ask Claude to build comprehensive interface tests beforehand. This ensures you got the refactor right. The tests become your verification layer.

Writing tests: The best tests are written in the same context as the code they are testing.

Let Jesus take the wheel. For production apps, test in staging or dev on a PR. Integration tests are your safety net. If they pass, ship it.

AI writes code fast, but debugging AI code requires different skills than debugging your own. You didn't write it, so you don't have the mental model.

When something fails, use systematic debugging. I have a /debug command that triggers thorough investigation:

The rule of three: If you've explained the same thing three times and Claude still isn't getting it, more explaining won't help. Change something.

Show instead of tell: If Claude keeps misunderstanding, show it a minimal example of what you want the output to look like. Claude is good at following examples.

Start fresh: If you're making lots of changes to your plan, start a new session. Get the agent to summarize the situation, what has been tried, and learnings. Copy paste into a new Claude session.

Different models have different blind spots. When stuck, get fresh perspectives:

You can automatically review your PRs and commits. Claude can catch issues, suggest improvements, and provide context aware feedback before human review even begins.

You can do this via a Stop hook (more on these later) with Claude code in headless mode (-p) that triggers on every commit, or via prs. When I've used automated reviewing it was always at the via PR level.

If you have access, use Codex for PR review. You don't want the same inductive biases that wrote the code reviewing it. Codex catches things Claude misses and vice versa.

Run /refactor to do a focused cleanup session with these tools.

I refactor when I either feel pain because Claude is making mistakes, or after large additions to codebases. I'm not the only one of the opinion that doing this continuously kills momentum. Treat it as a distinct phase.

Claude won't understand your preferences around code cleanliness. Over time, add context to your Claude.md that reveals your preferences and reduces refactoring time.

Always bias towards using the most powerful models. Use /model to switch to Opus 4.5. The cost difference is negligible compared to the quality difference.

Use @ to mention files directly in your prompt. Sometimes you need to type @/ to get the full file list to appear.

Shift+Tab twice: Plan mode.

Ctrl+R: Search through prompt history (similar to terminal backsearch).

Esc+Esc: Access /rewind checkpointing. Reverts to a previous checkpoint when Claude messes something up. Can rewind both code and conversation.

!: You can type any bash command in the chat by prefixing your message with !.

Useful Mac shortcuts:

You can often ask Claude to do things you think you have to do manually. Changing default permissions, configuration, anything file-related.

Get in the mindset:just ask Claude. It knows how to do things like creating custom commands (it will search the web and figure it out if it doesn't know).

I often don't even have an IDE open for a repo anymore. I have 12 terminals open at once, actively working from on 1-8 at any given time. Typically 2 per project: one for context management or Ralph, one for active multithreading.

Making real progress in 4 projects at once requires the projects to be more execution than thinking. And I have to be locked in off a Celsius and a pack of Zyns (metaphorically, I don't consume either. Just hard drugs like life).

The natural instinct is to use git worktrees to isolate parallel work.

But hammering the same branch is the best approach when running multiple instances. For speed and simplicity. In practice if you do this right you'll rarely need to use worktrees. Armin agrees. So does Pete.

Think in terms of the "blast radius" of one of your terminals. Evaluate the scope of your changes prior to sending your prompt. If it overlaps with another instance, you should be getting Claude to do it in that instance. You'll find that it's truly rare that this mindset doesn't work.

Worst case if there are errors or you miscalculated, you can always revert or fix it. The cost of the rare times this happens is worth it.

Our /commit-smart command helps to make contextual commits. It only commits files that the Claude Code instance touched which allows me to revert a specific change without losing unrelated work.

For solo projects I just push to main directly. When working with others

1. if it's one person I'll have a branch called silen which I periodically create a PR for and merge in, or
2. if it's multiple collaborators I'll create branches and check out the Claude instances on that branch, and
3. if it's a more established repo I'll create a second worktree, and have two terminals associated with two different branches.

Another tip is when I have one session doing something like a refactor but I already have your next prompt typed out for a feature add, you can do !sleep 600 in that second instance and then send in your prompt.

The default /init command analyzes your project and generates a starter configuration. Our /setup-repo command goes further to configure your repo in the first place. It includes best practices (also referencing the /init command) for agentic repos, and interviews you for what you need.

Generally, what you include should be driven by pain. Outside of the basic template that /setup-repo gives you:

Great prompting and guidelines help most. UI is hard to explain and difficult to verify.

I found giving access to take screenshots of the UI was slow and imperfect but it's possible this won't be the case a month down the line.

The interactions with the books and podcasts sections on my website took forever. Human judgment, screenshots, explaining, and organic coding.

Drag screenshots into chat.

Pete mentions that at least 50% of his prompts contain screenshots. I use them sparingly. They can be powerful for UI fixes but are slow and imperfect for iterative frontend work.

I like to generate UIs or visual components in Nano Banana Pro and paste the screenshot to get Claude to generate it.

Verifiability is straightforward here. Some advice:

I'm just starting to experiment with this. I've given Claude access to a VM with an A100 to see what experiments it performs.

Karpathy shared his experience:

So far it seems to me that models are able to grok pretty much anything and are great partners to think through things. Paste in a document about your hypothesis, and they can help you execute on it.

Have fun. But remember, extraordinary claims require extraordinary evidence. Avoid getting one shotted into psychosis land.

Claude Code is great for generating IPYNBs and using a large prompt for learning concepts. But when you're sitting there trying to grok things and want to stay in the loop, Cursor's Cmd+K and chat is best (along with ChatGPT).

On Mac, run caffeinate -dimsu to prevent your laptop from sleeping while Claude works. Start a task, close your laptop, go places.

When you paste something longer, Claude simplifies this in the terminal to [Pasted text #x +x lines]. 9/10 times I like this.

The other 10% here's my workaround: I send a bash command like !sleep 100, then I click enter on my prompt, then the up arrow. This will bring the fully expanded queued prompt into your terminal.

We used to have shiny rainbow text whenever we typed 'ultrathink' which would maximize Claude's thinking.

But it's 'on' by default now.

Unfortunately, for almost everything, Ralph is more of a pain to get working than it's worth. Sorry to disappoint the hype.

Ralph basically puts a bunch of Claude codes into a loop and coordinates them using a prd.json and progress.txt. I do sometimes use it when I'm starting a new project.

If you are brave enough to give it a shot, the /setup-ralph command sets up all the Ralph files for you.

Ralph exits early when it detects keywords like "done", "complete", or "finished" in your progress files. Use status terms like PASSED/PENDING instead to avoid premature exits.

Also, Claude can confuse itself into thinking it's advising about Ralph rather than being the agent. Make your PROMPT.md direct: "You are the agent. Do the work."

The key to Ralph: keep an accompanying chat open to guide it and check on progress. Ralph runs in the background; you steer from the side. When starting Ralph, I tell my monitoring chat: "Sleep for 30 seconds, then check if Ralph is executing correctly. Repeat 3 times." This catches early issues before you walk away.

Use vibetunnel.sh with Tailscale to code from your phone and you can run Claude Code on your phone from anywhere.

Custom Subagents are spawned instances that don't pollute your main context but can report back directly to it. I have a custom agents for different types of deep research, and a claude-critic agent for opinions. A friend uses a /f command in a subagent to find relevant files and context without cluttering the main agent.

Use cases: large refactoring (subagent for each logical group of files), code review pipelines (style-checker, security-scanner, test-coverage in parallel), research tasks (explore subagent for unfamiliar codebases).

Hooks execute on specific events (tool call, stop, etc.). I've experimented but nothing has stuck. One use case: running Prettier on .ts files after Claude finishes. A good mental model for when to use hooks: a) specific things you do at a certain point (like after chat) often, and b) it can be done through a bash command.

I've heard about running a "Do more" prompt when Claude finishes via the Stop hook to keep it working for hours.

Skills are folders where the LLM decides when or what to load. Files with scripts, prompts, etc. They' a superset of commands, coming with their own executable code and many potential prompt files. Use cases: code review standards, commit message conventions, database query patterns, API documentation formats. Vercel's React best practices skill is worth installing for React/Next.js projects.

MCP (Model Context Protocol) lets Claude talk to external services directly. Connect to GitHub, Slack, databases, issue trackers. Use cases: implement features from JIRA issues, query PostgreSQL directly, integrate Figma designs, draft Gmail responses, summarize Slack threads. Run /mcp to see your connections.

Here's a guide that goes more in depth on these. I think you should get started without reading it. If you feel something is missing or you try to close the loop some other way and it doesn't work, come back and read it.

The -p flag runs Claude Code in headless mode. It runs your prompt and outputs the result without entering the interactive interface. This means you can script it, pipe output to other tools, chain it with bash commands, integrate into automated workflows.

People use this for automatic PR reviews, automatic support ticket responses, documentation updates. All logged and auditable.

The people whose work informed this guide, and resources worth exploring:

All commands I recommend, organized by type and frequency.

Custom commands (gists linked):