I was planning to write a little about my usage of LLMs while building xfwl4 as a small section of a larger blog post, but I decided I’d rather get it out of the way on its own.

While LLM usage can be polarizing in the context of open source, I don’t really see it that way. It’s a tool, like any other. It has good parts and bad parts. On the bad parts, there are three things that stick out for me: Training Data and Copyright

Among other sources, LLMs were trained on publicly-available data, without the permission of any of the rightsholders of that data. That especially smarts since I have a lot of open source code out there, much of it licensed under the GPL. Is training an LLM on my code copyright infringement? If someone gets output from an LLM that looks substantially similar to my code, and they don’t know and don’t follow my license terms, is that copyright infringement?

And if it goes the other way, if output I get from an LLM looks very much like someone else’s code, did I infringe on their copyright?

I’m not sure! US law seems to suggest that training is fair game, as long as the entity doing the training has legal access to the data they’re training on. As for the rest of it, I’m not sure that’s legally settled yet.

On top of that, it sometimes feels icky that companies like OpenAI and Anthropic are making money off of all this when all that data out there – for which they mostly paid nothing – makes it possible.

I don’t, however, think the best response for myself is to just pretend none of it exists. It’s a tool, and a useful one. Environmental and Social Impact

LLMs need a lot of space, electricity, and water. Communities where data centers are being built, along with the associated power plant upgrades, are often getting stuck with some of the bill for those improvements, which is disgusting.

The secret deals between datacenter companies and utility companies, often with municipalities complicit, are often leaving regular ratepayers out to dry. That’s a local problem, and I hope those local people vote in representatives who will take better care of them. Supply Chain

I don’t need to remind anyone how expensive GPUs and RAM are right now. I was planning to upgrade the mainboard in my laptop this year, which would require new RAM (my current board has DDR4 in it), but the cost of 64GiB of LPCAMM2 DDR5 makes my eyes water.

The consumer RAM market has been hollowed out; several companies have either stopped making consumer-grade RAM entirely, or have severely restricted supply in order to make more money selling to datacenters and AI labs. That’s capitalism at work for you, at the expense of regular folks who need to buy computing hardware for personal use.

But here I am, with a Claude Max 5x subscription for the past year and a half. I’m not comfortable with it, but the utility is just too great for me to take a principled stance here. I like it, and I want it, so I’m using it. Maybe that’s morally questionable, or worse. But, as I said: here I am. xfwl4 and LLMs

So yes, I use Claude quite a bit while developing xfwl4. I don’t vibe-code, ever, and I probably use the LLM to generate less code than most people do. After all, building things with code is my hobby and passion (and I’m lucky I got to do it professionally for a quarter century), and driving an LLM is kinda boring. Research and Planning

Most of my time with Claude Code is research and planning. One great match for LLM use here is helping me understand the finer details of xfwm4, since xfwl4 needs to duplicate all of its behavior. One common prompt of mine:

look at the xfwm4 source in detail and determine everything there is to know about $FEATURE. write up a plan for how to implement it in xfwl4 to notes/$FEATURE.md.

I go do something else for a while, and when it’s done, I read the doc, and then spend a while asking Claude questions about it, and telling it the things I don’t like and what I’d like to be done differently, and it updates the doc. Implementation

Most of the time I’ll start working from the notes doc myself, writing the implementation by hand. My guidelines for plan-writing to Claude are to do things in phases, and so I’ll complete a phase at a time, and then ask Claude to validate what I’ve done. Often, while I’m working, I’ll decide to deviate from the plan, and I’ll have to tell Claude to do the validation based on the outcome I want, not based on adherence to the plan.

Once it’s done, I’ll use /code-review and let Claude spawn sub-agents to do a full review of the new code. This usually finds some problems, even problems that the “main” Claude instance didn’t find during its validation. I usually keep running /code-review again and again after finding and fixing issues, until there aren’t any left. I actually haven’t been doing /code-review for very long, maybe 6-8 weeks, as I didn’t know about it. I wish I’d done it from the start, as it’s very useful.

Sometimes I will have Claude write some code for me. Usually it’s when there’s a lot of boilerplate, or if there’s work that feels repetitive and tedious. Claude is generally a great fit for that, and I can both manually review the output and have a subagent do an independent review. I’ll usually keep CC in manual mode and approve every edit after reading it, but for some more mechanical changes, I’ll let it sit on auto for a while, and review when it’s done.

Occasionally I’ll have it write more substantial code for me, usually for bug fixes, and occasionally for small features. I find it does a pretty decent job here, but I keep it on manual mode and often ask it to write the code in a different way, or take a different approach. Bug Fixing

Whenever there’s a bug, I’ll start looking into the code myself (I want to keep my debugging skills from atrophying), but in parallel I’ll also ask Claude to look into it, either by describing the problem, or pointing it to a Gitlab issue, if there is one.

I’ll admit that it’s rare for me to find the issue faster than Claude does, and there were some issues where I was completely lost, and Claude figured out something in 10 minutes that probably would have taken me days. Tests

xfwl4 doesn’t have many unit tests, but I’d like to improve that at some point. Of the unit tests that do exist, they were al written by Claude. I’ve always found testing to be tedious, and never did a very good job of it. Claude’s tests are generally much more comprehensive than tests I’d write myself.

I’ve heard stories of people saying that Claude will change or delete failing tests instead of actually fixing the problem that makes the test fail, but that hasn’t (yet) happened to me.

xfwl4 also has a test-clients sub-crate that has a bunch of Wayland and X11 client apps for manual testing of various compositor features. I wrote the first Wayland test, using smithay-client-toolkit, but for the rest of them, I told Claude to write them for me, using my first test as a template. My LLM Strategy

I don’t really have one. I just run the best model available for everything (Opus 5, at the time of this writing1). I don’t write skills or other bits of automation. I expect some of that is indeed valuable, but I’m just not interested in it, so I don’t do it.

My usage isn’t high enough to ever hit my 5-hour or weekly limits on the Max 5x plan, so I just don’t worry about it. I started out with the Pro plan, but very quickly started hitting limits in the first 1-2 hours of the 5-hour windows, so I eventually upgraded after trying out extra usage for a bit and deciding I’d be spending more going down that route.

As I said above, I don’t vibe-code. I care about code quality and about understanding what I’ve built. I care about being able to maintain it in the future, manually, without needing an LLM to do everything for me. And That’s It…

That’s it, I guess. I don’t think I would have made anywhere near as much progress with xfwl4 without an LLM. It’s easily saved me months of time, not in writing code (for non-trivial things, I can usually write it just as fast or faster), but in tracking down problems and helping me figure out solutions, whether that’s in Claude reading and reasoning about my code to find something that’s wrong, or in adding tons of targeted debugging prints to gather the information we need, and then sifting through the log file for me to do analysis.

I know this blog post is a tiny drop in an ocean of people writing about their LLM use, but I expect some folks might be curious about the development process behind xfwl4, so I figured a sort of disclosure was in order.

It’s been a little over a month since the first preview release of xfwl4, and I’ve fixed many issues and added new features since then. Hopefully I should have a new preview release in the next week or so, but you can clone the git repository to check out the current state of things for yourself, whenever you want.