The "AI Replaced Programming" Myth Has a Load-Bearing Wall Problem

Ask AI to generate a button. It returns a chunk of JSX, or some HTML with an event listener. That code then enters a bundler, runs in a browser, triggers style calculation, layout, painting, and compositing, passes through the JavaScript engine, consumes memory, responds to input events, and lands on the process and I/O model provided by the operating system. Eventually it reaches the instruction stream of a chip. Along that chain, AI has completed the top layer: text generation. None of the layers below have disappeared. They have been encapsulated.

Many people mistake encapsulation for elimination. They mistake “rarely written by hand” for “no longer needed.” They mistake “a new abstraction appeared” for “the old layer can be deleted.” That is how we get claims that low-level work is a relic, or that AI will replace programming languages. The problem is not a matter of taste. It is a classification error. People confuse the life cycle of a specific tool with the ecological niche of the computing stack.

Punch tape to assembly changed the input method, not the computing base

Programming history has a favorite object of ridicule: punch tape. Mention it, and someone will smile at how primitive early programming must have been. But the shift from punch tape to assembly mainly changed the input medium and the toolchain. It changed how symbols were fed into the machine, and how the machine translated symbols into instructions. The computing model in the Turing-machine sense, primitive-level control flow, and the organization of state and rules were not uprooted at that step.

Computing models have expanded since then. Functional, logic-based, dataflow, GPU SIMD, and neural-network tensor computation have all grown into their own niches. Expansion is not replacement. Supplementation is not deletion. Mainstream control flow still depends on sequence, branching, loops, calls, and memory reads and writes. If someone says there has been no fundamental change in nearly ninety years, and means the Turing-machine model and mainstream control flow, that is broadly true. If someone says the entire computing model has not changed at all, that is inaccurate. Specific implementations keep changing. Abstraction layers keep accumulating. Low-level constraints keep bearing load.

That load-bearing role is not a matter of sentiment. It is a matter of the call chain. A front-end button request goes down to the framework runtime, the browser rendering pipeline, operating-system scheduling, memory management, graphics drivers, and the instruction set. A model-training job goes down to Python frameworks, C++ operator libraries, CUDA kernels, assembly-level optimization, GPU drivers, and hardware. You can orchestrate at a high level with natural language. Orchestration still has to land somewhere. Landing means consuming the layers below.

AI is an orchestration layer, not a replacement for the computing stack

AI is changing programming. Code completion, test generation, refactoring suggestions, and prototype building are changing the structure of tasks. Changing task structure is not the same as replacing the entire computing stack.

Most AI projects today still use Python or JavaScript as their project foundation. Training and inference still go down into C/C++, CUDA, assembly-level optimization, drivers, and hardware. So-called vibe coding is high-level orchestration on top of existing libraries, frameworks, runtimes, and toolchains. It generates a React component. That does not mean it has reimplemented React. It generates an inference script. That does not mean it has reimplemented the tensor runtime. You cannot, just to make a button, ask AI to rewrite everything from the script-parsing layer down to the operating-system layer, and then reimplement image rendering, rasterization, memory association, and I/O interaction from scratch. There is no need, and no point.

The reason is cost structure. Layers have their own jobs. The point of an abstraction layer is to keep people from having to think starting from transistors every time. But once an abstraction layer leaks, the low level comes back: performance bottlenecks, memory leaks, security vulnerabilities, compatibility problems, hardware adaptation, reverse engineering, real-time constraints, power constraints. Stronger AI and faster code generation make verification, debugging, performance, security, compatibility, and cost control more valuable, not less. Engineering is not over when code is written. Engineering is about running reliably under constraints.

Specific languages fade. Ecological niches do not disappear wholesale.

Specific languages do fade. They enter maintenance mode. They drop to zero in new projects. Perl’s share of new projects is nothing like its peak. COBOL mostly lives on in legacy systems. Fortran is rare in general business software. Some languages will die, and some tools will be replaced. The death of a specific implementation is not the death of an ecological niche.

What usually dies is a specific language, framework, or product. What survives is the need for a layer: a scripting layer for glue, a systems language for performance and resource control, assembly for extreme optimization and reverse engineering, RTL for describing hardware, and circuits and physical constraints for landing the design. C/C++ still occupies a large amount of infrastructure today: compilers, runtimes, databases, operating systems, embedded systems, graphics rendering, reverse engineering, and performance optimization. Inline assembly still appears in projects. Not because people are nostalgic. Because on some paths the compiler’s generated code is not enough, or analysis tools need to see instruction-level behavior.

Usage share is not necessity. New abstraction is not deletion. AI-generated code is not a replacement for the computing stack. One mistake in these three steps leads to the conclusion that the low level is a relic.

Cars shrank the horseshoe business. They did not make bearings and gears disappear.

The most easily confused analogy is “AI and programming languages are like cars and horse carriages.” After cars appeared, horse carriages did decline as the main means of transport. Cars did not make bearings, gears, electric motors, roads, steelmaking, rubber, and petrochemicals disappear. The more complex cars become, the more they depend on these underlying industries. You can build a brilliant robot. Unless modeling, materials, and manufacturing undergo a change that overturns the entire industrial system, you still cannot do without bearings and gears.

The same is true of the technology stack. On top are natural-language interaction, agents, workflows, and automatically generated code. Below are Python and JavaScript as the project foundation, frameworks and libraries, runtimes and inference engines written in C/C++, assembly and SIMD optimization, operating systems, drivers, memory management, I/O interaction, GPU and CPU instruction sets, RTL and chips, and circuit design and physical constraints. A button still lands on script parsing, framework rendering, browser or native UI, graphics rasterization, memory association, and I/O interaction.

A child can buy a bearing in a shop for a few dollars. That does not mean bearings are unimportant. It means bearings have matured to the point of cheap mass production. Maturity is not a disgrace. Maturity is infrastructure. People who sneer at the low level often have never opened a profiler, never soaked in a memory leak, and never cleared mines in a compatibility matrix. They see the new words in the news. They do not see the load-bearing walls in the call chain.

A hundred-story building cannot have floors one through ninety-nine knocked out

Someone will say: fewer people use the low level now, so doesn’t that mean it can be discarded? This inference misses a step. Fewer people use it may mean it has been well encapsulated. Well encapsulated does not mean nonexistent. When a building reaches the hundredth floor, you ask whether the lower floors can be knocked out because you do not like them, leaving only the hundredth. The lower floors are not outdated. They are load-bearing. You can renovate, replace the elevator, and change the façade. You cannot say that the ninety-nine floors below are a historical burden just because the view from the hundredth is good.

The stronger AI becomes, the more it exposes this fact: the more automatic high-level orchestration becomes, the harder low-level constraints become. Faster code generation makes verification more valuable. Easier prototypes make performance and security harder to fudge. AI replaces orchestration labor. It does not replace compilation, runtimes, operating systems, RTL, or device physics. Knocking out those lower layers and leaving only the topmost one is not an efficiency gain. It is system collapse.

Engineering judgment has to return to constraints, cost, reliability, verification, and compatibility. What works works. What does not work does not. Do not say “it should disappear” just because “I rarely use it.” Do not say “the ecological niche is gone” just because “it is rare in the news.” Do not say “the low level can be deleted” just because “there is a high-level abstraction.” Less use of the low level does not mean it can be discarded. Being encapsulated does not mean being eliminated. Specific languages fading does not mean the ecological niche disappears wholesale.

The higher the building, the more you need to know where the load-bearing walls are.