How many layers of software does it take to put a letter on a screen?
You press a key. The USB controller fires an interrupt. The kernel's input subsystem translates scancodes. The event propagates to userspace. The window manager routes it. If you're in Electron (and you probably are), it passes through Chromium's event pipeline, into the browser's input handling, into a JavaScript onKeyDown handler, which updates a model, which triggers a virtual DOM diff, which eventually tells the kernel to update a framebuffer, which the GPU composites to a display.
A keystroke touches maybe a dozen abstraction layers before it becomes a letter you can see. This is how a modern text editor works. And a Z80 microcomputer from 1980 could do the same thing faster, because it had none of those layers.
So why do we have them?
This is the part most engineers don't think about. The abstraction layers in a modern software stack don't exist because the computer needs them. They exist because humans need them.
A UX designer shouldn't have to understand USB. A kernel developer shouldn't have to think about typography. A backend engineer shouldn't need to reason about GPU compositing. So we build layers — each one a clean interface between groups of people who think about different things. React exists so frontend engineers don't have to manually diff DOM trees. ORMs exist so application developers don't have to write SQL. Docker exists so app developers don't have to think about infrastructure.
Every layer is a translation boundary between humans. And every layer has a cost: performance overhead, complexity, dependencies, things that can break, things you have to learn, things you have to keep up to date.
We accept this tradeoff because the alternative — every engineer understanding the full stack from silicon to pixels — doesn't scale. The layers are a coordination mechanism for human teams. They always have been.
Large language models understand all the layers simultaneously. An LLM can reason about USB protocols, kernel interfaces, DOM manipulation, SQL queries, HTTP semantics, and GPIO pins in the same conversation. It doesn't need React to manage UI complexity because it can hold the complexity in context. It doesn't need an ORM because it can write the SQL directly. It doesn't need a framework because it can see the whole path from intent to implementation at once.
This suggests something radical: for any specific task, an LLM could find the direct path from what you want to what the hardware and services actually need — skipping every layer that exists purely for human coordination.
Not removing the layers. Never generating them in the first place.
Say you have a Bluetooth button on your desk and a smart lightbulb on your network. You want the button to control the light — but not just on/off. You want a hold for 2 seconds to start a rhythm game where the light plays a pattern and you tap it back.
Today's approach: Install Home Assistant on a Linux box. Set up MQTT. Configure a Bluetooth integration. Configure a light integration. Write an automation in YAML. Add a custom script for the game logic. Debug why the Bluetooth pairing broke. Spend a weekend on it.
Every one of those components (Home Assistant, MQTT, the integrations) is a layer that exists to translate between humans who build different things. The Home Assistant developers don't know about your specific button. The MQTT protocol doesn't know about rhythm games. So you, the human, become the glue between all these general-purpose tools.
The direct path: The button can send specific bytes over Bluetooth. The light can receive commands over its network API. That's it. Those are the only real interfaces. Everything else in the traditional approach is middleware — human coordination tools that an LLM doesn't need.
If an LLM can reason about both endpoints, it can generate the exact code to read those Bluetooth bytes, interpret a 2-second hold, generate a rhythm pattern, send it to the light's API, listen for taps, and score the response. Maybe 100 lines of code. No MQTT. No Home Assistant. No YAML. Just the direct connection between the two real things.
You want a recipe sharing app — post recipes, search by ingredient, save favorites.
Today's approach: Pick a framework (Rails, Next.js, Django). Add a database with an ORM. Add an auth library. Add a search integration, maybe Elasticsearch. Add a CSS framework. Add a build pipeline. Each of these tools solves every possible version of the problem it addresses. You're using maybe 5% of each one.
The direct path: Your app needs to listen on a few HTTP routes, run a handful of SQL queries against Postgres, and return some HTML. That's the actual surface area. The LLM can find this path directly:
What comes out might be a single file — a few hundred lines that opens a socket, matches URLs, runs SQL, and returns HTML. It looks like a web programming tutorial from 2003. But it does exactly what you need, it's fast because there's no framework overhead, and you can read every line and understand what it does.
You didn't pick a stack and conform to it. You described what you wanted and the minimal path was found for you.
Here's the metaphor that ties it together.
In science fiction, a wormhole punches through the normal fabric of space to create a direct path between two distant points. It takes enormous energy to create one. But once it's there, you can build a gate around it — and then ships just fly through forever.
That's what's happening here.
The LLM is the enormous energy. It's expensive, it's slow, it's overkill for the runtime. But it's uniquely capable of finding the path — interpreting your intent, understanding the capabilities of both endpoints, and figuring out the direct connection through all the layers that would normally sit between them.
Once it finds the path, you print it. Now it's just code. Tight, bespoke, no unnecessary abstractions. The LLM is no longer in the execution loop. The wormhole stays open, but it's infrastructure now. Ships fly through.
That printed code runs at the speed your hardware allows — no framework tax, no middleware overhead, no layers that exist to help humans who are no longer in the loop. The LLM found the wormhole. The code is the gate. The gate is permanent.
The implications go further than saving some dependency installs.
For building software: Instead of choosing a stack and building within its constraints, you describe what you want and get the minimal implementation. Frameworks stop being the starting point. They might stop being necessary at all for many applications.
For performance: Bespoke code with no unnecessary abstraction layers can be dramatically faster than the same behavior implemented through general-purpose frameworks. Not because it's better optimized — because there's simply less in the way.
For understanding: A 300-line single-file app is easier to reason about than the same behavior spread across a framework, an ORM, a router, a templating engine, and their respective configuration files. The code does obvious things in an obvious order.
For iteration: Want to add a feature? You don't go searching for a compatible library. You describe what you want, the LLM finds the new direct path, and you print an updated version. The tool shapes itself to your problem every time, instead of you shaping your problem to fit the tool.
At the extreme end: If every application on your computer were built this way — bespoke, minimal, direct paths to the hardware and services they actually use — you wouldn't have an operating system in the traditional sense. You'd have a collection of wormholes. Each one a direct connection between human intent and machine capability, with nothing in between except the gates that keep them open.
That might sound like science fiction. But a Bluetooth button talking to a lightbulb through 100 lines of code instead of an entire home automation stack? That's this weekend.
Every abstraction layer in modern software exists because humans need help coordinating with other humans across complexity. LLMs don't have that limitation. They can see the whole stack at once.
This means that for any given task, there's a direct path from what you want to what the machine actually needs to do — a path that skips every layer that was only there for human reasons. The LLM finds that path. You print it. It becomes permanent.
We've been building pyramids — piling more material on top to compensate for the fact that the lower layers can't understand the upper ones. The wormhole approach says: punch through, find the direct connection, build the gate, and move on.
Less material. Almost all air. And it actually works.