Claude Code over the last weeks

The last couple of weeks I’ve been very busy freelancing. A new customer emerged and needed a PC and NAS setup, and an existing customer needed some changes on their network. Quite nice, I have to admit, finally bringing money into the freelance part and not only paying stuff.

Besides that, I spent a good portion of February with Claude Code. I burn around $800 in tokens before switching to the subscription-based payment. I learned a lot about Claude in general and how LLMs work as a whole.

One of those things I did was consolidate all my small coding side projects into one large monorepo, quite a hassle if you were to do it manually, but I have to admit Claude did a fabulous job. Instead of having a bazillion similar small projects (I’m mostly using Astro.js & React) with almost the same npm dependencies, I now have one large project, several claude.md files in it, and pnpm as dependency manager, and I’m quite pleased with it.

I recently also got access to Claude at my employer, and there are a few key things I learned: It won’t make developers jobless anytime soon, and there is a huge difference between API-based billing and the subscription models.

One thing Claude really runs well (probably GPT Codex too) is if there is a designated task defined by a person who knows the repo and knows what the output should look like. I’ve built myself a private chatbot (based on Sonnet 4.5/4.6) with RAG and Smart Home integration in basically a weekend. The code is maintainable, and occasionally I extend stuff myself. But there is a caveat and a new skill to learn for programmers: prompt engineering. Not in the way of “What is the best prompt” as a whole, but more in the sense of “How do I break this down in a way a junior dev (Claude) can take it over and implement an architecture that makes sense (so it doesn’t just push out slop)”.

And to be honest, I quite like learning that new skill, not only to get my side projects more attention again (because I can quickly iterate on features or fixes) but also because I can do it while watching TV and let Claude do the heavy lifting. Sure, it needs guidance quite regularly, but “dumb line after line” writing works better than I expected.

You might be saying now, “But C-level can spec out stuff too.” Yes, they can, but you can see the output Claude produces in contrast to the output from a developer. That’s nothing you can blame on Claude; the outputted code still works, but when it comes to scalability and maintainability, that’s an entirely different thing.

On the API/subscription stuff, neither Anthropic nor OpenAI admit it, but having run several models on my local RTX4080 (in my gaming rig), both the subscriptions and API billing are still far too cheap. And I mean by magnitudes of at least 5x to 10x. Sure, all the big players currently run on venture capital to grab users, but I think we are not nearly close to cost break-even. That said, they must be running huge losses on the subscription, because one thing I consistently observed: The API-billed Claude is consistent in reasoning, answers, and code. While the subscription-based one (which I use now to not declare bankruptcy in a few weeks) has good and bad days. One day you’ve got a competent senior dev that has 20 years of software engineering experience, and the next day you’ve got a junior that has never written code.

And I’m not the only one observing that; coworkers are experimenting themselves and observing similar patterns, and I’ve seen a bunch of Reddit posts on that topic too.

What also works very well is server setup & admin with Claude. I moved several Hetzner servers around over the couple of weeks before finally deciding on an architecture that is feasible for me and my customer for the next years. Although I know (mostly) how to run a Linux machine, having a living document where I copy and paste run commands and Claude adds appropriate documentation makes a huge difference. With my current setup, I can spin up the same server in a matter of hours instead of days.

But, there is also a downside: instead of powering down the MacBook after work and simply doing something else, I tend to extend my workday (well, there is currently a shitload of work I need to do before the upcoming Japan trip) because I can just do “one more bug fix or feature spec out”. And I can sometimes feel myself slacking with prompts, which leads to semi-optimal code, just like the same if you do way too long coding days.

Also, since switching over to coding with Claude mostly, my creative writing stuff has fully died down for now. But that should come back once I’m done fiddling around with side projects (but there is always one more feature to build 🙈😂!)