How I Use Every Claude Code Feature

But in general I still don’t really use MCP. Agents are just so good at solving problems themselves. I wish MCP would mostly focus at the auth part instead of the tool part. Getting an agent access to an API with credentials usually gives them enough power to solve problems on their own.

[1]: https://x.com/mitsuhiko/status/1984756813850374578?s=46

There is no customer advantage to developing cheap and fast if the delivered product isn't well conceived from a current and future customer-needs perspective, and a quickly shipped product full of bugs isn't going to help anyone.

I think the same goes for AI in general - CEOs are salivating over adopting "AI" (which people like Altman and Amodei are telling them will be human level tomorrow, or yesterday in the case of Amodei), and using it to reduce employee head count, but the technology is nowhere near the human level needed to actually benefit customers. An "AI" (i.e. LLM) customer service agent/chatbot is just going to piss off customers.

So if youre building your own agent, this would be a directory of markdown documents with headers that you tell the agent to scan so that its aware of them, and then if it thinks they could be useful it can choose to read all the instructions into its context? Is it any more than that?

I guess I dont understand how this isnt just RAG with an index you make the agent aware of?

So now you need to get CC to understand _how_ to do that for various tools in a way that's context efficient, because otherwise you're relying on either potentially outdated knowledge that Claude has built in (leading to errors b/c CC doesn't know about recent versions) or chucking the entirety of a man page into your default context (inefficent).

What the Skill files do is then separate the when from the how.

Consider the git cli.

The skill file has a couple of sentences on when to use the git cli and then a much longer section on how it's supposed to be used, and the "how" section isn't loaded until you actually need it.

I've got skills for stuff like invoking the native screenshot CLI tool on the Mac, for calling a custom shell script that uses the github API to download and pull in screenshots from issues (b/c the cli doesn't know how to do this), for accessing separate APIs for data, etc.

I think if it literally as a collection of .md files and scripts to help perform some set of actions. I'm excited for it not really as a "new thing" (as mentioned in the post) but as effectively an endorsement for this pattern of agent-data interaction.

Codex writes higher quality code, but is slower and less feature rich. I imagine this will change within months. The jury is still out. Exciting times!

If you are using literally any of Claude Code’s features the experience isn’t close, and regardless of model preference (Claude is my least favorite model by far) you should probably use Claude code. It’s just a much more extensible product for teams.

It's much easier to review larger changes when you've aligned on a Claude generated plan up front.

It is why I am a bit puzzled by the people who use an LLM to generate code in anything other than a "tightly scoped" fashion (boilerplate, throwaway code, standalone script, single file, or at the function level). I'm not sure how that makes your job later on any easier if you have even a worse mental model of the code because you didn't even write it. And debugging is almost usually more tedious than writing code, so you've traded off the fun/easy part for a more difficult one. Seems like a faustian deal.

Part of it is the snappy more minimal UX but also just pure efficacy seems consistently better. Claude does its best work in CC. I'm sure the same is true of Codex.

Really, the interface isn't a meaningful part of it. I also like cmd-L, but claude just does better at writing code.

...also, it's nice that Anthropic is just focusing on making cool stuff (like skills), while the folk from cursor are... I dunno. Whatever it is they're doing with cursor 2.0 :shrug:

> I select the text and Cmd-L, saying "fix this part, it's broken like this

This flow works well.

I've been coding seriously for about 15 years. No single tool has changed how I code more than claude code and I'm including non-"AI" tooling/services. This sounds like I'm shilling but I am not affiliated. It's played a large part in injecting my passion back into building stuff.

If theres enough interest, I might replicate some examples in an open source project.

This is basically a "thinking tax".

If you don't want to think and offload it to llm they burn through a lot of tokens to implement in a non-efficient way something you could often do in 10 lines if you though about it for a few minutes.

It wasn't possible before for me to do any of this at this kind of scale. Before, getting stuck on a bug could mean hours, days, or maybe even weeks of debugging. I never made the kind of progress I wanted before.

Many of the things I want, do already exist, but are often older, not as efficient or flexible as they could be, or just plain _look_ dated.

But now I can pump out react/shadcn frontends easily, generate apis, and get going relatively quickly. It's still not pure magic. I'm still hitting issues and such, but they are not these demotivating, project-ending, roadblocks anymore.

I can now move at a speed that matches the ideas I have.

I am giving up something to achieve that, by allowing AI to take control so much, but it's a trade that seems worth it.

A sibling comment on hooks mentions some approaches. You could also try leveraging the UserPromptSubmit hook to do some prompt analysis and force relevant skill activation.

At the moment though I also code on and off with an agent. I’m not ready or willing to only vibe code my projects. For one is the fact that I had tons of examples where the agent gaslighted me only to turn around at the last stage. And in some cases the code output was to result focused and didn’t think about the broader general usage. And sure that’s in part because I hold it wrong. Don’t specify 10million markdown files etc. But it’s a feedback loop system. If I don’t trust the results I don’t jump in deeper. And I feel a lot of developers have no issue with jumping ever deeper. Write MCPs now CLIs and describe projects with custom markdown files. But I think we really need both camps. Otherwise we don’t move forward.

Latest version from 2 momths ago, >4700 stars on GitHub

0: https://github.com/whyisdifficult/jiratui

You’ll also end up dealing with merge conflicts if you haven’t carefully split the work or modularized the code.

The people who just copy paste output from ai and ship it as a blog post however, deserve significant condemnation for that.

Didn’t realize you were forced to read this?

> Feels disrespectful to your readers

I didn’t feel disrespected—I felt so respected I read the whole thing.

Fun fact, a large chunk of context is reserved for compaction. When you are shown that you have "0% context remaining," it's actually like 30% remaining that's reserved for compaction.

And yet, for some reason I feel like 50% of the time, compaction fails because it runs out of context or hits (non-rate) API limits.