It has been almost 6 months now since I first started using Claude Code (CC from here on). Until then I had heard so much about CC, especially how CC is so much better than GitHub Copilot. GitHub Copilot was already quite impressive for me, and now you are telling me there is something even better? I was very hesitant to use CC, since CC requires either a Claude subscription or paid API usage. But boy, so much has happened in the past 6 months!
The first encounter
Back in March, by some chance and luck, I was able to attend 2 coding agent workshops, one by each of the 2 leading AI labs: OpenAI and Anthropic. And yes, those were the workshops on Codex and CC. To say that I was mind blown is an understatement. For me as a developer, they were a tool that could finally free me of the “coding burden” and let me focus solely on the project itself. Suddenly, for the first time ever, I could just do things without the need to first figure out a framework, a language, or even the best practices. Now of course in hindsight that is not completely true (which I will explain later), but at that time, with generous credit limits during the workshops, I was able to one-shot a few “demo” apps. I think for a moment there I truly understood how powerful these LLMs have become. And I knew that it was something I wanted to be part of.
Fresh from the workshops, I sat down and read up on some comparisons of the coding tools online. In the end I decided to focus on CC, purely because CC was the OG coding agent at that time. So I went and bought a Claude Pro subscription, and with that my journey with “agentic AI” began. Here I want to break away from my other blog posts about my projects, and focus a little bit on what happened behind the scenes from my perspective, and give some thoughts that might be useful to whoever is reading this.
Before I continue, just for context, I am not a complete newbie in this field. I had worked with LLMs before, but my work was mainly on single LLM calls or chains of multiple LLM calls using structured output, e.g. JSON output. At that time my next step was to integrate “reasoning” mode into my work. But boy, was I not prepared to realize how far behind I was compared to the SOTA, and that people were already moving towards the next level of abstraction: agent harnesses, systems with state management and tool use integrated.
The usage limit paranoia
Now back to the main timeline, so where was I? Ah yes, I had just subscribed to the Claude Pro plan and now I had access to CC. At first, for some reason, I was so paranoid about the usage. What I mean is that I was mainly using Sonnet, because Opus would literally eat up my 5hr limit in like an hour or so. To be fair, I think Anthropic really had compute problems back then, plus probably some bugs in CC that caused the high token usage. Compared to then, I can now get way more Opus usage out of the 5hr limit. And ironically, because of this paranoia, the very first thing I did with CC, besides creating the statusline, was… as you can probably guess, a dashboard to track token usage! I think I spent a good amount of time on that, especially making sure that the information was accurate and that it looked fancy. Looking back, I can tell you right now that it was really a complete waste of time. Sure, I got to see “hey, I used 1 billion tokens!” But surely there are more useful things I can do with CC? Also, there are probably a million such dashboards online right now, so if you are reading this, DO NOT BUILD A TOKEN USAGE DASHBOARD, USE AN AVAILABLE ONE! (#LESSON-1) But at least I learned so much about how CC stores its logs and what the CC user-level file structure looks like. To this day I am still amazed at how much you can configure CC, and now with the introduction of mods, you can really make CC “your own”.
The code tsunami
One other crucial thing I learned from that dashboard project is the amount of code CC can generate. At first I was really reading every single line of code and every test generated. IT WAS TORTURE!!! The amount of mental “willpower” needed to go through that code is just… not sustainable. Looking back, I think the biggest issue is that everything was generated so fast and from scratch that you really needed to understand EVERY part of the code. Before, since one could not write so much code, one would probably use some library or framework where part of the code has been abstracted away, so that you can just assume it works. But now, with CC generating all the code, there is no way around this. Sure, you can ask CC to use libraries or frameworks, but then CC will very quickly start using new “established” ones that you have never heard of (let’s face it, you cannot really know every available coding library or framework), and you would then need to learn something new again. Basically, all of this drains your energy, and ironically it does not free you from the “coding burden”, but rather just shifts it to become “technical debt” (#LESSON-2). In the end you would just end up accepting all the code generated by CC WITHOUT READING THE CODE, as long as it runs and does what you want it to do, and as long as it passes all the tests, which it will, since CC wrote those tests in the first place. I believe this is still a very big open challenge yet to be solved: how do we properly validate the generated code without much human intervention? In my opinion, writing more tests is not the solution, because of how easily CC can generate and modify code. The solution is writing more behavioral tests that validate the feature functionality of the written code. Another aspect is code review, which is the next step after writing the tests, before things get real. And here lies the biggest dilemma. If you do not read the code generated by CC, how do you review the code changes then? Use more agents to review the code? But who then reviews the review agents? Use more agents again??? Surely there is a recursion limit here =D
The addiction
After the first few weeks or so, I think I got slightly addicted. Addicted? Yes. I would keep looking at my Claude usage limit and make sure that I hit the weekly limit, because hey, I paid for it. Every week I would somehow feel agitated because I didn’t hit the usage limit. So what happened was that I kept building random projects, asking Claude what to build and asking Claude to build it in CC. Sure, it is a good “exercise” to understand and learn how to use CC, but I think it was not healthy, because at some point I was doing it just for the sake of doing it. And it felt good looking at all that code being generated and running. Somewhere in my mind I was thinking “oh wow, I am doing so much”, and it felt really good, even though I was not 100% sure what the code was doing, because at some point you just cannot read all the code (as mentioned previously). Basically a form of addiction! Yikes! But now, after the first “burst” of euphoria, I have calmed down a bit and focus more on the project itself, because at the end of the day it will always be quality over quantity. (#LESSON-3)
The portfolio projects
Once I got over the initial hype, I started consolidating my effort into “portfolio” projects. These are projects that I can build by myself and use to say to others: hey, look what I’ve got here! When choosing these projects, I really asked myself which tools and frameworks I already knew, and from there Claude helped to narrow it down to the 4 portfolio projects that I currently have: mcp-cassette, pr-compliance-gate, mlops-incident-commander and presidio-compliance-stack. While they might look a little spread out, they actually have 1 thing in common: they are built with agentic AI in mind. They also allow me to learn more about agentic AI systems, especially how to build them. Currently they are all built and working, but not 100% as I intend them to be. I realised quite quickly that while CC excels at generating code, CC cannot read your mind. CC only knows what you have told it about (#LESSON-4). Being able to clearly articulate and describe what you want to CC is surprisingly a lot harder than it looks. I guess if you have ever worked with clients or customers, you will know this feeling. One of the approaches I see people taking to address this is “spec-driven” development. But in my opinion, and based on my experience of using CC so far, that is not really the right way. Why? Because Claude has a specific way of doing things due to the way it is trained, and by forcing it through specs to do something that does not align with that, we are basically (a.) handicapping Claude by not allowing it to do what it knows best, and (b.) blinding Claude by not telling it the goal of the project, which specs are not really used to convey. I could be wrong, but for now I am not convinced.
The skills
The “default” CC is built to be as generic as possible, which is understandable, because CC technically needs to support the use case of every user. So a way to overcome this is to use skills, so that Claude can “function” in a certain way that the user wants, and by extension CC itself. Just to be clear, this is different from mods, which are mainly aimed at customizing the CC tool itself, whereas skills are for Claude. I think skills are quite powerful, especially since you can use them to “steer” Claude’s behaviour by writing in plain text (yes, they are really just predefined prompts!). I currently maintain my own skill library under ceh-claude-code-library, which has been through multiple refactors, rewrites, and 1 migration. And now, with the experience I have, I can confidently say this: skill files should always be created based on a workflow. They should reflect how you work, instead of being a collection of dos and don’ts for topic X (#LESSON-5). This mainly boils down to how Claude triggers the skill. If the skills reflect how you work, they will get triggered easily as part of your workflow. If not, then you will need to remember to invoke them, which is hard if you have many skills. One thing that I keep reading is that we should not be using too many skills. In my opinion, there is unfortunately no clear-cut answer to this. If your workflow has many steps and the tasks are large, then using multiple skills will be beneficial. But on the other hand, we should not write a skill for every single step within the workflow. Why? Because most of the time, a lot of the workflow is relatively generic “standard practice” that almost every developer follows, for example the git branch convention. This is information that Claude already has, and Claude can act on it without the need for skills.
The only Claude that matters - Opus
Going back to the paranoia, after months of using CC, I have come to the realization that we should always use the most powerful Claude, which in this case is Claude Opus. We can argue about which effort level to use, but at the end of the day, just use Opus. Why? Because even though Opus uses more tokens, it also creates a “higher quality” codebase that requires less correction or modification by you (#LESSON-6). In many cases, it is also able to write clear notes and comments in the code, as well as clearly explain what it has done in the response. The explanation is especially crucial to why we need to use Opus, because a good explanation is basically the only way to know if Claude did what you told it to do, since we don’t read every line of code anymore. I can tell you right now that after using Opus for a while, Sonnet and Haiku just feel very bad in comparison. Fable is good in my opinion, but I have only had limited usage time with it, so I won’t comment on it. Sonnet is really only usable if we know exactly what we want and the task has 0 ambiguity. A test I give myself to identify if Sonnet can do the job is to ask myself: if I am doing this task and 10 other tasks in parallel, can I still do this task? If yes, then Sonnet it is. Unfortunately, when building new projects this is never the case, because there are so many unknowns.
The transition to personal AI agents
I think once you have used CC as much as I have, you would probably ask the same question: can I use CC for other tasks besides coding? Surprisingly, the answer is yes, especially through the use of skills. You can use CC to do planning, brainstorming, writing blogs, etc… (#LESSON-7). In my opinion, CC can even replace all the AI chat services or apps that you are using. The only downside is that CC comes with a lot of prebuilt tools and features that are tailored for coding. And crucially, while CC does state management for you out of the box, you still need to do session management yourself, aka starting, ending and resuming sessions. What if there is a way for CC to do tasks proactively, without needing me to start a new session? What if there is a way for the agent to learn new insights from past sessions and use them in future ones all by itself? The answer for now seems to be personal AI agents such as Muse, OpenClaw, Hermes, and Grok Bot. I haven’t gotten the chance to use them yet, but it would seem like that’s where the trend in agentic AI is going. In just half a year (for the industry about 3 years), I went from chaining LLM outputs to exploring AI agents that can proactively perform tasks without me telling them what to do. And for me personally, this is such an interesting and exciting time to be alive =D