LLMs and xfwl4

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 writing¹). 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.