AI Agents as the Next Abstraction Layer

My Blog has not talked much about AI Agents. That is usually not the kind of problem I focus on. But if you search for AI here, you can still find several articles that mention it. I have also never avoided saying this: almost all of my code is already written by AI.

As you can tell from the previous article, Bun Team: PR #30412 - Rewrite Bun in Rust / #30683 - Remove .zig source files, I do not like the kind of hot takes that spend all day preaching that AI will overthrow our industry, that the accumulated work of software engineering is now useless, or that AI will replace every programmer.

But unsurprisingly, I am also witnessing another some interesting friends. They stubbornly believe that letting AI write code will make them lose their coding ability and lose control over their own programs, so they insist on preserving the intangible cultural heritage of "traditional handmade software"...

Abstraction Stack

Today's software engineering world is built on layer after layer of abstraction and encapsulation. From bottom to top, these layers form our "technology stack". On top of the physical world, we abstracted and encapsulated logic circuit components. By assembling those circuit components, we encapsulated the CPU. By centrally scheduling the CPU and various hardware resources, we got operating systems. By smoothing over the differences among platforms, we got all kinds of virtual machines. Every user-facing business application depends on a great deal of work being done across all layers below the business logic layer.

When C freed programmers from mnemonics tightly coupled to hardware, some people also worried that this would take programmers farther and farther away from the machine. COBOL was deliberately designed to be close to English and oriented toward business data processing, claiming that business people, auditors, and managers could also understand programs. Later, many technologies that were either short-lived or sensational repeatedly promised a similar future: letting users describe "what they want" instead of telling the machine "how to do it" step by step. In 1991, Visual Basic was released, bringing drag-and-drop controls, event-driven programming, and rapid Windows desktop application development to many people who were not traditional systems programmers. Later, the popularity of Python, Ruby, PHP, and JavaScript also brought back slogans like "everyone can write programs" and "programming should become basic literacy" again and again.

These slogans do not sound unfamiliar today. The controversies they faced also look especially familiar today.

Regardless of the controversies, most of the abstractions above eventually became firmly established. Once established, most people's attention to the layer below shifted from "I need to fully control it" to "how can it better serve the layer above". From then on, every business developer no longer hand-wrote assembly every day, manually managed registers, or personally planned memory layouts. After high-level programming languages such as C appeared, most logic that can be written in C or a higher-level language would no longer be written in assembly.

However, we still need people who understand hardware and study assembly, because we need compilers. Abstraction and encapsulation do not work for no reason. Everything in C is built on top of compilers. Obviously, people who build compilers need to be sufficiently familiar with assembly, ABI, linkers, and target platform hardware. Looking back now, we obviously would not say that using C to write operating system kernels and system-level components made us lose control over hardware. On the contrary, most of the time, hand-written assembly is not necessarily more efficient than what a compiler generates. You do not know how hard gcc and clang are optimizing for you.

AI Agent Is a New Layer of Abstraction

If you think the ongoing software engineering revolution (a neutral term; I am only describing objectively that the way people develop programs is indeed changing dramatically) is unprecedented, makes you anxious, and makes you doubt the value of programmers, including yourself, or the future of the industry, then I recommend understanding AI Agents as this kind of thing: just like the birth of every previous layer of abstraction, today's AI Agents are raising the abstraction level of programming by one more layer.

We once told assemblers: turn these mnemonics into machine code.

We once told compilers: turn this C, Java, and TypeScript code into a lower-level executable form. As for what exactly it became, no one cares anymore.

Later, we told frameworks: I declare these components, these routes, and these data dependencies; please take full responsibility for organizing rendering, state updates, build artifacts, and runtime behavior. Countless people learn frontend development, but how many of them care how much work React and Vue do underneath our simple declarations? (Those who need to memorize interview questions for frontend jobs probably do.)

Now we begin telling Agents: I want to implement this feature, follow these constraints, remain compatible with these historical behaviors, and pass these tests.

If one day AI Agents (I cannot say whether that day has already arrived; at least for most business-code codebases, it has) can steadily take on a large amount of mechanical work such as implementation, migration, test completion, documentation lookup, context organization, and bug fixing, then they will be like the abstractions that eventually became established throughout history: they free human programmers from certain low-level details and let us move our energy to problems one level higher.

Control and the Future

Programmer Regression?

I dislike mindless Vibe Coding. I just want to firmly defend our software engineering. "Engineering" requires an engineering attitude. Engineering experience never disappears. Without requirement breakdown, architectural decisions, test strategy, code review, release rollback, and long-term maintenance, AI will only help you generate mountains of crap faster. Rights and obligations are extremely symmetrical in reality: when you do not use your brain to pay attention to a certain detail, you have no right, or no ability, to pay attention to certain corners. Just as you cannot hand over your entire travel plan to a travel agency while also hoping that every bit of transportation, dining, and accommodation along the way will exactly match your own wishes. Conversely, if relying on AI Agents means programmers are regressing and losing control over systems, then using high-level languages is regression, using frameworks is regression, using languages with GC is regression, using databases is regression, and using cloud services is also regression. Unfortunately, the history of software engineering did not unfold this way. We have always been pushing repetitive, stable, and formalizable parts downward, while pushing human attention toward more complex, more open-ended problems that are harder to fully formalize.

Control Over Software

Many people also worry that AI Agents will make us lose control over software, turning many parts into black boxes from then on.

Control over programs may be an abstract concept. Where did our "sense of control" come from in the pre-Agent era? After all, at that time, the vast majority of web programmers already did not care about hardware, operating systems, or memory management. Frontend developers using frameworks even stopped caring about DOM management. I think it came from having a "reliable" boundary that encapsulated all details below it. By "reliable", I mean we knew that JS code and the Vue framework would (almost) never go wrong, and that operating systems and browsers would (almost) never go wrong. Because they are time-tested infrastructure, we rarely encounter their bugs in daily development, so we naturally assume that nothing below this point will go wrong, and we only care about our own work above this encapsulation layer.

But AI Agents may not give us such a highly reliable psychological expectation. This is the core reason we feel they are "uncontrollable". We must admit that this layer of abstraction differs from all the abstractions above it: LLM is not a manually written conversion logic, and the internal principles of a LLM are a black box to humans. This is not even a bug that can be fixed. So the concern about "losing control over software" is absolutely reasonable.

But this unreliability is not entirely brought by the LLM itself. This layer of abstraction allows us to express things in natural language, so developers with uneven engineering quality can all participate in development. Some people sketch out a business picture that does not exhaust all details, or is semantically unclear, open to multiple interpretations, or may even contain contradictory business state machines, yet they do not realize it because they did not think carefully enough, or did not have the ability to think carefully enough. Without something like a compiler, when our own engineering quality is insufficient, we may not even receive hard error feedback. Then we break down, decide that AI Agents are unreliable, and try to abandon them. At that point, we find that our efficiency has dropped by more than 100 times. We cannot abandon them. We simply cannot.

Whether by writing detailed design documents, PRDs, or Skills, it currently seems that we still have many ways to harness LLMs. The instability of LLM, together with the efficiency improvement they bring, is absolutely worth it at least at the business-code layer. There is no silver bullet for harnessing them, and the methods are closely related to the specific business and technology stack you work with. As I said in the previous paragraph, the Agent era may demand even higher engineering quality from engineers. Agents merely make our attention in various directions less fine-grained, but they cannot let us completely block out concern for any particular piece of business or technology.

No matter which layer someone does engineering on, I think they can be called an "engineer": we are people who are familiar with and love the "layer" we work on, and who can flexibly dive into the layer below when needed to serve our own layer.