Prompt, context, harness: the three ages of LLM engineering

SAMI
July 8, 2026 6 mins to read
Share

A 5-part series — Part 1/5

Three years ago, knowing how to “talk” to a model was a rare and slightly magical skill. People traded screenshots of prompts that worked and passed around phrasings like cooking recipes. Andrej Karpathy summed up the era in a line that stuck: the hottest new programming language was English.

Today nobody serious introduces themselves as a prompt engineer. The word hasn’t vanished, it has shrunk. It now describes one small part of a much larger job. That shift in vocabulary tells a precise story about how we build systems on top of LLMs.

The story fits in three words: prompt, context, harness. Three disciplines, three questions, arriving in that order. The good news is that none of them killed the one before. The bad news is that plenty of teams think they’re doing context engineering when they’re still tweaking prompts, and they talk about harnesses without ever having built one.

Let me set the definitions cleanly. They frame the next four parts.

The prompt: how do I phrase my request

Prompt engineering is the craft of writing the instruction. Which phrasing, which example, which output format, which constraint. You work inside a single request and optimize that request for the best possible answer.

It was born in the GPT-3 rush, and it still matters. A badly written prompt gives a bad result even with the best model on earth. But the prompt has a structural limit: it only acts on what you write, not on what the model actually has in front of it when it answers. You can chisel the perfect instruction. If it’s buried under 12,000 tokens of useless history and three badly formatted documents, it counts for nothing.

Prompt engineering optimizes one interaction. It says nothing about the rest.

The context: what the model should see

“The rest” is exactly what context engineering takes over.

In June 2025, Karpathy reopened the debate: in any serious LLM application, the real skill is no longer the prompt but the context. Tobi Lütke, Shopify’s CEO, followed by defining it as the art of giving the model everything it needs for the task to be plausibly solvable. Simon Willison added the assembly angle: deliberately bringing together the system prompt, retrieved documents, history, and tool outputs into one coherent package. Anthropic put it in engineering terms: which configuration of context is most likely to produce the behavior you want.

Where the prompt asks “how do I phrase this?”, context asks “what does the model need in front of it, right now?”. You move from writing to information architecture. The context window becomes a finite resource to manage, with three ways to fail: too little information and the model hallucinates, too much and it drowns, conflicting information and it gets lost.

Gartner summed up the shift bluntly: context is in, prompts are out. That’s an overstatement, but the direction is clear. Prompt engineering was a craft. Context engineering is systems engineering applied to LLMs.

The harness: the system that keeps the loop running

Then 2026 arrived, with a third word.

In February, Mitchell Hashimoto put a name on something practitioners had been building without naming: the agent harness. The harness is everything around the model that isn’t the model. Tool execution, memory, managing the context at each step, persisting state across sessions, verification rules, orchestration. Vivek Trivedy at LangChain gave the sharpest version of it: if you’re not the model, you’re the harness.

The idea got concrete a few weeks later. When the Claude Code source leaked in late March, people found a codebase of roughly 512,000 lines of TypeScript where the model interaction itself is a tiny fraction. Everything else is the harness. The LLM is the smallest part of the system.

Harness engineering rests on a principle that changes how you work: every agent failure isn’t a prompt to retry, it’s a system problem to fix once. You don’t rerun and pray. You repair the mechanism. And because the harness is independent of the model, you can plug in a newer model without rewriting everything. The model becomes a swappable component.

Why all three still matter

You might expect a cascade of replacements, each discipline burying the last. That’s wrong, and it’s the most important point of this part.

Look at the diagram: the harness contains the context, which contains the prompt, which wraps the model. A bad prompt sabotages a good context strategy. A badly managed context derails the best harness. The three stack, they don’t substitute.

What changes is where your current problem lives.

  • Generating a well-turned email in one shot? A prompt problem.
  • Your assistant answers off-topic because it can’t see the right documents? A context problem.
  • Your agent runs across twenty steps, calls tools, loses the thread after ten minutes? A harness problem.

Diagnosing which layer the failure sits at is already half the work. It’s also a maturity ladder in disguise: most teams that call themselves advanced are still managing context on a single production agent. That’s not a criticism, just an honest snapshot, and the starting point for everything that follows.

What’s next

Over the next four parts, we go down into each layer. Part 2 revisits prompt engineering: what it really was, which techniques still earn their keep in 2026, and the wall it eventually hits. Part 3 takes on context engineering and managing the context window as a scarce resource. Part 4 takes a harness apart piece by piece, with Claude Code as the worked example. Part 5 assembles all of it into a maturity model you can use at work.

One thing to keep in mind until then. When something breaks in your LLM system, don’t ask first “what better prompt should I write.” Ask “which layer is the problem on.” That alone is a different way of thinking.

Practical resources

Leave a comment

Your email address will not be published. Required fields are marked *