Thought Completion Engines

In my first series on LLMs, I described them as “document completion engines.” It was a useful frame for breaking the chat illusion, recognizing that these models aren’t “talking” to us, but are instead sampling from a probability distribution to complete a sequence of tokens.

But as models have shifted from pure language generation to sophisticated reasoning, my mental model has evolved. I find it more useful now to think of them as “thought completion engines.”

This isn’t technically accurate, under the hood, they are still next-token predictors. But technical accuracy is often a poor guide for practice. Treating a model as a thought completer changes how you architect your prompts and how you judge the results.

From Document to Trajectory

The original “document completion” frame taught us that if you start a document with a specific style, the model will maintain it. If you provide a list, it will continue the list.

“Thought completion” takes this a step further, implying the model is extending the trajectory of your reasoning.

If your initial thoughts are muddled, the completion will be muddled, and if you provide a clear logical path but stop halfway, the model often lands exactly where you were headed. It isn’t just completing a text format, it is sampling from the probability space of where that specific line of thinking leads.

Thomas Osmonson describes this as “a surface you think against.”¹ The model isn’t just a tool for generating output, it is a mirror for your own clarity of intent.

The 3D Object Metaphor

One of the most powerful ways to think about “thought completion” comes from Osmonson’s 3D object metaphor.

Imagine what you are trying to communicate as a 3D object floating in space. Each time you describe it in a prompt, you are putting a single light on one face of that object. If you only describe it one way, the model only sees one face, and the “completion” might go off in a direction you didn’t intend because it can’t see the rest of the shape.

The goal of prompting is to add enough lights from enough angles that the whole object becomes visible.

You don’t need to be perfectly precise in a single sentence. You need to articulate the same intent from multiple angles, describe the goal, describe the constraints, describe the “vibe” of the solution, and describe what the solution isn’t. The model sees the shape formed by the intersection of those descriptions and completes the thought accordingly.

Modeling the Model

Working effectively with these models requires a specific kind of empathy. Not human empathy, but a “modeling of the model.”

You have to put yourself in the agent’s position, to understand what it “sees” given the context you’ve provided. If the model goes off the rails, the question isn’t “Why is it stupid?” but “What in the context I provided made this trajectory seem more probable than the one I wanted?”

Sunil Pai notes that “if you ask an agent for a vibe, it will give you a vibe-shaped completion.”²

The real skill is the ability to visualize where the model is in its thinking, understand why it went in a particular direction, and then adjust your framing by adding another “light” to the 3D object rather than just adding more words.

The Domain Expertise Paradox

There is a catch to the “thought completion” abstraction. It works best when you already know how to think about the problem.

A common counterpoint from people deep in AI is that these models feel the most powerful when you’re sitting on top of thousands of hours of hard-won domain understanding.⁴ You can recognize a “good” completion because you know what the target looks like.

Without that expertise, you are just accepting whatever trajectory the model takes, and instead of thinking against a surface, you are just following a random path. The abstraction of thought completion is a force multiplier for existing skill, not a replacement for it.

Practical Implications

How do you use this?

Start with the shape, not the specifics: Before you worry about the exact syntax of the code, make sure the “thought” you are presenting is coherent.
Sample the trajectory: If the first response is wrong, don’t just tell it “fix it.” Look at why it thought that was the right path and restart from the bad prompt.
Adjust by adding angles: If the model missed a constraint, don’t just repeat the constraint. Explain why that constraint exists in the context of the larger 3D object you are trying to illuminate.
Use the dialogue to refine the thought: Often, seeing the model’s completion will help you realize that your own thought was incomplete. The dialogue is where the planning happens.

Treating LLMs as thought completion engines moves us away from “prompt engineering” as a collection of magic spells and toward a more durable practice of clear communication and system design.

Thomas Osmonson, “More Thinking, Not Less”. “In the large they’re closer to ‘thought completers’.” ↩
Sunil Pai, “Where Good Ideas Come From”. “If you ask an agent for a vibe, it will give you a vibe-shaped completion.” ↩
Geoffrey Huntley, “LLMs are Mirrors of Operator Skill”. “Someone can be highly experienced as a software engineer in 2024, but that does not mean they’re skilled as a software engineer in 2025, now that AI is here.” ↩
This tension is well captured by the “Cryptowriter” counterpoint: “Who’s gonna tell him that the reason why it’s super easy for him to use Claude effectively is the thousands of hours he spent mastering coding?” ↩