How to Use LLMs Efficiently

Introduction: Giving Structure to a Shapeless Tool

As engineers, we are used to deterministic systems. Given the same input, we expect the same output. When this does not happen, we assume that something is wrong: an uncontrolled state, a hidden dependency, or a bug waiting to be found.

LLMs challenge this instinct. The same prompt can produce different answers, and a small change in context can completely alter the result. A prompt does not strictly define what the model will produce; it only guides it toward a range of possible outputs. This makes the technology feel less like traditional software and more like a system that must be observed, guided, and corrected.

Physics went through a much deeper version of this discomfort when quantum mechanics introduced probability at the heart of its predictions. The theory worked remarkably well, but it challenged the deterministic view of the world that scientists had relied on until then. With LLMs, the stakes are obviously different, but the practical problem feels familiar: how do we control an unpredictable system?

This article is not an attempt to provide a definitive method or another collection of perfect prompts. Its goal is to present the foundations of a more effective way to work with LLMs: breaking problems into clear stages, managing context, reviewing outputs critically, and building a feedback loop around the model. It is not the complete answer, but it is a useful place to start.

The prompt is not the method

Good prompts help. Of course they do.

Being articulate and specific helps. Giving examples helps. Defining the expected output helps. If you ask the model to write code, explaining the constraints of the project matters: the frontier models are excellent at understanding intention.

But this is only the beginning. You also need taste: the ability to know what you want, stay critical of the output, and steer the model toward something better.

You are not a wizard looking for the right spell anymore. You are the architect trying to build Hogwarts: a place where you can confidently build the best things possible. And it takes time to get there. The truth with LLMs is that you can often do better, but not always faster.

The real question is: what workflow makes the model useful without letting it take the wheel?

The workflow matters more than the prompt

To build an efficient workflow, let's go back to the roots of building something. It usually comes down to four simple questions:

1. What problem am I trying to solve?
2. What is available in my environment that could help me solve it?
3. What should I do with those tools?
4. Is the result working?

Later, you can ask how to make it better, how to make future changes easier, and when to stop and ship.

In practice, I split it like this:

1. Requirements: clarify what we are trying to build or decide.
2. Exploration: look at the state of the art, possible tools, approaches, constraints, and tradeoffs.
3. Plan: make design decisions and write an implementation strategy.
4. Build and review: execute, test, criticize, iterate.

This is pretty boring, right? Personally, I love boring, simple, efficient truths. Humans are very good at making unnecessarily complicated systems.

The mistake of prompt engineering is trying to compress everything into one heroic prompt.

One thread can be about requirements. Another can be about technical options. Another can produce the implementation plan. Another can focus on coding.

For example, if I want to build a small feature, I try not to start with: "Build this feature."

I start with: "Help me clarify the requirements." Then: "Given those requirements, what are the possible approaches?" Then: "Turn the best option into an implementation plan." Only after that do I ask for code.

It sounds slower, but it prevents the model from sprinting confidently in the wrong direction.

Each step has a goal. Each step produces an artifact. I strongly recommend Markdown for this. The artifact becomes something you can read, judge, edit, and reuse.

If you are not deleting and rewriting parts of those artifacts, something is wrong. The trace forces you to slow down and be critical of the work being produced.

This is where real-world experience helps tremendously. The model can produce options. You still need to know which ones have a bad smell.

Context is fuel, not memory

A few months ago, I looked more closely at how chat applications pass context to LLMs. I was curious about what people casually call memory when interacting with a model.

The useful realization is simple: the continuity of the conversation is more constructed than most users realize.

In most chat interactions, the model does not remember like a human. It does not sit there with a stable inner mental state, patiently keeping track of your project. Each answer is generated from the information made available to that request.

From the user’s point of view, the conversation feels continuous. Under the hood, continuity is reconstructed again and again by sending relevant information back into the model: recent messages, retrieved context, project instructions, user preferences, system instructions, files, tools, and your current question.

This is powerful, but it has a cost.

Context fills up. Noise accumulates. Old decisions, outdated ideas, failed attempts, and irrelevant details stay in the conversation. The model starts trying to satisfy too many ghosts at once.

This is why I do not like very long LLM conversations for serious work.

As a personal rule of thumb, if a chat goes beyond fifteen or twenty meaningful prompts, I usually ask the model to write a synthesis: what we decided, what matters, what should be ignored, what the current state is, and what the next step should be.

Then I start a fresh conversation with that synthesis.

A good synthesis is not a generic summary. I want it to tell me what we decided, what constraints matter, what ideas we rejected, what vocabulary we are using, and what the next action is.

Sometimes I literally ask: "Write the handoff note for a fresh conversation. Include only what is still relevant."

It feels slower, but it is usually faster. Less mud in the context. Less confusion. Better decisions.

Make the model a sparring partner

Another common problem with LLMs is the yes-man effect.

By default, many chat models and product settings tend to be agreeable. They praise your ideas. They validate weak plans. They explain why your half-baked intuition is actually brilliant. This feels nice for about two minutes and then becomes dangerous.

A useful LLM should not only complete your thoughts. It should sometimes attack them.

You can explicitly ask for this:

Challenge this idea. What am I missing?

Give me the strongest argument against this plan.

What would an experienced engineer criticize here?

What tradeoffs am I ignoring?

If this fails, what will probably be the reason?

The difference is immediate. If I ask, "Is this plan good?", the model often becomes polite. If I ask, "Assume this plan fails in production next month. What was the most likely reason?", the answer becomes much more useful.

This changes the interaction.

You stop using the model as a text generator and start using it as a sparring partner. Not because it is always right, but because it can help you see angles you were not looking at.

One recent example comes from Peter Steinberger, the developer behind OpenClaw and founder of PSPDFKit. In OpenClaw, files like SOUL.md help define how an assistant should behave: its style, boundaries, standards, and sense of continuity between sessions.

The name is theatrical, but the underlying idea is practical. You can write down the kind of assistant you want once, then reuse it: more critical, less sycophantic, more direct, less generic.

The exact file matters less than the artifact. Whether you call it SOUL.md, AGENTS.md, or project instructions, the point is to make the interaction shape explicit.

The model will not magically know that you prefer blunt criticism over polite encouragement. You have to say it. Better yet, write it down once and reuse it.

Create a feedback loop

The best LLM sessions feel less like asking a question and more like running a loop.

You write an idea. The model reacts. You judge the reaction. You correct the model. It proposes a structure. You reject part of it. It gives alternatives. You pick one. It produces a draft. You criticize the draft. It rewrites. You compare. You keep what works.

This takes longer than the fantasy version.

But the fantasy version is mostly bullshit.

The goal is not to get something instantly. The goal is to get something good. And good still requires taste, pressure, revision, and judgment.

That is the part many people miss. LLMs can make you faster, but their real value is not speed. Their real value is leverage.

They let you operate at a higher level. You can spend less time staring at a blank page and more time deciding what should exist. Less time writing boilerplate and more time shaping architecture. Less time producing raw material and more time evaluating it.

But only if you stay awake.

If you outsource the whole process, you get average output with your name on it. If you stay in the loop, you get a tool that amplifies your thinking.

Conclusion

LLMs reward clarity.

They expose whether you can define a problem, explain constraints, judge an answer, and make decisions. If your thinking is vague, the model will usually give you vague confidence back. If your process is structured, the model becomes dramatically more useful.

That is why I do not think the future belongs to people who memorize prompt templates.

It belongs to people who can think clearly, write precisely, organize context, challenge outputs, and iterate without falling in love with the first answer.

The real upgrade is not writing faster.

The real upgrade is operating at a higher level.