Why is Claude Code So Popular?

--- type: transcript date: 2026-01-19 youtube_id: UY8MIAiUmDo --- # Transcript: Why is Claude Code So Popular? In this video, I wanted to go over why Claude Code is so popular. Now, a lot of people know the stories of LLM. They're increasing in capabilities, the abilities of all of these models over time. They're just getting better and better. There's an exponential curve in terms of the capabilities of what they can do, whether it's within software engineering or within a whole host of other disciplines. But even if we just put the LLM aside for a moment, I think there are a number of interesting aspects of what makes Claude Code as popular as it is. First up, I want to quickly touch on a tweet from Boris Journey, who was the creator of Claude Code. One of the things that he mentioned is there is no one correct way to use Claude Code. We intentionally built it in a way that you can use it, customize it, and hack it however you want. Each person on the Claude Code team uses it very differently. Now, there are a lot of different things that are out there in terms of different skills or sub agents or processes or hooks that you can leverage to have Claude Code do interesting things. I've covered some of those on the channel, like the concepts around continual learning or having Claude run autonomously. There are a number of different strategies to have it do novel things like that. But the interesting thing with cloud code is you can really use it across a ton of different form factors. You can use it for coding. You can use it as a coding agent. You can use it for automations or you can use it for a ton of different things. You could use it for a diary. You could use this for a blog writer. You can compartmentalize all of the different things that you think about and can offload to an AI agent. Now, you can use cloud code for that or you can use co-work. It's very flexible. It's very low-level and that's very intentional in how they've communicated and Boris in particular how he thought about building this. Now, the one thing that I want to touch on, and I've been thinking about this a little bit more lately, is a lot of the core tools that are built within cloud code. Again, if we take the LLM outside of this, a lot of the tools that are equipped to it, it's not like there's a hundred different tools and a complicated orchestration process to make this work as good as it is. It's actually quite simple. I wanted to touch on the Lindy effect. Now, this is a term that was popularized by Nim Tab within the book Antifragile. This is a book that I read many years ago. There's a ton of interesting ideas with it, but at its core, one of the core ideas with the Lindy effect is the longer something non-p perishable has survived, the longer its remaining life expectancy. In other words, what has been around is more likely to continue to be around. So, if you think about a book that's been in print for 40 years, you can expect it to be in print for another 40 years. Or same thing, if a book has been in print for 2,000 years, you can expect it to be in print for another 2,000 years. every year without extinction doubles the additional life expectancy. And what got me thinking about the Lindy effect was this idea of what are AI coding tools actually built on. Now let's quickly go through the numbers. So we have Unix that came out in 1969 57 years ago. We had pipes 53 years ago. Gp 53 years ago said 52 years ago 49 years ago bash 37 years ago. The idea with this is all of these different primitive building blocks is what cloud code is really built on. Cloud code builds on top of all of these different methods that have been around for decades. Next up, text files. It seems too simple to be true. 54 years old. File system 1970, 54 years old. Markdown 2004, 22 years old. All of these different things are the core foundation of how cloud works. Whether you're a computer scientist or not, you're going to be able to understand these things and it's going to feel intuitive. And not to mention the performance that you can get by just using GP, bash, all of these core Unix commands. These have been built on and fortified and aren't built on things that have a shaky foundation. One quick aside with all of this is oftent times we see all of these different vulnerabilities that come up. These vulnerabilities are never within bash or grap. One of the thing with a lot of technology today is a lot of the vulnerabilities that come up are on all of these different abstractions, all of these different frameworks. It's not these core methods that have been durable and tried and true over time. The same thing can be said about SQL. SQL has a very strong Lindy effect. So it's been around for decades is going to probably continue to be around for decades. And cloud code's foundation effectively that full stack that is built on top of markdown text files the file system Unix all of these different layers have survived basically 50 years of change and the idea of the Lindy effect this is going to compound into the future. Now if we just take a look at the competition what do other AI coding tools look like and what are they built on top of? VS Code 11 years old came out in 2015. Cursor came out three years ago. This is a fork of VS Code. They built a ton of amazing AI capabilities on top. But if we look at the history of this, if you look at VS Code or Cursor, these abstractions and frameworks and interactive interfaces are very far from some of the core pieces and the building block that are within cloud code. And this is not to say that something new is bad or anything like that. It's just that the compounding effects of all that you build on top of can be a really good foundation just to carry you into the future. And I think it is still an open question in terms of where VS Code will be, where cursor will be as coding is changing as dramatically as it is in this current moment. If we take a look at cloud code, it's one year old. But the thing with cloud code is it's built on that foundation that I just went through. Every single layer has decades of proven stability. is not built on top of new coding languages and new frameworks like some of these other idees. It's built on top of really just primitive methods that have been around for decades. Why did Anthropic make this bet? It actually came out as an experiment from Boris Journey. It came out as a side project as many great things do. Anthropic's product principle is do the simple thing first. And if you think about even that principle in of itself, if we go back to Unix or if we even touch on things like functional programming and the idea of having a function that does one thing really well, one of the ways that I heard in an interview Boris described cloud code is it just felt better in terms of the agentic search and some of the different principles that actually went into things. There wasn't this complicated rag system of keeping track of all of the different vectors and having to manage all of that different complexity. is just using Grep and Glob and all of these things that have been around for an awful long time. And these things just work. They work. They've been around. They're tried and true. There's a reason why they didn't stay in 1970 and they continued on to 2026. So, if we take a look at some of the Cloud Code tools, now these aren't all of them. There's not actually that many, but the core building blocks of the main tools that you'll see Cloud Code run again and again are the tools that have been around for an awful long time. But the idea with this is if these things weren't effective, they wouldn't have lasted for 50 years. They wouldn't have that Lindy effect, right? They would have stayed in the dust bin of history if these things weren't as effective as they were. Now, the other thing that I quite liked about the creator is he's actually a very humble guy. And one of the ways that I've heard him in one or two interviews describe Claude code is the interface that they built is just built on the foundation of we don't actually know what coding is going to look like. If we take the models and we go 1 2 3 years out, what is coding actually going to look like? If we take a snapshot of today, I don't have any idea what coding is going to look like. Am I going to be talking into a microphone and it's just going to be spinning out this wild architecture? I have no idea. And I don't think anyone can claim that they actually know what that is going to look like in even just a few years. This just goes to show how quickly things are changing. If you have a very strong foundation that isn't based on something that might change tomorrow or might break or might have a security vulnerability, it might actually play in your favor in quite a big way. Now, next, some of the other benefits of Unix commands. One, they're very strongly represented within the trading data of models. You could have a very small 8 billion parameter model on your own computer and it's going to know these commands quite well. Further, if you put this on a state-of-the-art model like Claude Opus 4.5 or GPT 5.2 two or whatever, it's going to absolutely know how to use these things. And when you pass in the right context and right instructions, this in combination with that, you can get pretty powerful results. If we take the Unix philosophy of having a program do one thing really well. I think these principles they're clearly represented within cloud code. But I think within some of the new techniques of how we're leveraging cloud code or skills, sub aents, MCPs, file system, all of these things as well can be built with those same principles. In my opinion, skills, sub aents, and MCPs, some of the best versions of all of these things are probably going to be represented in the same type of Unix philosophy. Have one skill that does something really well. Have a sub agent that does something really well. Have one MCP that does something really well. We don't need to try and squeeze everything into one tool into one skill into one agent, so to speak. Now is the big paradigm shift in 2026 and years following. Cloud code is really the first glimpse into agentic systems working really well. We have it within SDKs where we have vertical integrated applications. We have it as an exceptionally popular coding tool. Everyone from my 7-year-old through to people that have never coded before a day in their life are able to be productive with cloud code. And that just speaks to both its capability, but I think it's intuitive design in of itself. We're entering an interesting era where there's going to be a little bit of a mix where we now have programmers that are leveraging these tools and we have non-programmers leveraging these tools, but now we also have agents that are going to want to leverage these tools as well. If we go to VS Code or some of these other editors that are out there, one of the things that a lot of IDE have in common is they're designed for humans. That was the way that we used to code. We used to be in these IDEs. We had to have syntax highlighting. We'd have all of these different llinters and errors and warning signs and extensions and all of these different tips and tricks in terms of actually navigating line by line and tabbing through our codebase and writing things out manually. But now we're moving to an era where agents are actually writing a lot of our code. And in the interim, it's going to be agents and humans. We really need an interface that a human can use as well as an agent can use. This is what cloud code is. an agent can use it really well as well as a human. And I think this is in part why they're really well positioned for 2026. And one of the interesting pieces of this is actually the story around file systems. The emerging consensus at least right now, and this might not be the case in 3 months, but it's the idea of bash is all you need and file systems are all you need. They're token efficient. LLMs know how to use them. They're tried and true. And like I mentioned, these have been around for a very long time. When I was researching this video, one thing that I found amazing was if we look at some of these different companies that make storage devices. If we look at SanDisk, this is up over a,000% within a year. If we look at Western Digital, 350% in one year. If we look at Seagate, 234% within one year. And the idea with this is all of this data that we're generating, it has to live somewhere. Now that we have AI agents, in addition to humans leveraging all of these different applications that are out there, we're just creating an enormous amount of data and storage that's required. Why are file systems a win for agents? They're token efficient. You don't need to worry about migrations or schemas and setting up databases and understanding where the data is, where the tables are, structuring that, having to think about the structure. It's very easy to update and change a file system and find exactly what you need very quickly, very efficiently, like we've leveraged for decades. That's potentially a really good way to access information. Now, additionally, it's a familiar mental model. Everyone knows what a folder and file is, programmers, non-programmers alike. And lastly, they're portable. They're malleable. You can put these on a hard drive, and you can also read through these. And a lot of what an AI agent is generating. You can just read through the files. It's not within a vector database. It's not in this embedding where you have to do these machinations to actually get information out of them. You can just read it. It's text. It's markdown. It's all of these files that an AI agent can read or a human alike can read as well. One of the big benefits of folders is it's a really great mental model. So if we look at SQL or MongoDB or you name the different database dour that you enjoy, most people don't know those things. The great thing with this is with folders, skills, sub aents, it's just text. Anyone can write it out. Actually developers might not even be the best ones to write out the best skills, write out the best agents. It might actually be someone like a teacher or professor that's just used to conveying different information and writing very clear instructions for students to follow, for instance. But all in all, developers and non-developers understand directories. Next up, simple interfaces win. We go back to Google when it was released. ChatgPT, Claude Code. The thing with all of these different interfaces, they're simple, they're intuitive, and they get out of your way. They're very clear what all of them do. Now, I know a lot of people probably are going to have some resistance to some of what I said within the video. They're probably thinking, "Yes, cursor is better DX. VS Code is better DX." Whatever IDE that you leverage. I'm sure the form factor is great because you have all of the different key bindings, you have the extensions, you have that familiarity of going into a system, you know how it works. And the switching cost to something like Cloud Code is definitely non-trivial. It took me probably hundreds of hours before I was convinced that, hey, this is probably the most productive place for me actually building and working on applications. The only thing that I want to suggest is some of these tools have only been out for a little bit of time. A lot of people are really experimenting with the form factor. A lot of companies are building amazing products, but I think time will be the tell of whether those different tools in their current instantiation will be the ones that we're going to be using in 2 3 4 5 years, so on and so forth. I'd argue that over the next 10 years, there's probably a very unlikely chance that those are going to be the tools that endure over the coming decades. The IDE and its current instantiation is very likely not going to be the form factor that most programmers or developers are going to be using in say 5 years. I already touched on this a little bit, but LMS are really good at bash. They're really good at SQL. And sometimes when you think about things that are within the training data, the benefit of this, when you think about actually building an application or an agent, if you build it on top of something that's been around for a very long time, there might be an 8 billion parameter model that could handle this really well. And you might be able to have an experience that runs at a,000 or 2,000 tokens per second because it's built on these foundations where the models know exactly how to use some of these things very well. Okay, so I've done a ton of videos on cloud code. I'm probably going to continue on some concepts over the coming weeks if you're interested. What I encourage people to do is learn cloud code. Once you learn how to use cloud code, use cloud code to build agents. And this is one that I don't hear a lot of people touch on is if you learn how to use cloud code is by an essence in seeing how cloud code works. You're going to understand intuitively how an agent works. just watching how it runs, learning what methods it's using, learning what tools it's leveraging. You can leverage that same knowledge that honestly you're probably just going to be picking up passively from watching Cloud Code and leverage that in like the Cloud Agents SDK or Deep Agents or the Versell AI SDK, whatever it is, you can leverage those same patterns that you see within Cloud Code or similar harnesses and you can build applications with that. If you have an idea for an AI agent, just watching these systems, in my opinion, those are going to be the best teacher to actually show you how to build good agents yourself. Learn from the best that's out there, things like cloud code or similar products and take those lessons and apply them. If you're actually building agents, same pattern, same composability. You can leverage these same skills, cloudMD, you can build sub agents with context and you can teach it when it makes mistakes. And all of these same patterns can be applied within production applications as well. And one of the things that I encourage people to do is just talk to claw code. Tell it to build skills. If there's something you see it doing again and again, maybe it's making the same mistake. Mistakes aren't necessarily a bad thing. You can tell it to learn from the mistakes and not repeat itself. Now, if you see something that you want to have it do every single time, you can put a claw.md within the root of your directory of your project. You can also have global commands within the cloud. MD and every mistake that you see you can use it as a learning opportunity and you can say hey I notice you keep creating a button that isn't within the application's context always reference the button and you can have that within a skill and you could build that skill to be something like a front-end skill or a front-end developer skill you can start to compartmentalize okay based in this application here's the design system here's where to find the different files all of the different things just like you tell a different employee you can direct and reference all of that different contextual awareness when appropriate. And all that you have to do is you can just tell Claude to do it. You don't have to go and even touch the file system. All in all, in a world where no one knows what the form factor is going to be, bet on something that composes with everything else. That's it for this video. If you found this video useful, please like, comment, share, and subscribe. Otherwise, until the next