DEV Community: ctrlshiftbryan

The Art and Zen of Claude Code: Why Simplicity Always Wins

ctrlshiftbryan — Sun, 15 Jun 2025 16:47:21 +0000

I've been using AI coding assistants for a while now. Started with Copilot, moved to Cursor, tried Roo, experimented with Windsurf. They all promised to revolutionize how we code. But after months of fighting with configurations, learning shortcuts, and debugging integrations, I found myself spending more time managing the tools than actually coding.

Then I tried Claude Code. And everything changed.

The Beauty of Simplicity

Here's what nobody tells you about those VSCode extensions and forks: they're adding layers of complexity that often get in your way. With Cursor and Roo, you're constantly dealing with accepting changes, learning their specific diff views, remembering keyboard shortcuts, figuring out their context management and code indexing.

I remember spending an entire Saturday just trying to understand how Cursor's context indexing worked. Was it including the right files? Why wasn't it seeing my updated code? The invisible complexity was killing my productivity.

Claude Code strips all that away. It's literally just you writing a prompt. That's it.

No diffs to accept. No shortcuts to memorize. No mysterious context windows. Just write what you want and Claude Code handles it. I still use VSCode when I want to edit files directly, or I'll write longer prompts in markdown files and tell Claude to read them. But the tool itself? It gets out of the way.

Battle-Tested Tools vs Shiny New Things

One of my biggest frustrations with VSCode extensions was dealing with MCPs (Model Context Protocol integrations). Take the Postgres MCP for example. I spent hours trying to get it working with Cursor. It needed specific Node settings, couldn't read my existing .env files, required npx runner configurations. Even when it worked, it felt fragile.

With Claude Code? It just started using psql when it needed to. You know, the tool that's been around for decades and just works. Same with GitHub integration. While I was fumbling with GitHub MCPs in other tools, Claude Code just uses the gh CLI. These aren't sexy new abstractions. They're boring, reliable tools that have been refined by thousands of developers over years.

The CI Debugging Story That Sold Me

Here's the moment I knew I was done with VSCode extensions. I had this infuriating CI issue where tests were passing locally but failing in GitHub Actions. Spent hours with Cursor trying to debug it. Even with their massive context windows, I was manually copying logs back and forth, searching for working GitHub integrations, getting nowhere.

This happened to be happening on the day Claude 4 was announced and Claude Code hit 1.0. I knew it was powerful but I had spent $30 in API tokens when I tried it a few weeks earlier with Claude 3.7 and decided to put exploring it on hold until I got better at prompting or the price was more predictable. Fast forward to picking it back up, within 30 minutes & Claude 4, it had solved the issue.

How? It used gh CLI to pull the actual CI logs, ran the tests locally with the same environment variables, compared the outputs side by side, and identified a timezone difference that only showed up in CI. No manual copying. No broken integrations. Just standard CLI tools doing what they do best.

Manual Context Management: The Feature Nobody Talks About

Here's something I've discovered that completely changed how I work: manual context management is actually better than automatic. I know that sounds counterintuitive when everyone's bragging about million-token context windows, but hear me out.

With Claude Code, I decide when to start fresh sessions and when to continue. I use the compact command to manage context. I'm writing technical plans to end the session and start a new one. Most importantly, I'm breaking big problems down into small, manageable pieces of work. This isn't some new AI technique. It's the same skill good engineers have been honing for decades. The difference is Claude Code lets me apply it naturally giving me the minimal tools I need to do the job instead of fighting against automatic context management.

It reminds me of the golden days of Twitter when people had to craft their tweets into a character limit. There was a beauty to that constraint. You had to make each word and even letter count. The same principle applies here. When you're conscious of your context, you communicate more clearly. You think before you prompt. You get better results. You can do this in other tools, but Claude Code is optimized for it.

The result? I've never hit the MAX context limit. Not once.

