How I use LLM for my work

One of the hot topics in the last months has been the use of “AI” — which usually means using LLMs (Large Language Models).

After a big push at work to adopt “AI”, it took me some time to find a good use of it in my daily workflow.

Rewriting software

One of most popular ways of using “AI” is rewriting software. I know people having old games ported from one retro platform to another this way.

However, the low barrier to entry gave many people a way to jump in which did not end well…

As a result, countless projects have stopped accepting merge requests because so many of them were nothing more than “AI slop” (aka “worthless junk not even worth looking at”).

My example

I have used Claude to rewrite my EDK2 ArmCpuInfo project to make it easier for me to update it. The statistics of the commit that did most of the work:

lines changed: 5630 additions & 3552 deletions

I would not send anything like that to anyone for review. Far too messy. Going through it was painful but I got what I asked for. And this was a result of several prompts and manual changes.

Fixing packages

As you know, my work is mostly around building packages. I have worked on Arm, AArch64, ppc64le, s390x and now RISC-V. I fixed countless packages by hand, going through their source and finding out why they failed and how to get them building on target platforms.

After my last vacation I decided to check how an LLM would help with it.

I fetched the package, unpacked the sources (fedpkg prep), fetched the build.log file from the latest failed build, and ran Claude with one, simple prompt:

Look at build.log and source and find out why it does not build on risc-v.

The amount of time I had to wait and output to read varied from package to package. Sometimes build logs from other Fedora architectures were needed, sometimes a few build attempts. At the end I had a patch which made the package buildable on the RISC-V architecture.

Types of fixes

Some fixes were simple, like fastnetmon where a change in the link order was the only thing needed.

Some were funny, like GNU Data Language where fixing RISC-V fixed it for AArch64 as well. This made the build fail, as some tests, which were expected to fail, passed.

Others were related to differences between RISC-V (RV64GC) floating-point unit compared to other architectures. Such “simple” things like “are we dividing by zero” can be a problem.

Things I do not send

There were also packages for which I got some patches and never sent them neither upstream nor to the package maintainer.

Those were ones I did not understand. For instance, a patch changed how the “R” language handles “NA and NaN” numbers. It was yet another issue related to how RISC-V FPU works. Also it was so cryptic that I looked at code and had no idea what I was looking at.

The final question

I understand FOSS developers who refuse to accept any “AI generated” changes. There is too much “AI slop” being submitted. At the same time I wonder where their limit is.

Would they merge patch below or not? And would presence of the “Assisted-by: LLM” line make them refuse this patch or not? Will they accept it without such line?

Subject: [PATCH] Fix abseil link order for ld.bfd

Move absl:: libraries after gRPC in fastnetmon_api_client link list.
ld.bfd (used on riscv64) is a single-pass linker and needs dependees
before dependencies.

Assisted-by: LLM
---
 src/CMakeLists.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 10caf4c6..5bde9fcc 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -800,10 +800,6 @@ if (ENABLE_GOBGP_SUPPORT)

     add_executable(fastnetmon_api_client fastnetmon_api_client.cpp)

-    if (LINK_WITH_ABSL)
-        target_link_libraries(fastnetmon_api_client  absl::base absl::synchronization)
-    endif()
-
     # We use another way to specify dependencies for Windows as our standard approach clearly does not work
     # https://www.f-ax.de/dev/2020/11/08/grpc-plugin-cmake-support.html
     if (${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
@@ -819,6 +815,10 @@ if (ENABLE_GOBGP_SUPPORT)

     target_link_libraries(fastnetmon_api_client protobuf::libprotobuf)

+    if (LINK_WITH_ABSL)
+        target_link_libraries(fastnetmon_api_client  absl::base absl::synchronization)
+    endif()
+
     if (KAFKA_SUPPORT)
         target_link_libraries(fastnetmon ${LIBKAFKA_CPP_LIBRARY_PATH})
     endif()

I would accept it. Because for me, despite the origin of that patch, it is a very simple change to review.