The Magic of Claude Code

If you've talked to me lately about AI, you've almost certainly been subject to a long soliloquy about the wonders of Claude Code. What started as a tool I ran in parallel with other tools to aid coding has turned into my full-fledged agentic operating system, supporting all kinds of workflows.

Most notably, Obsidian, the tool I use for note-taking. The difference between Obsidian and Notion or Evernote is that all the files are just plain old Markdown files stored on your computer. You can sync, style, and save them, but ultimately, it's still a text file on your hard drive. A few months ago, I realized that this fact made my Obsidian notes and research a particularly interesting target for AI coding tools. What first started with trying to open my vault in Cursor quickly moved to a sort of note-taking operating system that I grew so reliant on, I ended up standing up a server in my house so I could connect via SSH from my phone into my Claude Code + Obsidian setup and take notes, read notes, and think through things on the go.

A few weeks ago, I went on Dan Shipper's AI & I Podcast to wax poetic about my love for this setup. I did a pretty deep dive into the system I use, how it works, why it works, etc. I won't retread all those details—you can read the transcript or listen to the podcast—but I want to talk about a few other things related to Claude Code that I've come to realize since the conversation.

Why is Claude Code special? What makes it better than Cursor?

I've really struggled to answer this question. I'm also not sure it's better than Cursor for all things, but I do think there are a set of fairly exceptional pieces that work together in concert to make me turn to Claude Code whenever I need to build anything these days. Increasingly, that's not even about applying it to existing codebases as much as it's building entirely new things on top of its functionality (more on that in a bit).

So what's the secret? Part of it lies in how Claude Code approaches tools. As a terminal-based application, it trades accessibility for something powerful: native Unix command integration. While I typically avoid long blockquotes, the Unix Philosophy deserves an exception—Doug McIlroy's original formulation captures it perfectly:

The Unix philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978:

1. 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
   2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
   3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
   4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

It was later summarized by Peter H. Salus in A Quarter-Century of Unix (1994):

• • Write programs that do one thing and do it well.
  • Write programs to work together.
  • Write programs to handle text streams, because that is a universal interface.

These fifty-year-old principles are exactly how LLMs want to use tools. If you look at how these models actually use the tools they're given, they are constantly "piping" output to input (albeit using their own fuzziness in between). (As an aside, the Unix | command allows you to string the output from one command into the input of another.) When models fail to weld their tools effectively, it is almost always because the tools are overly complex.

So part one of why Claude Code can be so mind-blowing is that the commands that power Unix happen to be perfectly suited for use by LLMs. This is both because they're simple and also incredibly well-documented, meaning the models had ample source material to teach them the literal ins and outs.

But that still wasn't the whole thing. The other piece was obviously Claude Code's ability to write code initially and, more recently, prose (for me, at least). But while other applications like ChatGPT and Claude can write output, there was something different going on here. Last week, while reading The Pragmatic Engineer's deep dive into how Claude Code is built. The answer was staring me in the face: filesystem access. 

The filesystem changes everything. ChatGPT and Claude in the browser have two fatal flaws: no memory between conversations and a cramped context window. A filesystem solves both. Claude Code writes notes to itself, accumulates knowledge, and keeps running tallies. It has state and memory. It can think beyond a single conversation.

AI Overhang

Back in 2022, when I first played with the GPT-3 API, I said that even if models never got better than they were in that moment, we would still have a decade to discover the use cases. They did get better—reasoning models made tool calling reliable—but the filesystem discovery proves my point.

I bring this up because in the Pragmatic Engineer interview, Boris Cherney, who built the initial version of Claude Code, uses it to describe the aha:

In AI, we talk about “product overhang”, and this is what we discovered with the prototype. Product overhang means that a model is able to do a specific thing, but the product that the AI runs in isn’t built in a way that captures this capability. What I discovered about Claude exploring the filesystem was pure product overhang. The model could already do this, but there wasn’t a product built around this capability!

Again, I'd argue it's filesystem + Unix commands, but the point is that the capability was there in the model just waiting to be woken up, and once it was, we were off to the races. Claude Code works as a blueprint for building reliable agentic systems because it captures model capabilities instead of limiting them through over-engineered interfaces.

Going Beyond Code

I talked about my Claude Code + Obsidian setup, and I've actually taken it a step further by open-sourcing "Claudesidian," which pulls in a bunch of the tools and commands I use in my own Claude Code + Obsidian setup. It also goes beyond that and was a fun experimental ground for me. Most notably, I built an initial upgrade tool so that if changes are made centrally, you can pull them into your own Claudesidian, and the AI will help you check to see if you've made changes to the files being updated and, if so, attempt to smartly merge your changes with the new updates. Both projects follow the same Unix philosophy principles—simple, composable tools that do one thing well and work together. This is the kind of stuff that Claude Code makes possible, and why it's so exciting for me as a new way of building applications.

Speaking of which, one I'm not quite ready to release, but hopefully will be soon, is something I've been calling "Inbox Magic," though I'll surely come up with a better name. It's a Claude Code repo with access to a set of Gmail tools and a whole bunch of prompts and commands to effectively start operating like your own email EA. Right now, the functionality is fairly simple: it can obviously run searches or send emails on your behalf, but it can also do things like triage and actually run a whole training run on how you sound over email so it can more effectively draft emails for you. While Claude Code and ChatGPT both have access to my emails, they mostly grab one or two at a time. This system, because it can write things out to files and do lots of other fancy tricks, can perform a task like “find every single travel-related email in my inbox and use that to build a profile of my travel habits that I can use as a prompt to help ChatGPT/Claude do travel research that's actually aligned with my preferences.” Anyway, more on this soon, and if it's something you want to try out, ping me with your GitHub username, and as soon as I feel like I have something ready to test, I'll happily share it.

A Few Takeaways

While I generally shy away from conclusions, I think there are a few here worth reiterating.

1. The filesystem is a great tool to get around the lack of memory and state in LLMs and should be used more often.
2. If you're trying to get tool calling working, focus on following the Unix philosophy.
3. Claude Code represents a blueprint for future agentic systems—filesystem + Unix philosophy should be the template for building reliable, debuggable AI agents rather than complex multi-agent stuff that's floating around today. Tactically, this means when you’re building tool calling into your own projects, keeping them simple and letting the main model thread “pipe” them is the key. (As an aside, one big problem that needs to be solved in all these agents/chatbots is the ability to pipe things without it going through the context window.)
4. Anyone who can't find use cases for LLMs isn't trying hard enough