In the first part last week we saw what we need to run Claude Code with a local LLM. In this second part we take a closer look at the different models and how they perform on different machines. Then the "right" model does not help us much if we cannot run it with the needed context size or when it only produces a few tokens per second. This is the hard part of running Claude Code against a local LLM and there is no solution that works everywhere.
Running Claude Code against a self-hosted LLM is much simpler than I expected. All we need are environment variables and the local LLM itself and we are good to go. However, that is just the start, and the challenges arrive when we try to do some real work. Let us see what we can do to tackle those challenges.
Creating the first CLAUDE.md file is not much work as we saw in last week's post. However, getting an initial file and something that helps us is not necessarily the same. Why not use Claude to improve our CLAUDE.md file?
As we saw in the insights report from last week, there are usually a few suggestions on how to improve our CLAUDE.md file. But if you never used a CLAUDE.md file that may not help you enough. In this post we take a close look at this helpful file and how we can use it to our advantage.
Claude Code gave us in April a new feature that allows us to see how we use Claude Code. Even better, it is not only a tool to show us what we did, but it helps us to get better. Let us see how it works.
If you return to Claude Code after a few weeks of vacation, you may be way behind on all the new things that you now can do with Claude Code. Let us explore a few ways to get up to date and not to miss important updates.
When we use tools like GSD, Claude Code does a ton of work for us. It does it so fast, that we cannot keep track. Did it call a specific tool? What was our input? If those are questions you would like an answer for, then this post is for you.
After a rather disappointing experience with OpenSpec I kept looking further and found Superpowers and Get Shit Done (GSD) as candidates for another round of tests. I tried to build the same application as with OpenSpec and found some interesting differences.
OpenSpec brings spec-driven development (SDD) to AI coding assistants. The idea is that we move away from vibe coding and use well-established practices for software development inside our AI coding tools. While I love the idea, my first experience was not that promising. Let us see what happened.
AI coding agents are impressive. Give them a prompt, and they can scaffold apps, write tests, refactor code, and even debug tricky issues. That speed makes them feel almost magical. But anyone who has used them on a real project learns the same lesson quickly: the quality of the output depends heavily on the quality of the requirements.
Requirements are not bureaucratic overhead. They are the map for what to build. A human developer can often fill in missing context through experience, conversation, and judgment. An AI coding agent cannot do that reliably. Combine that limitation with the agent’s speed, and you get a recipe for disaster. High-speed development does not help when you move in the wrong direction.
So how do teams find the right direction? With requirements. But as with all important things, it is not as easy as it looks.