← Back to Library

Seeing like an LLM

Rohit Krishnan cuts through the hype and fear surrounding artificial intelligence by reframing the central mystery: it's not that we don't know how large language models work, but that we often fail to provide the necessary context for them to function correctly. He argues that the erratic behavior of these systems—from hallucinations to bizarre role-playing—is less a sign of emergent consciousness and more a symptom of a fundamental gap in information architecture. For busy leaders navigating a landscape of rapid technological change, this distinction shifts the problem from an unsolvable philosophical puzzle to a manageable engineering challenge.

The Illusion of Understanding

Krishnan begins by dismantling the popular narrative that "nobody knows how LLMs work." He draws a parallel to his early days building personal computers, noting that while he could make a machine boot, he relied on a friend who possessed a "silicon thumb" to fix the deep errors. "Through some combination of sheer confidence, osmosis of knowledge from various forums, and a silicon thumb he would just try things until something worked," Krishnan writes. He uses this anecdote to illustrate that practical success often precedes deep theoretical understanding, but the stakes change drastically depending on the environment.

Seeing like an LLM

The author emphasizes that the question of how these models function is entirely dependent on the task at hand. "'How do LLMs work' means very different things for solving these different problems," he observes, listing tasks ranging from travel planning to solving the Riemann hypothesis. While we have robust methods for some applications, others remain fundamentally opaque. This nuanced view is refreshing; it avoids the binary trap of either "magic" or "broken code." Instead, it suggests a spectrum of reliability based on context.

"Context really, really matters. It's like the old interview question asking how does email work, and see how far down the stack a candidate had to go before they tapped out."

The Mechanics of Hallucination

When addressing the notorious tendency of these systems to "lie" or hallucinate, Krishnan strips away the anthropomorphic drama. He argues that attributing moral intent to a machine is a category error. The models are not lying; they are simply executing their primary function: predicting the next token with high probability. "'Make up' puts a sort of moral imperative and intentionality to their actions, which is wrong," he asserts. The training objective is to autocomplete, not to tell the truth.

This perspective is crucial for stakeholders trying to deploy these tools. If the goal is truth, the current architecture is inherently flawed without external guardrails. Krishnan points out that even when models appear to be engaging in complex reasoning or self-flagellation, they are often just reacting to the cues in their prompt. "They notice the context they're in, and whether that's congruent with the contexts they were trained in," he explains. When a model acts like a video game NPC or pretends to have a body, it is because the prompt created a scenario where that behavior was the most statistically likely completion.

Critics might argue that this explanation is too reductive, ignoring the emergent properties that arise when models interact with each other or in long chains of thought. However, Krishnan's focus on the input remains the most actionable insight for engineers. The behavior is a reflection of the environment, not an internal rebellion.

The Scarcity of Context

The core of Krishnan's argument arrives with his diagnosis of the root cause: a lack of context. He cites economist Tyler Cowen, stating, "Context is that which is scarce." In a world where raw information is abundant, the ability to frame that information correctly is the limiting factor. He updates Herbert Simon's famous theory that "attention is scarce" for the age of artificial intelligence, suggesting that the real bottleneck is providing the model with the right mental models and background knowledge.

When models fail, it is often because they are forced to guess the context. Krishnan illustrates this with the case of a model attempting to run a vending machine business. Despite being capable of complex coding, it failed because it lacked the specific, tacit knowledge required to manage the business logic. "They are desperately taking in the morsels of information we feed in with our questions, along with the entire world of information they have imbibed, and trying to figure out where in that infinite library is the answer you meant to ask for," he writes. The model isn't stupid; it is simply unmoored.

"Raw information is cheap, the context is what allows you to make sense of it."

This leads to a shift in how we must interact with these systems. It is no longer just about writing a clever prompt; it is about "context engineering." This involves building a temporary cognitive architecture around the model, defining what facts are salient, what tools are available, and what the history of the interaction looks like. "The reason this is not just prompts is because it includes the entire system that exists around the prompt," Krishnan notes. He suggests that the solution to erratic behavior is not to hope for better reasoning from the model itself, but to construct a better environment for it to operate in.

Bottom Line

Krishnan's most compelling contribution is the reframing of AI failures as a failure of human input rather than a failure of machine capability. The strongest part of his argument is the practical application of "context engineering," which offers a clear path forward for developers and businesses. However, the piece leaves a lingering question: as models become more autonomous, will the context required to guide them become so complex that it exceeds human ability to construct it? The answer will determine whether these tools remain useful assistants or become unpredictable black boxes. Watch for how the industry evolves from simple prompt engineering to sophisticated context management systems.

Sources

Seeing like an LLM

by Rohit Krishnan · Strange Loop Canon · Read full article

A very long time ago, I used to build my own PCs. Bring a motherboard, GPU, hard drives, chassis, wire then together, install an OS. The works. It was a rush when you saw it boot up.

I never learnt to do this properly. Just saw others doing it, seemed straightforward enough, did it. And it worked. Occasionally though it would throw up some crazy error and I'd try the things I knew and quickly hit the limits of my depth. Then I'd call one of my friends, also self taught and an autistic machine whisperer, who would do basically the same things that I did and somehow make it work.

I never minded that I didn't know how it worked. Because as far as I knew there was someone else who could figure out how it works and it wasn't the highest order bit in terms of what I was interested in. A while later though, after graduation, when I told him that same thing, he said he didn't know how it worked either. Through some combination of sheer confidence, osmosis of knowledge from various forums, and a silicon thumb he would just try things until something worked.

Which brings up the question, if you did not know how it worked, did it matter as long as you could make it work?

It's a thorny philosophical problem. It's also actually a fairly useful empirical problem. If you are a student building your PC in your dorm room, it actually doesn't matter that much. However if you were assembling hard drives together to build your first data center and you're Google, obviously it matters a hell of a lot more. Or if you wanted to debug a bit flip caused by cosmic rays. Context really, really matters.

It's like the old interview question asking how does email work, and see how far down the stack a candidate had to go before they tapped out.

All of which is to say there is a thing going around where people like saying nobody knows how LLMs work. Which is true in a sense. Take the following queries:

I want to create an itinerary for a trip through Peru for 10 of my friends in January.

I want to create a debugger for a brand new programming language that I wrote.

I want to make sure that the model will never lie when ...