How to Use an LLM

If an LLM is a tool, then the obvious next question is:

How should we actually use it?

The answer is not “write better prompts.”

Prompting matters. Context matters. Model selection matters. Tools matter.

But none of these solves the fundamental problem by themselves.

The most effective way I have found to work with an LLM is to treat the interaction as an iterative, bounded process.

You establish a direction.

You let the model work.

You evaluate what happened.

Then you either continue or change direction.

It sounds almost disappointingly simple. I think that is precisely why it works.

1. Start With a Meaningful Problem

The first mistake is giving the model too much to do at once.

Instead of:

• In software: “Build my application.”
• In writing: “Write a novel about two people growing apart.”

Give it something meaningful but bounded:

• In software: “Implement the navigation component.” Then: “Implement the hero section.”Then: “Integrate user authentication.”
• In writing: “Draft the kitchen scene where they pack the first box.” Then: “Draft his solitary commute the morning after.” Then: “Audit the chapter for physical object continuity.”

The point isn’t to create microscopic tickets for their own sake.

The point is to create a useful boundary around a unit of work.

A good task answers five questions:

1. What are we trying to accomplish?
2. Why does it matter?
3. What does the model need to know?
4. What are the important constraints?
5. How will we know whether it worked?

This is the foundation of Task-Driven Design.

2. The Task Is the Interface

The task sits between human direction and AI execution.

Human
  ↓
Direction
  ↓
Task
  ↓
LLM / Agent
  ↓
Implementation

The human does not need to dictate every line of code or every sentence of dialogue.

The agent does not need to hold the entire project as one enormous, unresolved objective.

The task establishes the current boundary.

And that creates something invaluable: a point where you can stop.

3. Why Stopping Matters

Consider the alternative: the infinite chat stream.

Prompt
  ↓
Implementation
  ↓
Correction
  ↓
More implementation
  ↓
More correction
  ↓
More instructions

Without bounded tasks, the conversation becomes an ever-expanding stream of context.

Eventually it becomes impossible to tell:

• what the original goal was
• which decisions are still valid
• which assumptions have changed
• what has already been attempted
• why the current output looks the way it does

A task creates a clear stopping point:

Task
 ↓
Work
 ↓
Result
 ↓
Review

Stopping gives you directional control. It allows you to inspect what happened, prune away temporary conversational clutter, and decide what happens next.

4. Constrain the Destination, Leave the Path Open

An LLM needs enough information to establish a useful direction. But you don’t want to prescribe every step.

Consider:

“Write a scene about two people breaking up. Make her sad and make him defensive. Have her say these three lines, have him look at the floor, and make sure it ends at 800 words.”

versus:

“Draft the breakup scene in the kitchen. The tension centers on the division of shared objects. Capture only concrete physical actions and sparse dialogue. Zero narrator commentary.”

The first approach micromanages the path; the second firmly constrains the destination.

The same applies in software:

“Implement user login using existing session middleware. Preserve current route guards. Verify with existing tests.”

When you constrain the destination and leave the path open, you give the model room to discover simpler implementations, notice subtle edge cases, or uncover authentic character dynamics that you didn’t foresee.

Constrain the destination. Leave the path open.

5. Let the Model Explore

Once the destination is clear and the context is bounded, let the model do what it is uniquely good at:

Generate. Transform. Expand. Synthesize. Compare. Explore.

If you already know the one exact sentence or the single line of code that must be written, you don’t need a probabilistic engine — you need a keyboard.

The value of an LLM is that it can generate possibilities from across an enormous solution space.

The human establishes the problem space. The model explores within it.

6. Then Stop and Look

This is the step that is easiest to skip.

After the model produces something, ask:

Did we arrive at the destination we intended?

Not:

• “Did it follow all my words?”
• “Does this look impressive?”
• “Is the prose eloquent?”

A function can compile cleanly and still solve the wrong business problem. A drafted scene can be beautifully written and still feel like manufactured soap-opera melodrama rather than real life.

The evaluation must connect back to the actual objective.

7. Verification vs. Discovery

When evaluating work, two distinct things happen:

Verification asks:

Did we accomplish what the task asked us to accomplish?

Discovery asks:

What did we learn while doing it that changes what we do next?

Suppose an agent implements a feature and discovers that an existing component already supports the required behavior.

• Verification: The feature works.
• Discovery: We don’t need the extra abstraction we originally planned.

Or suppose an agent drafts a chapter where two characters divide their kitchen belongings.

• Verification: The dialogue is sparse and the scene follows the camera-and-microphone rules.
• Discovery: The silence around a chipped diner mug revealed an unspoken emotional invoice that completely alters how the next chapter must begin.

That discovery matters more to the project than the immediate execution. This is why completed work should leave a lightweight trail: recording what changed, what was verified, and what was discovered.

8. Human and Model Have Different Jobs

The ideal relationship is not:

Human tells the model every detail.

Nor is it:

Model figures out what to build.

A better division of labor is:

Human
→ Establishes direction and values
 
LLM
→ Explores possibilities and executes
 
Reality
→ Provides evidence (compilers, tests, emotional truth)
 
Human
→ Evaluates the evidence and reorients

The human does not need to control every implementation detail.

The model does not need to determine the project’s purpose.

Reality gets a vote.

9. The Chainsaw Lesson

Go back to the chainsaw.

You don’t operate a chainsaw by giving it one giant instruction: “Clear the forest.”

You select a tree.

You determine where you want it to fall.

You clear the immediate ground.

You make the cut.

You watch what happens.

If the tree begins leaning in an unexpected direction, you don’t yell at the chainsaw to try harder. You adjust your stance, change your cut, or step back and reorient.

The same principle applies to working with an LLM:

• Give it a bounded problem.
• Give it the context it needs.
• Let it cut.
• Watch the result.
• Verify what you can.
• Recognize when the direction is drifting.
• Change direction when necessary.

That is not a limitation of the technology. It is how you use a powerful tool.

The Next Question: Context

Once you understand how to direct an LLM through bounded tasks and iterative stopping points, another problem becomes unavoidable:

What information should the model have in the first place?

Because simply dumping everything you know into a single prompt doesn’t work.

That is the question of Context System Design: how we structure memory, modular skills, and external tools so that long-running projects remain coherent over time.

References & Context

• Task-Driven Design: Structuring work as discrete, testable units of intent.
• Directional Prediction Framework: The iterative loop of Constrain → Explore → Monitor → Reorient.