hulryung.comhulryung.com
KO

The Efficacy of LLMs — An Era Where We Build What We Never Used to Build

AI
LLM
생산성
The Efficacy of LLMs — An Era Where We Build What We Never Used to Build
한국어로 읽기 →

The Story of Reviving a 25-Year-Old Kernel Driver

I recently read Dmitry Brant's post Using Claude Code to modernize a 25-year-old kernel driver. There was a Linux kernel driver called ftape, written for QIC-80 tape drives from the 1990s, that had been abandoned for 25 years after kernel 2.4. The author, with the help of Claude Code, modernized this driver to work on a current kernel (6.8).

What's interesting is the nature of the work itself. Kernel driver migration is grueling work that involves replacing old APIs, changing build systems, and hardware debugging all at once. The author himself said, "I could have done it myself, but it would have taken several weeks." In the end, he finished it in a few days working with Claude Code.

Reading that post, one word came to mind: efficacy.

What Is the Efficacy of LLMs?

In psychology, self-efficacy is the belief that "I can do this." The efficacy of LLMs is a bit different. It's the sense that "now I could actually build this too."

There's a lot of software in the world that is genuinely necessary but that nobody builds. The reasons tend to be similar.

  • The value-to-effort ratio is low. Only I — or an extremely small number of people — would ever use it.
  • It's tedious. The core logic is simple, but there's a lot of surrounding boilerplate.
  • There's a wall of domain knowledge. You'd need to learn kernel drivers, systems programming, or a particular OS's API from scratch.

When all three overlap, you never act on an idea even when you have one. Things you tell yourself "I'll get to it when I have time" — and then never do.

LLMs change this equation. The boilerplate gets written by the LLM, unfamiliar API documentation gets read by the LLM, repetitive debugging cycles get worked through with the LLM. When LLM execution ability is added to the domain knowledge and ideas you already have, "things you were too lazy to build" turn into "things you can build and ship."

My Experience: Small but Necessary Apps

I've been experiencing something similar firsthand.

Korean Input Switching Without Karabiner

To customize Korean/English input switching on macOS, most people install Karabiner-Elements. It's a powerful tool, but it's heavy just for changing a single input key. You have to load a kernel extension, write a configuration JSON, and fiddle with system security settings.

"A lightweight app that switches Korean/English input with just the Right Command key" — there's clearly a need for this, but building it means learning macOS's input source API, keyboard event hooking, and app bundling. A classic "necessary but tedious" task.

With LLM assistance, the story changes. In the process of setting up a Swift skeleton, configuring a CGEvent tap, and implementing the input source switching logic, the LLM guides me through the APIs I don't know, while I can focus on verifying behavior and handling edge cases.

An App That Only Reverses Mouse Wheel Direction

On macOS, natural scrolling on the trackpad feels natural — but when you connect an external mouse, the scroll wheel direction is reversed. If you change the scroll direction in System Settings, it affects the trackpad too. There's a need for "an app that only flips the mouse wheel direction," and again, building it myself felt like too much hassle.

Same story here. The core idea is simple (intercept only mouse scroll events via CGEvent tap and reverse direction), but the actual implementation comes with tedious work like event filtering, device discrimination, and permission handling. With LLM assistance, work like this wraps up in a few hours.

Why This Matters

The common thread in these cases is that they're all "software for a small number of people."

People using 25-year-old tape drives. People who just want to change the Korean input key without Karabiner. People who only want to flip the mouse wheel. From a market logic standpoint, there's no reason to build this software. The user base is too small.

But as LLMs have dramatically lowered development costs, the very criterion of "too few users to be worth building" is changing. Now you can build an app even if you'll be the only one using it, and if you've built it, you can ship it too. And it becomes real, practical help for the small number of people who share the same frustration.

This is what I mean by the efficacy of LLMs. Not some grand AI revolution, but a quiet shift: "things I was too lazy to build, I now build." And as these shifts accumulate, the world will have far more "small but useful software" than it does today.