Sign in Subscribe
Artificial Intelligence

The Psychological Barriers to Computation

The limits of my language mean the limits of my world.

Andre Fristo

Andre Fristo

— 16 min read
Share
The Psychological Barriers to Computation

"The limits of my language mean the limits of my world."

— Ludwig Wittgenstein

Table of Contents

  1. Speculation
  2. Debasing Mathematics
  3. Speaking to Machines
  4. The First Programming Language
  5. Jevons
  6. Learn More

Speculation

This piece is an attempt to explain why my information space is radically changing as of late and some speculation that can be made, given this explanation. First, we'll do a light historical review on general computation and discuss the associated barriers to access. Second, we'll discuss how LLMs have categorically changed this access. Lastly, we'll ponder what Jevons Paradox can tell us about the future.

I'd like to define one's "information space" as the collection of phenomena that are delivered by a digital information system. Stuff like videos on YouTube, voice messages on WhatsApp, documentaries on Netflix, music on Spotify or any other content delivered over the internet. This definition excludes analog sources, like a physical book, a physical painting or a speech given in person. It is bounded specifically to content delivered digitally.

As of late, there are three patterns cropping up in my information space:

  1. There is more content
  2. The quality of content is decreasing
  3. More people are accessing computation

For example, I notice myself questioning if content is generated by AI often. I'm skeptical of almost any written media containing an em dash. A significant portion of online content shared by my older family members is clearly AI generated, to their subsequent dismay. The other day I finished the last season of a show I'd been watching for years. Instead of pondering the conclusion, I was musing over whether or not the screenwriters had used AI to write the script, given how abysmal the last season was. It's the same pattern, more content and lower quality.

A Beksiński-esque rendition of the monkeys on typewriters thought experiment. Courtesy of OpenAI's image generation tool.

Separately, in my professional life, I've noticed more traditionally "non-technical" people engaging deeply with technical topics. A senior program manager asked me the other day about "inferencing" to categorize Jira stories. After a short discussion I discovered she was attempting to train an ML model to categorize Jira stories based on their contents. When I suggested using an agent, she responded that traditional ML would be faster and cheaper. She already had a curated data set, but wanted to discuss a few specific details around inferencing after training. She'd gotten this far with no formal ML background, using Claude to teach herself the core concepts as she worked to solve her own problem. Another pattern, access to computation.

It seems intuitive that all three patterns (more content, lower content quality and easy access to computation) are downstream of recent advancements in large language models and their corresponding products, but why? What does a program manager implementing a neural network and a crappy movie script for the final season of your favorite show have in common?

Debasing Mathematics

In the early 1900s, a man named David Hilbert was seeking to do a few things for mathematics:

  1. Show that mathematics could prove every true statement (i.e. 1+1=2)
  2. Show that mathematics is free of contradiction (i.e. 1+1=2 or 1+1=3, not both)
  3. Show that there is a mechanical procedure that can determine the truth or falsity of any mathematical statement (i.e. 1+1=2, true or false?)

A logician named Kurt Gödel published a paper outlining how mathematics cannot prove every true statement and that no mathematical system can show that it's free of contradiction. These two Incompleteness theorems proved that Hilbert's first two goals were unattainable.

However, the third question remained. Was there a mechanical procedure that could determine if a given mathematical statement was true or false?

Another man, named Alan Turing, attempted to solve the problem. In order to do so, he invented something called the "Turing machine". The machine consisted of:

  • A tape of ones and zeros
  • A head that can read one symbol at a time on the tape
  • A state register for the machine
  • A transition function with instructions to manipulate the tape

With this machine, Turing proved that no general procedure could exist. Some mathematical statements can never be mechanically determined true or false. Hilbert's third goal turned out to be unattainable. In the process of answering this question, Turing had incidentally described, abstractly, what any general computing machine could do.

The details of this machine are important to us, because they provided us the abstract design for the modern-day computer. The modern computer consists of four key components:

  1. A central processing unit
  2. Random access memory
  3. Storage
  4. Input/Output

The central processing unit modifies information, the random access memory stores it short term for basic operation, the storage holds information long term, and the input/output allows you to use the machine through a display, keyboard, terminal, or other medium.

These components come together to form a machine that generally manipulates information. Want to send instructions to a robot on the moon? You need a computer. Want to predict a market collapse? A computer can. Want to track the mating habits of an endangered sea turtle species? Grab a computer.

Just like a car, a computer doesn't actually do anything without an operator. The driver of a car "instructs" the system through mechanical input, using the two pedals and steering wheel to move the vehicle. A computer is typically "instructed" through a programming language. A set of logical steps that tell the components what to do.