Why? Because I'm not dumping my entire codebase into every conversation. I'm having focused discussions with exactly the context needed. When I'm done with one problem, I start fresh with the next. It's like the difference between a cluttered desk where you can't find anything and a clean workspace where you bring out exactly what you need.

This also means each conversation costs less and stays more focused. The AI isn't wading through thousands of irrelevant lines trying or some index to understand what you want. It's laser-focused on the specific problem with the specific context you provided.

The Permission System Is a Killer Feature

When people ask about Claude Code, they often mention "wider CLI permissions" like it's a security concern. They're missing the point entirely. The permission system is one of its best features.

You can run in planning mode where it can't execute anything. Or you can set granular permissions in a session like:

"Bash(gh run list:*)"
"Bash(gh run view:*)"
"Bash(cat:*)"
"Bash(grep:./src/**)"

Or you can go full YOLO mode with --dangerously-skip-permissions when you're in a trusted environment, know it's on track and just need to move fast.

The key is you control it session by session. You're not trusting some opaque system to manage security for you. You know exactly what Claude can and can't do because you set the boundaries.

The Model-Switching Trap

In Cursor, when Claude 3.7 couldn't solve something, I'd switch to Gemini and suddenly it worked. This felt like a feature but was actually a bug. It's like the old days when Chrome would silently fix your broken JavaScript while IE would throw errors. You'd think IE was wrong, but it was actually exposing your bad code.

Model-switching adds layers of non-determinism. Did it work because Gemini understood my prompt? Was my context too big? Too small? You never know what actually fixed it.

With Claude Code, I stick to Claude 4. When something fails, I know it's my prompt that needs work. No model shopping, no uncertainty. Just like how IE forced us to write cleaner JavaScript, using one model forces me to write clearer prompts.

Focus on What Matters: Learning to Prompt

Perhaps the biggest shift was realizing I could stop learning tools and start learning the model and optimize for it. Instead of bouncing between different prompt libraries, techniques for different models, and platform-specific tricks, I'm just reading the official Anthropic docs and getting better at communicating with Claude.

It's remarkable how much better my results got when I stopped fighting with tool interfaces and started focusing on clear, effective prompting.

Predictable Pricing That Actually Makes Sense

With API-based tools, I was constantly anxious about costs. One complex debugging session could spike my bill unexpectedly. With Claude Code, I know I'm spending $100-200 a month. That's it. No surprises. No watching token counters. Just a predictable cost for a tool I use every day.

The Bottom Line

Claude Code isn't trying to reimagine how we code. It's not adding AI-powered diff views or intelligent context management or smart acceptance flows. It's doing something much more radical: it's getting out of the way.

After months of experimenting, I've stopped investigating other tools. I'm not interested in the latest VSCode extension or the newest coding assistant. I have a simple tool that lets me leverage Claude's capabilities without any friction.

Sometimes the best interface is no interface. Sometimes the most powerful feature is simplicity. And sometimes, the future of coding isn't about adding more abstractions. It's about removing them.

If you're tired of fighting with your AI coding tools, maybe it's time to try something simpler. Your future self might thank you.

Have you tried Claude Code? What's been your experience with AI coding assistants? Drop your thoughts in the comments below!

Writing process note: This post was created through an AI-assisted interview process in about 30 minutes. Two years ago this post would have taken me an entire weekend to write. I used Claude to ask me targeted questions about my experience with Claude Code, then worked with it to structure my responses into a cohesive narrative. The opinions and experiences are entirely my own; Claude helped me articulate them clearly and organize them into a readable format.

'let' it be (remix.run)

ctrlshiftbryan — Tue, 30 Nov 2021 12:21:16 +0000

let vs const in remix.run

The Remix.run documentation and source code uses let for everything. This somewhat breaks "convention" and is usually the first thing people notice when learning remix. This is too bad.

