Igor Bubelov

LLM Use Cases: Code Reviews

Sat, 03 Oct 2026 00:00:00 +0000

Crossing the Rubicon

BTC Map Android v1.2.0 shipped on September 30, roughly six months after v1.1.0. The previous release was 100% hand-written, and this one started the same way, with zero LLM involvement.

Early in the cycle I introduced OpenCode, starting with some models provided by PayPerQ and quickly switching to M2.7 Highspeed (2026-04-09) for better latency and reliability. It turned out to be counterproductive, but amusing.

Then came M3 (2026-06-01), which felt value neutral, more of a toy than a tool. Finally I tried DeepSeek V4.1 Flash (2026-09-10), and it crossed the Rubicon of actual, indisputable LLM usefulness on real tasks. By the time I cut the release, almost every recent change was LLM-accelerated.

Many new features were still hand-written early in the dev cycle. That notwithstanding, before cutting the release, I put every module, new and old, through an LLM code review and kept iterating until there were no findings of medium severity or higher left.

My Code Review Setup

Before doing anything else, I created a bash helper script for managing the emulator lifecycle. The goal was to make sure the LLM knew exactly what to do and would not waste time struggling with the dev environment.

My workflow was simple. I would point the model at one module, ask for a review with findings ranked by severity (low, medium, high, critical), fix every finding at medium severity or higher, then re-run the same review. Repeat until the module comes back clean, then move on to the next one. Some modules took one pass, others took a dozen.

In my experience, DeepSeek V4.1 Flash is a fantastic reviewer. What sold me most was its speed. It is fast, thorough, blunt, and cheap enough to re-run the whole app a gazillion times. That matters a lot, because quantity beats quality in code reviews. Fixing one issue reshapes the surrounding code and tends to expose the next one.

More Code Is a Liability

The obvious pushback is that most findings are edge cases nobody will ever hit, and every fix that adds code makes the codebase bigger and harder to maintain. There is truth to that. A reviewer, human or not, is rewarded for finding something, and “delete this and make it simpler” is a much rarer suggestion than “add one more null check for an impossible state”.

I did not fix everything. I routinely ignored low-severity findings on purpose, and I rejected my share of medium-severity findings too, precisely for the reason stated above. The severity threshold is what made my workflow net-positive. Without it, an eager clanker will happily bury a small app under defensive code, which is a net negative even if every individual suggestion is technically correct.

What the Reviews Actually Found

Some findings were genuinely useful, in ways that justify the effort.

Real bugs. Races, stale state, leaked resources, and mishandled empty or error responses. These are the ones that are hard to reproduce and easy to ship unnoticed.
Consistency. The same screen doing the same thing in three different ways, or error handling drifting between modules. Boring, but if you’re autistic enough, you’d appreciate the value.
Tests. A lot of findings were cheap to turn into regression tests instead of yet more defensive code, and the test suite grew noticeably because of it.
Architecture. Repeated reviews and revisions pushed the code toward less coupling and clearer separation of concerns, which is a benefit that no single finding captures.

That last point is the one I underrated. A reviewer that reads every module over and over starts to notice structural problems, not just local ones, and that nudges the architecture in a good direction.

Conclusion

The previous, fully manual release shipped six months ago. I am very happy with how 1.2.0 turned out, and it feels much more stable than v1.1.0.

This workflow is not free, and it is not magic. Reviewing is a loop with a real time cost, and the temptation to over-engineer is something you need discipline to suppress.

An LLM is also not a substitute for tests or for understanding your own code. It does not know your product and will cheerfully propose correct, useless changes. But as an extra pair of eyes that never gets bored, applied to a codebase you wrote and understand, code review is one of the better LLM use cases I have found so far.

LLM Use Cases: Reports

Sun, 06 Sep 2026 00:00:00 +0000

Reporter and Editor

A journalist friend of mine once told me that in the standard reporting pipeline, you always have an editor. The original writers are often too verbose and rambling, and it is the editor’s job to filter out the noise.

Journalists often have a beef with editors for that reason. Editors have their own vision and the ultimate power over the final text.

I find this framing useful when thinking about LLMs and text generation.

Commits as Inputs

My commit messages are now mostly LLM-generated, and my recent commit history is rather verbose. My average commit message used to be a one-liner, probably comfortably below 80 chars. Not anymore. Now my commit messages are longer than the actual code diff.

That makes it trivial to feed the commits into an LLM and ask it to summarize everything into a draft report. The goal is to get rid of the repetitive, exhaustive job of manually reviewing every commit and turn the verbosity into an asset rather than a liability.

We publish two kinds of monthly reports for BTC Map. One is the consolidated report on the BTC Map Blog, and the other is my personal report, published here on this blog.

I started feeding an LLM a time period and a list of git repos, then asking it to produce a draft changelog. My job shifted from journalist to editor. I take the draft, shorten it, rearrange what survives, and remove the slop.

Trouble in Paradise

Did the report quality improve? The answer is: yes and no.

For my personal reports, quality did improve because I tend to forget details and clankers have a good memory. I still spend roughly as much time preparing my reports as before, but my reports are better both in terms of grammar and content. The boring part is faster, so I can shift my focus to readability.

I cannot say the same about our consolidated reports though. I suspect the reason is that they are just unedited LLM outputs. I am not just speculating here, it is trivial to see. LLMs cannot figure out which changes are meaningful, which changes are inappropriate for the format, and which ones are just noise.

My personal report is supposed to be technical, since my contributions are mostly code-focused. Our consolidated reports target a completely different audience, so they used to be focused on new partnerships, usage statistics, and so on. But because both reports are fed the same commit history, they include all kinds of irrelevant noise and nitpicky details derived from raw commit messages.

Conclusion

I find LLMs useful for report generation, but here is my personal rule: it is not a good idea to publish something you did not even bother to read a few times and fully conceptualize yourself.

If I am not ready to read, fact-check, and polish my own text, why would someone else read it? Respect for the reader is fundamental. New fancy tools don’t change anything in principle.

This morning, I saw someone on Twitter defining AGI as “Actually Generating Income.” I think it is a good framing. We see an explosion in textual output, but do we see an explosion in quality? The answer so far is a definitive no.

LLM Use Cases: System Updates

Tue, 28 Jul 2026 00:00:00 +0000

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.

pacman in action

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.

A decent report, under 60 sec

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:

11 minutes of “thinking”, gazillion tool calls, bs report

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.

Igor Bubelov

LLM Use Cases: Code Reviews

Table of Contents

Crossing the Rubicon

My Code Review Setup

More Code Is a Liability

What the Reviews Actually Found

Conclusion

LLM Use Cases: Reports

Table of Contents

Reporter and Editor

Commits as Inputs

Trouble in Paradise

Conclusion

LLM Use Cases: System Updates

Table of Contents

The World Is Not Black and White

Why This Series

Case 1: System Upgrades

Verdict