Unfortunately, these instructions have made it difficult for most of us, historically, to leverage these machines.

Speaking to Machines

Now if you want a computer to do something, you need to tell it what to do. You have to be very, very specific about what you need, because computers are deterministic machines. They do exactly what you tell them, including carrying out any mistakes in your instructions.

Under the hood computers flip bits. Everything on your computer is a combination of ones and zeros. These are represented:

  1. In the CPU, voltages in transistors
  2. In RAM, charge in a capacitor, or a small loop of transistors
  3. In storage, magnetic orientations on a spinning platter or trapped electric charge in a floating-gate transistor

This means you need to tell it what bits to flip, when and how. You also need it to interpret what a specific collection of bits means. To call this a "pain in the ass" would be an understatement. Of course, technological advancement is often pursued to make our lives easier, and writing instructions for these machines was no exception. We sought to "abstract" them.

A scanning electron microscope image of transistors in a single memory cell on an Apple A4 microprocessor. Image by Chipworks, courtesy of the NISE Network, licensed under CC BY-NC-SA 3.0 US.

Imagine you have to move thousands of people throughout a skyscraper every day. Climbing a single flight of stairs is manageable. Climbing ninety of them, over and over, all day, is not. An engineer visits your building one day with a machine. You simply step inside a box, press a button for your desired floor, and the machine does the rest. Of course there are details like cables, counterweights, motors, failsafes all working together to get you there. These are articulated in a design schematic, but as the user of an elevator, they are irrelevant. Voilà, you've now abstracted the climb into a simple button press, and can now focus on other parts of your day. Over time, you forget the mechanics happening behind the wall, and come to view the button and ride as the only relevant part of the process.

The same process happened to computers over the past century, one layer of abstraction after another. We pursued this in two ways. The first made it possible to tell a computer to do almost anything, if you were willing to learn how. The second made it effortless to do one thing, with no learning required.

We can call the first type of abstraction we pursued general abstraction: tools that make it easier to instruct a computer to do almost anything, but that you have to learn to use.

Originally, computers were programmed by physically rewiring plugboards and flipping switches. Then came raw binary instructions, typed by hand, each one and zero at a time. Assembly language followed, swapping those numbers for words a person could actually read, like MOV and ADD, which a translator then converted back into bits behind the scenes.

Every subsequent advancement after that allowed a single instruction typed into a computer to do more work. Languages like FORTRAN, C, and eventually Python let you write one line, "if this, then that," and have the machine expand it into hundreds of steps on your behalf, handling memory and storage without being asked. When you sit down to write Python today, the majority of the complexity of writing machine instructions has all but disappeared. This general abstraction has made programming computers much easier, provided you're willing to learn a modern programming language.

A U.S. Army photo of the ENIAC being programmed. Using modern chip technology, this computer could now fit in the palm of your hand.

We've also pursued something I'll call specific abstraction: tools built for a narrow set of tasks that anyone can use without learning to program. When you schedule a meeting in a calendar app, browse the web, or build a spreadsheet in Excel, you're not writing instructions in a programming language, but you are running instructions someone else already built. The code that executes this program still exists, but there is an additional layer that makes it easy to run without knowing how to write a modern-day program yourself. Every one of these programs was built using general abstraction. Someone else wrote the code so you wouldn't have to. Turning on your computer, drafting an email and clicking send still executes machine code. The same capacitors and magnetic platters from earlier are still changing bits.

This specific abstraction allows someone without a programming background to still use a computer, albeit for a narrow, specific set of tasks. If you want to browse the web, you need a browser. If you want to trade stocks, you have to install a different app. If you want to make a video call, you need a third application. You can still use the computer, but you need specific programs for specific functions.

General abstraction gives you freedom. You can get the computer to do almost anything, but you still have to put in significant effort to learn a programming language. There's a reason that software engineering has been a lucrative career field over the past few decades. Writing these instructions is no easy task.

Examples of the two types of abstraction. General abstraction (left) lets you instruct a computer to do almost anything, but requires significant expertise. Specific abstraction (right) covers easy-to-use software applications built for a narrow set of jobs.

Specific abstraction gives up that freedom for ease. Most people can use the calendar application on their phone intuitively, but a calendar app will never browse the web, and a browser will never balance your budget. The elevator works the same way: it does one job, for anyone, with no training, while driving yourself lets you go anywhere, but only once you've learned how. For half a century, this has been the tradeoff when you use a computer. If you want to truly leverage its computation to do a broad set of tasks, you need to learn to program it.