Remix.run is an amazing framework. It has the possibility of changing web development in the same way JSX changed templating or graphql changed working with web apis. It truly feels like one of the transformational technologies that simplifies development by removing many of the boilerplate challenges that modern front-end or even static generated sites have introduced like state management, REST/graphql and too many hooks.

What's truly amazing is it does this while getting us back to "foundational web" or "embracing the web platform." I like to think that remix is "old school cool". It's like working in php or a traditional rails app, but in a good way.

Old School cool Joan Jett without her signature black eyeliner (1976) on reddit.

So let's think through the arguments for and against using only let and speculate maybe why the core team made this decision.

ARGUMENT FOR: It forces you to challenge your existing beliefs.

This is my favorite argument for using "let". It doesn't really impact your code. If you zoom out a little bit, it kind of gets you into the mindset that "remix" is going to change the typical way you do things and that's ok.

When starting to develop with remix, I had this same reaction doing full-page post backs using POST. You might feel the same way when using html forms for sending data to the server or not being able to use the DELETE verb when deleting a record. Remix challenges you as a developer to do things different and that's great! This helps weed out developers that are too closed minded.

ARGUMENT FOR: It's controversial. That's good for online engagement.

I'm actually fine with this argument. Again remix is amazing and one of the most important things right now is to make it popular. Let's get people talking about it. Let's Increase the online engagement by taking this technically incorrect opinion or style.

The core team created and maintained React Router and offered best in class React training for years. They have more credibility than they need. They can burn a little bit with a hot take like this. With tech and open source, being technically superior or making better trade offs is not enough, it also has to be massively popular.

ARGUMENT FOR: eslint

If eslint can easily fix this, it can, why bother talking about it? Every developer or team can make their own decision here and just let the auto-formatting handle it. Should this also be an argument against? Maybe it's neither?

ARGUMENT FOR: It's less to type on your keyboard

some cool guy on reddit's keyboard

I love a good keyboard as much as the next guy. But I prefer to use it as little as possible. There's just something about a nice 3 letter combo. Your fingers can type this in about 500 ms. Let the muscle memory take over.

This probably not the best argument, but it certainly feels nice. The type of developer that is upset that you are using let when you should be using const is only going to be even more triggered when they hear this answer. I just hope it doesn't turn them off to remix entirely.

ARGUMENT AGAINST: It doesn't matter. It is a distraction from learning remix.run.

I'm excited about remix.run! I want to evangelize and tell everyone I know. Having to argue about a modern "tabs vs spaces" is a waste of time and energy. Kent says "He just doesn't care enough to challenge it!" I too just don't care! I don't care so much that I want to stop talking about it ever again. Can we get back to remix? The quickest way to do this is to correctly use const/let.

When I first go to a discord I generally look at the pinned messages in the general channel to get started. If the only pinned message in your general channel is this (see above) does that maybe tell you something? Is this really what you want the your first impression about this amazing framework to be?

ARGUMENT AGAINST: It signals the wrong thing to the developer

It might make your feel like you don't know what you are doing. In most react code, almost everything is const. The only time you should see let is if you need to re-assign the value.

Kent C. Dodds 💿

@kentcdodds

Why I prefer `const` over `let` and `var`

The goal is to have less to think about.

23:00 PM - 15 Nov 2016

This is good because when looking for bugs you can focus on 'let' as you scan the code knowing that if something is getting re-assigned it could be the issue as it's not generally something we ever need in React. When we do it could be a sign that there is some complexity that needs to be inspected.

In conclusion

Let's just 'let' it be. Ultimately it's remix core team's choice, obviously. I could see a compromise where the training materials and documentation use let/const properly and the source code uses they 'let' only style, but assuming positive intent we could just go with the "it forces you to challenge your existing beliefs" argument and call it a day.

What ever side of this argument you agree with please go to remix.run and give it a try. I hope you will learn and become as excited about remix as I am!

What about you?

What do you think? Leave your arguments for or against let in the comments below