Once again, I’ve been meaning to write up a bunch of stuff here on my blog, but just haven’t gotten around to it. In my last post, from about two weeks ago, I blogged about the nightmare that was Main St overnight construction. Well, the good news is that there’s hasn’t been any more over the last couple of weeks. The bad news is that they haven’t been able to do it because the weather has been so bad. We had a big snowstorm, followed by very cold temperatures, so a lot of the snow is still on the ground. I won’t get into all of the inconvenience that’s caused. I have other stuff I want to blog about. Let’s just say that a combination of stuff, staring with the construction, then the weather, has really put a dent in my productivity and equanimity this year.
So on to the next thing. One thing I’ve actually managed to learn and enjoy playing around with this year has been Mermaid, a language for creating diagrams programmatically. I’ve always hated creating diagrams with drag & drop tools like Visio and Lucid. I’m just not good at it. I never get things quite right. With Mermaid, I just describe the diagram in code and let the system render the diagram. It might not always look as pretty as a carefully handmade Visio or Lucid diagram, but it’s good enough for me!
I stumbled across Mermaid via a reference to it in David Sparks’ Obsidian Field Guide. I learned it by reading a book called Creating Software with Modern Diagramming Techniques, which also discussed the C4 model, which is a simple framework for thinking about how to use diagrams to describe a given computer system. None of this was really planned; it was just serendipity, but it turned out to be fun and useful. I’d recommend looking into it, if you have to create diagrams, and like the idea of doing it through code.
Topic number three: AI-assisted programming. I’ve been messing around with GitHub Copilot for a while. I passed an exam on it late last year. I’ve been using it at work, for my C# work. (A lot of my work is in AX 2012, using X++, so it’s not easy to use AI assistants for that.) I’ve found Copilot to be a mixed bag, in practice. I do use it, but it’s often more trouble than it’s worth.
I keep hearing good things about Claude Code, though. We’re not allowed to use it at work (sigh), but I eventually felt I had to give in and try it. This article about Microsoft not just allowing, but encouraging, their employees to try Claude Code was the thing that really pushed me to dive in.
So I’ve spent some time this week trying to figure it out. First, I had to sign up for a Claude Pro subscription, at $20/month. (I actually decided to go all-in and pay for a full year, at $200.) That money was another thing that was holding me back with Claude Code. Since I already have access to Copilot, I didn’t want to pay for another AI subscription. But, yeah, I gave in.
The next stumbling block for me was knowing that Claude Code is oriented more towards Linux and Mac developers, vs. Windows. It relies on Node.js and npm, which are… not my favorite tools. GitHub Copilot is integrated right into Visual Studio and VS Code, so you can get started with it quite easily, if those are the tools you’re using. (And, for me, they are!)
After some weeping and gnashing of teeth, I finally decided to set it up in WSL on my Windows 11 laptop. That wasn’t too hard. I initially used it in conjunction with a repo I had on my Windows drive, and which I was trying to work on in Visual Studio 2026. But that’s not a great way to work. Claude Code needs to be able to build and run your project, and if I’m doing that on the Windows side, it’s going to leave Claude crippled.
So, then, I took the leap and set myself up for .NET development under WSL. (That, also, wasn’t too hard.) So the setup I settled on is, basically, opening a WSL prompt in Windows Terminal, changing into my project folder (now in the WSL filesystem), running “code .” to open my project in VS Code, then running “claude” from the prompt to set up the Claude Code environment. (Using VS Code from WSL is described here.) So I switch back and forth between Claude Code running in the terminal and VS Code.
Once I started doing that, I was surprised to see that I could chat with Claude Code from a chat window in VS Code. Honestly, I’m not even sure how that happened, since I didn’t install the Claude Code extension in VS Code. I’m going to have to figure that out at some point.
But my main way of working was to chat with Claude in the terminal session, let it change stuff in my project, then review it in VS Code, and build and test it there. (I did let Claude build and test it a bit, too. That worked.)
The project I choose to use for my Claude Code experiment was my Project Euler repo. (I last messed around with it back in 2023.) I’ve found that Claude Code can easily solve Euler problems by just typing “implement a solution for problem XX” and then letting it go. That’s probably because so many other people have solved the problems, then blogged about them. So Claude probably has a bunch of solutions and information about the older problems in it’s training data, so it’s all baked in. But I wanted to use trial and error, and actually learn some stuff, so I figured out how to prompt it to work with me rather than just doing the work itself. Part of that was explaining my intentions in my CLAUDE.md file. (I’m not sure how much that helped, but I think it did.)
So, at this point, I know I’m only using about 10% of the power of Claude Code. Maybe less. There’s a lot more I could try. Small steps for now. I’m making progress!