Over the last few years, we've started developing tools and programs that blur these lines significantly, and the implications are enormous.

The First Programming Language

In late 2022, ChatGPT broke into mainstream awareness. The underlying large language model (LLM) had been available for years. OpenAI provided a simple user interface with chat functionality that made it easy to use for non-technical people, sparking another AI race.

What I want to focus on isn't the interface, but rather the model itself. The underlying mathematics that allows you to input text and get what seems like an intelligent response in return. These LLMs don't fit neatly into the usual categories of computation. They overlap with the components of modern computers and the Turing machine. They also straddle the line between the general and specific abstraction we talked about earlier.

In many ways, LLMs function very similarly to a classical computer. Within the model, the hardware and software that carry out its calculations are similar to a CPU. The context window (the amount of conversation the model can hold in view at once, for non-technical readers) functions similarly to RAM, as does the KV cache, the model's short-term scratch space while it writes a response.

A screenshot from an old Microsoft blog. This is a common sight for software engineers writing Python. I stared at a similar interface for months while building a graph of conspiracy theories from Reddit data.

The text the model was trained on, the model weights, and files containing persistent context for the LLM all function similarly to storage. Instead of having a desktop, the I/O system for the LLMs is often a chat window and a tokenizer/detokenizer that converts the text to vectors and back when processing your instructions. While these aren't exact, one-to-one relationships, they do highlight how large language models function similarly to a self-contained computer.

Large language models don't fit neatly into either category of abstraction we've discussed. In some ways they resemble general abstraction. In a single conversation you can cover a broad range of tasks, like editing an Excel sheet, revising a report, building a new software application or drafting an email. Many of these tasks previously necessitated knowledge of programming, but instead you provide instructions through natural language, as opposed to Python, C, or another programming-specific language.

In other ways, they resemble specific abstraction. Like your calendar app or a web browser, using an LLM requires no programming knowledge. You open it, type something in a box and it works. Just like those apps, there are product boundaries. It can only reach information it has been connected to. If someone hasn't built a connector for Google Calendar, your LLM isn't going to reorganize it. You're still constrained by a previous developer's work.

These two types of abstraction can even be combined. Because an LLM can write general-purpose code, you can reach general abstraction through specific abstraction. Remember the program manager from earlier, training a machine learning model to categorize Jira stories? She had no formal background in machine learning, and she never learned to write Python in the traditional sense. She described her problem in plain language, and the model wrote the code and taught her the concepts along the way. Until recently, that kind of reach required either years of practice or a team of engineers. The old set of tradeoffs only allowed you freedom or ease. Now you can get both.

Instructing an LLM to build a knowledge graph is much more intuitive.

Everything I described in the introduction traces back to a single innovation. LLMs take instructions in natural language, rather than code. A senior program manager with no formal training in machine learning built a classifier algorithm by describing her problem to Claude in plain English. The AI-generated posts my older family members share, and quite possibly that disappointing final season, exist for the same reason. Producing passable text, images and video no longer takes a skill, only a prompt. The outcomes may differ, but the underlying cause is the same. It has become dramatically easier to get a computer to do something, anything, so far more people are leveraging them to generate stuff.

Human beings added language to our evolutionary toolkit more than 100,000 years ago. It is the basic substrate we use to share and manipulate information together. Programming languages, by comparison, are about seventy years old. While a program manager may not intuitively understand Python, they will intuitively understand a prompt. If we view LLMs as general computational machines, like classical computers, then their programming language is natural language, which is how they deliver the reach of general abstraction without its steep learning curve. That comes with two key tradeoffs.

The first is probabilistic computation. Send the same prompt to an LLM ten times and you will get ten different answers. The answers may be very similar, but they will differ. Classical computers are deterministic. All code is ultimately a fixed list of exact instructions, and the same instructions with the same inputs produce the same output every time. This is why computers do exactly what you tell them, mistakes included. An LLM instead predicts what text should come next, with a deliberate dose of randomness, so the same request can lead down different paths with each invocation.

A knowledge graph mapping 84 major topics in philosophy, from its core branches (metaphysics, epistemology, ethics, logic) to the schools and thinkers within them. It took 22 seconds and a single prompt to generate this (including the Python code, input data and image).

The second is efficiency. Large language models are not efficient. They require significant, raw computational power to work. Adding up a column of numbers takes a laptop a fraction of a millisecond. Asking an LLM to do it requires billions of calculations. Because of the underlying mathematical structure of these models, they will almost always require far more energy.

