AI removes annoyance—but the complexity remains

The article opens with a thought experiment: compilers exist because humans tired of writing machine code, but we do not say the compiler "wrote" the program. Linus Torvalds made this comparison, arguing that AI is a tool that changes how programmers create, not necessarily who created what. The key insight: compilers eliminated low-level creativity but unleashed higher-level creativity—in algorithms, data structures, languages, and systems. The article explores whether AI will follow the same trajectory.

However, a crucial difference exists. Compilers require a higher-level formal language first; the knowledge is already locked into a durable representation before compilation. AI, by contrast, can generate implementations directly from informal requests, leaving knowledge scattered across prompts, generated files, tests, and human memory. This matters because the feedback mechanism that historically drove better abstractions—annoyance—relies on friction. The best engineers, the author observes, are "lazy in a particular way": they will spend a week eliminating a task that costs five minutes a day. That refusal to tolerate repeated friction is how better tools are born. More importantly, annoyance is a "wrong-abstraction detector." It signals that durable information is being restated, that decisions from different layers have collapsed into one operation, or that the same idea appears in many slightly different forms.

When AI removes that annoyance—generating long commands, configuration files, or integration variations—the complexity does not disappear; it merely moves out of sight. The author illustrates this with a concrete case. While developing a service, he faced a deployment workflow involving a bespoke Dockerfile and a long command combining details from multiple layers. His first solution embedded staging and installation logic directly into the service. It worked, but creating the documentation revealed the awkwardness: the service used itself to construct another form of itself. An AI given the ticket-sized task of "make this installable" would likely have produced the same result and declared success. But the author's annoyance—his refusal to accept the incoherent structure—led him to extract this logic into Reploy, an unreleased tool that treats portable application lifecycle (stage, change, test, install) as the primary object, not staging as a service property.

The article then addresses a counterargument: perhaps AI is correctly making some abstractions unnecessary. Repeated implementations are no longer automatically expensive, and a shared abstraction introduces its own costs—coupling, compatibility constraints, leaky boundaries. Cheap, generated code may sometimes be better than a framework. However, many abstractions do more than save effort; they make shared concepts explicit—what an object means, who owns a behavior, which invariants must hold. Generated code reduces duplication cost but not the need for shared meaning. This creates a paradox: cheap code weakens pressure to abstract while abundant code increases the need for trusted abstractions. Code can be regenerated from a prompt, but the expectations surrounding it cannot. The author proposes a practical test: if only implementation repeats, regeneration is fine; but if requirements, invariants, ownership, or compatibility expectations must be reconstructed each time, the duplication carries meaning needing a shared model. Ultimately, the article argues that AI will not eliminate human creativity but amplify its leverage—once someone sees beyond the working answer, imagines a possibility that does not yet exist, and decides that it matters.

The article rests on a historical observation: creativity in engineering has always moved upward when lower-level work becomes cheaper. Compilers did not destroy programming; they freed humans to think about algorithms, languages, and systems instead of opcodes. The author applies the same lens to AI, arguing it will likely follow a similar path—but with a critical risk.

The risk hinges on a feedback mechanism that has historically driven abstraction: annoyance. When a task is tedious enough, engineers invest time to eliminate it—building tools, frameworks, or shared concepts. Hydra, a configuration framework the author created, emerged from this pattern: long command lines combining unrelated concerns (identity, storage, networking, security) forced the author to reconstruct an implicit model each time. The solution was to make that model explicit and composable.

AI disrupts this loop. If a long command is annoying to type, an AI can generate it. If a configuration file is tedious, an AI can write it. The friction signal—the very thing that used to motivate abstraction—is gone. The author illustrates this through a service deployment scenario: an AI given the task "make this installable" might reasonably embed installation logic into the service itself, run tests, and declare success. But the author's lived experience with the problem revealed that staging, configuration, and installation belonged in a portable, declarative infrastructure model (Reploy), not in the service. Only accumulated contact with the problem—the annoyance—exposed the missing concept.

No comments yet. Be the first to share your thoughts!