AI Doesn't Get Annoyed

Skip to main content

Compilers exist because humans got tired of writing machine code. What shared<br>concepts will remain implicit when AI can keep generating implementations<br>forever?

The next compiler​

Linus Torvalds made a comparison that I found useful. He objected to describing<br>AI-assisted code as "written by AI." Compilers already generate all the machine<br>code, but we do not ordinarily say that the compiler wrote the program. In his<br>analogy, AI is another tool that changes how the programmer creates software,<br>not necessarily who created it. His larger point was that the fundamentals<br>still matter even as the tools change.

Compilers did not eliminate creativity in programming. They eliminated most of<br>the need to be creative in machine code. Creativity moved upward, into<br>algorithms, data structures, languages, interfaces, and systems.

AI may do something similar. The analogy is operational, not mechanical: AI is<br>not a deterministic translator like a compiler, but it similarly lowers the<br>cost of turning an intention expressed at one level into an implementation at<br>another. It can make one person capable of acting across a much larger surface<br>area.

But there is an important difference.

A compiler generates low-level instructions only after the program has been<br>expressed in a higher-level formal language. The knowledge has already moved<br>upward into a durable representation. AI can often generate a lower-level<br>artifact directly from an informal request, without requiring a stable<br>language, model, or interface to exist first. It can remove the low-level work<br>while leaving the knowledge scattered across prompts, generated files, tests,<br>conventions, and human memory.

Annoyance carries information​

The best engineers are lazy in a particular way. They will spend a week<br>eliminating a task that costs them five minutes a day. The immediate economics<br>may be terrible. But the refusal to tolerate repeated friction is often how<br>better tools are born.

Sometimes that instinct leads nowhere. But sometimes annoyance is a<br>wrong-abstraction detector.

Necessity invents a solution. Annoyance invents a system.

Annoyance can tell us that we are repeatedly restating durable information.<br>That several decisions from different layers have been collapsed into one<br>operation. That the same idea appears in many slightly different forms. That a<br>component is doing work which logically belongs somewhere else.

In those cases, the irritation is not just about effort. It is evidence that<br>the system lacks a useful concept.

AI changes this feedback loop. If a command is difficult to construct, an AI<br>can construct it. If a configuration file is tedious to write, an AI can write<br>it. If the same integration must be implemented differently in every system,<br>an AI can keep generating the variations.

The pain disappears, or at least moves out of sight. The complexity does not.

This is not an argument that AI cannot invent abstractions. It plainly can<br>recognize patterns, propose interfaces, and help design systems. The question<br>is what it is being asked to optimize. When AI is given a ticket-sized or<br>case-specific objective, another working implementation is usually a successful<br>outcome. The fact that humans would hate maintaining fifty such solutions may<br>never enter the task.

This is not primarily a limitation of model capability. Even an agent with<br>perfect knowledge of the codebase, given a ticket-sized objective, has little<br>reason to pay the upfront cost of an abstraction the task never asked for.

AI can identify maintenance burden, but in most current workflows that<br>accumulated cost sits outside the task it has been given. It does not spend six<br>months being interrupted by the fifth variation of the same idea. That<br>accumulated pressure usually enters through a human who notices the repetition<br>and decides that it deserves a shared model.

Software history contains many versions of this move. Build systems made<br>repeated command sequences explicit. Package managers made dependency graphs<br>explicit. Configuration management made machine state explicit. In each case,<br>the abstraction did more than save typing: it gave part of the system a durable<br>model.

The danger is not simply that AI will produce more code. It is that locally<br>successful implementations can multiply without forcing the shared concept<br>behind them to become explicit.

Long command lines are a symptom​

One place I have repeatedly felt this problem is in long command lines. A long<br>command often forces me to reconstruct a model that should already exist<br>elsewhere.

It may combine the identity of an application with its configuration, storage,<br>networking, security, environment, execution mode, and deployment details.<br>These are not all properties of the command. They describe different parts of a<br>durable system, but the command line flattens them into a sequence of strings to<br>retain, copy, or regenerate.

The problem is not character count. The problem...