LLMs give up precision and efficiency. In exchange, we get the ability to use natural language as machine instruction. This is their key advantage. Many of our most important inventions work by reducing a constraint that stood between us and a goal. Electric lighting reduces the constraints imposed by daylight. The telephone reduces the constraint of distance in conversation. Writing reduces our constraints on memory.

Large language models reduce the constraint of translation. They drastically reduce the mental effort of turning an idea into instructions a computer can follow.

Jevons

Suppose you have a resource. Let's take gasoline. If we made engines twice as efficient, would we burn more gasoline in total, or less?

Most people assume less. Twice the efficiency means half the gas per mile. But in 1865, the economist William Stanley Jevons observed that technological improvements that increased the efficiency of coal use led to increased coal consumption in many industries. Many assume that if we can do something more efficiently, we'll do less of it. Jevons found that sometimes we do more.

Efficiency lowers the effective cost of using something. If your engine burns half the gas, every mile costs half as much, so people drive more. Economists call this the rebound effect: the extra use eats some of the savings. Sometimes the rebound is partial and total consumption still falls. Jevons Paradox occurs when the rebound is greater than 100% and the extra demand more than cancels the savings. In our example, that happens if cheaper miles make people drive more than twice as far.

In the current zeitgeist, Jevons Paradox is generally applied to AI in two places:

  1. Computational efficiency
  2. Labor efficiency

Many argue that as AI gets more efficient and accessible, its use will skyrocket. Second, if AI makes workers more productive, demand for some jobs could grow instead of shrink. Most discussion centers on running models more efficiently (quantizing them, distilling larger ones into smaller ones, and so on) or on humans doing their jobs more efficiently with AI. These are valid applications of Jevons Paradox, but they miss a critical insight.

William Stanley Jevons (1835 to 1882).

Jevons observed one barrier to using a resource: price. Cheaper coal meant more coal burned, but price is only one barrier. Jevons Paradox is a specific example of a more general phenomenon common in product engineering: your product will be used more if it's easy to use. Jevons saw the effect through costs, and earlier in this piece we analyzed the same effect through a different psychological barrier.

I think the sheer magnitude of reaching computation in natural language is underappreciated. I'd argue a big part of the AI explosion over the last four years is that a psychological constraint got reduced.

Combine the psychological ease of using LLMs, incremental improvements to computational efficiency and the potential productivity gains in the labor market, and the prediction is simple. LLMs are inefficient, sure, but they're getting cheaper to run and easier to reach at the same time. The naive expectation is that efficiency gains mean less computation and less energy expenditure. Jevons says to expect the opposite. More computation, more hardware and power behind it.

Jevons isn't a law, though, and it comes with caveats. As NPR notes, economists mostly find that the rebound in modern energy markets is partial, and when farming got more efficient, we didn't start eating several times as much food. The bet comes down to elasticity, whether computation behaves like coal or like food. I'm betting on coal, because I can't see a hard ceiling on how much information we want or can process in the next few decades.

In a gold rush, the most reliable way to capitalize on the hype is not to pursue gold, but to sell pickaxes. Nvidia is the obvious example today, selling chips to the labs that train models. Given the psychological needs of the average consumer and the computational efficiency gains being pursued, I think there's a second kind of pickaxe: the device people use to run those models.

I'm skeptical of betting everything on massive flagship LLMs (GPT Astra, Claude Opus 5.5, etc.). Training one is extremely expensive, and the performance lead doesn't last long. Epoch AI estimates that the best open-weight models trail the closed frontier by about four months. The training for GPT-6 Astra likely cost at least half a billion dollars. Spending half a billion for a four-month lead in performance doesn't make economic sense in the long run. To be fair, closed labs still lead and plenty of customers pay for the best. I'm not predicting they fail, but the durable competitive moat looks like it's somewhere else.

My guess is that Apple sees it the same way. It hasn't shipped a flagship model of its own. Instead it signed a multi-year deal with Google to use Gemini for Siri, and it's reportedly distilling a large Gemini model into a smaller one that runs on Apple hardware. The play is to rent the frontier model and sell the device, as best I can tell.

It also fits that John Ternus, Apple's longtime hardware chief, replaced Tim Cook as CEO. This is the "general" Jevons bet. Every efficiency gain makes another task practical to run on the phone in your pocket, and more tasks means more usage, which means more demand for hardware that can handle it.

So what does a program manager training a neural network have in common with a crappy script for the final season of your favorite show? Easy access to computation. When it takes almost no effort to get a computer to do something, far more people do it. If Jevons is right, we've only seen the start of it.

Learn More