The Interface Trap

One of the things that looks most retro about 1950s sci-fi isn't the rockets; it's the robots. They are almost always humanoid, sitting at control panels, pushing buttons with metal fingers. It looks silly now because we know that if a computer wants to fly a spaceship, it doesn't need hands to press buttons. It just talks to the guidance system.

Yet, if you look at the current wave of "AI Agents," we are effectively building those 1950s robots.

We are building software that reads a screen, moves a cursor, and types into a terminal. We are building AIs that write Python or JavaScript, which then has to be interpreted or compiled, linked, and turned into machine code. We are automating the interface, not the machine.

It feels like a mistake. Or at least, it feels like one of those things that we’ll look back on in twenty years and wonder why we wasted so much energy on it, like optimizing horseshoes just before the Model T arrived.

To understand why, you have to look at the stack. At the bottom, you have physics (Silicon, voltage, 1s and 0s). Everything above that is a lie we tell ourselves to make the machine comprehensible. We built Assembly because binary is painful. We built C because Assembly is tedious. We built Python because C is dangerous. We built GUIs because command lines are intimidating.

Every single layer of abstraction, from the kernel up to the React button on your screen, exists solely for the benefit of human cognitive limitations. These layers are user interfaces for biology.

So why are we training artificial intelligence to use interfaces designed for biological intelligence?

When an AI writes code, it is essentially taking a machine-perfect concept, translating it into a clumsy human language (code), which is then translated back into machine instructions by a compiler. It’s like two mathematicians who speak the same language agreeing to communicate only via smoke signals. It works, but it’s remarkably lossy.

The argument for the current approach is that we want "humans in the loop." We want to be able to read the code the agent writes or see the button it clicks. And that makes sense for now. It’s the safe path. It’s the path of least resistance because all our training data comes from humans using human interfaces.

But it’s a local maximum.

The true application of automation shouldn't involve any layers of abstraction designed for humans. A true agent shouldn't need a browser; it should interact directly with the API (or better yet, the database state). It shouldn't need to write Python; it should manipulate the instruction set or the logic gates directly.

We treat "coding" as the high skill, but coding is just the manual transmission of computing. We are building AI agents that are really good at driving stick shift, when they should just be the engine.

There is a concept in design called skeuomorphism, like when a digital calendar has fake leather stitching, or a note-taking app looks like yellow paper. It helps users transition to new technology by making it feel familiar.

Right now, the entire field of AI agents is skeuomorphic. We are treating the AI as a "digital employee" who sits at a "digital desk" and types on a "digital keyboard." We are simulating the human workflow.

But the most powerful optimizations in history happened when we stopped trying to mimic the old way. A car isn't a mechanical horse; it doesn't have legs. A plane isn't a mechanical bird; it doesn't flap its wings.

The future of AI agents probably isn't a bot that can navigate a website or write a script. That is just automating the abstraction. The future is machines talking to machines in the language of machines. Raw state manipulation, binary, protocol-to-protocol.

The startups that realize that the current "agent" craze is just a UI layer over a much deeper, rawer potential, are the ones that will build the things that actually feel like magic. They won't be building better robots to push the buttons. They'll be rewiring the control panel.