Finding LLM Use Cases: Part 1

The World is not Black and White

I have mixed feelings about LLMs. They clearly matured enough to do some small tasks with a high degree of reliability, but the tech has some fundamental downsides.

LLMs are non-deterministic, which makes them hard to integrate into reproducible workflows. This is a core property of any fancy word predictor based on statistics, and there is no way of fixing that.

I’m not that worried about the environment, so the environmental damage angle doesn’t concern me, but the demand for high-bandwidth memory and fast storage has pushed RAM and SSD prices through the stratosphere, hurting everyone, regardless of their Greta Jugend membership status.

And yet, like most people in tech, I still like to play with new things and see what can be done with them.

Why This Series

This series will be a handful of posts, each focused on a single workflow that I tried to improve with LLMs, in the hope of making my life more comfortable or productive. Some have worked, some haven’t, and a few are still in limbo. This is the first one.

Case 1: System Upgrades

I run Arch Linux on my machines and update them daily. It’s a rolling-release distribution, so every pacman -Syu pulls in a mix of small fixes and major upgrades, and there’s rarely a boring day.

TIP: Try uncommenting VerbosePkgLists in /etc/pacman.conf. It makes it much easier to examine the diffs. One package, one line.

The thing that always annoyed me is that distros don’t ship changelogs. The best you typically get is something like “old version: 1.2.3, new version: 1.2.4”, which tells you almost nothing.

To find out what actually changed, I have to open a browser, hunt down the upstream project, and find the release notes. With dozens of packages updated every day, laziness often takes over and I just type yes without a deep review.

Since LLMs are pretty good at web search, I figured this was a reasonable use case. I hooked an LLM into my update routine and instructed it to fetch the changelogs for every package that’s about to be upgraded. The result is a comprehensive pre-update “what’s new” report that I can read in plain English before pulling the trigger.

Verdict

Surprisingly, it’s one of the few LLM-enhanced things in my workflow that actually works. Most days, the report is solid. It covers the major packages, pulls relevant highlights, and is genuinely useful. Some days, though, the formatting falls apart, a few sources fail to fetch, and the same data is presented in a completely unreadable format.

The only way to make it reliable is to invest a lot more effort. I can hardcode the changelog sources for every package, write strict rules for the report layout, and add validation passes that catch and fix structural issues. That might help, but that’s a lot of work for a tool that’s supposed to save time.

Here is what it produces on a “bad” day:

I’ll keep experimenting with this use case, but so far I can’t call it a success, and the future doesn’t look bright for my LLM-enhanced system update flow.