Great Context, Great Output

I've had this conversation maybe a hundred times. Friend says, "I tried Claude, it's not that good." I ask what they tried. They show me. The prompt is six words and contains no context. Of course the output was mediocre. They were trying to draw water from an empty well.

Ninety percent of the time someone tells me AI doesn't work for them, the actual diagnosis is: they didn't give it any context. Claude isn't psychic. Claude is a powerful pattern-completer that needs the right pattern to start from. Bad context in, bad output out, every single time.

Prompt vs. context, the difference

A prompt is the immediate ask. "Write me an article about electrical engineering in hotels."

A context is everything around that ask that lets the AI know what good looks like. "Here are three articles I've already published on electrical engineering. Here's my brand voice (warm, technical, plain-language). Here's my audience (hotel owners, mostly non-engineers). Here's the angle I want to take. Now write me an article about why electrical engineering preparation matters for hotel resilience."

Same task. Two completely different outputs. The first one will be generic AI slop. The second will sound like you wrote it yourself, on a good day.

That's the leverage. Context engineering, not prompt engineering, is where the work is.

Bad context, bad output, a real story

I'll keep this generic, because most of the bad-context stories look the same. Operator opens Claude. Asks for a launch announcement. Provides no audience description, no tone target, no examples of past announcements, no brand context. Claude produces something competent and forgettable. Operator concludes Claude isn't good at copywriting. Operator goes back to writing it themselves.

The real story is that Claude was given five percent of the information needed to do the job, and produced output proportional to the information. The model was working correctly. The captain was undertrained at the task of being a captain.

Great context, great output, a real story

HBOT Finder, mid-2026. Goal: research and publish pages for new cities in the hyperbaric oxygen niche. Context provided (and reused on every nightly run):

• The Command Kit explaining what HBOT Finder is and who it serves.
• A research framework saying what data we need per city, what page structure to produce, what SEO and AEO targets to hit.
• Example pages already published, so the format, tone, and density were anchored.
• A list of common pitfalls (how previous research had been wrong) that gave Claude a checklist of what to verify.

With that context, Claude produces city pages that pass review most of the time. Without it, same exact prompt, no context, it produces something that takes 45 minutes per page to clean up. Same model, same prompt, same time of day. The only difference is the context the captain wrote once and reused forever.

The Naur connection, programming as theory building

Peter Naur wrote a paper in 1985 called "Programming as Theory Building." It's the most important essay in operator history that nobody operating reads. The thesis:

A program is not its source code. A program is a shared mental construct (a "theory") that lives in the minds of the people who built it. Source code is a shadow of the theory. Documentation is incomplete. Rebuilding the system requires rebuilding the theory.

Apply this to AI work and the implication is enormous: the theory is what gives Claude context. The CLAUDE.md is the explicit articulation of the theory. The wiki entries are the entity-level theory. The folder structure itself encodes part of the theory. When you write Command well, you're externalizing the theory of your business in a form Claude can read.

If you can't articulate yourself well, you definitely shouldn't expect Claude to articulate itself well on your behalf. You're playing telephone with the AI, and the AI's output is only as good as what you whispered to start.

(I'll write a longer essay specifically on Naur's paper at /log/programming-as-theory-building, but for now, the core insight is what matters.)

How to build context over time

Context engineering is a slow accumulation, not a flash of insight. The mechanics:

1. CLAUDE.md as the spine. Brief, explicit, high-signal. Updates weekly with what you learned.
2. Wiki entries for every recurring entity. Each venture, client, person, concept gets a page that compounds with new information.
3. Inline turn-by-turn context. When a single ask needs more, paste the relevant wiki entry into the chat alongside the prompt.
4. Examples in the folder. When you produce something good, save it to the folder so future prompts can reference it. This is how your "voice" stays consistent across hundreds of pieces.
5. Auto-memory (MEMORY.md). As of March 2026, Claude maintains its own memory file alongside your CLAUDE.md, capturing patterns it learns about your preferences. You don't write this; you read it occasionally and correct it if it's wrong.

Each layer adds context. Each rotation of the Captain's Flywheel sharpens it. Three months in, your context is genuinely yours, and the output Claude produces feels like an extension of you, not a generic AI.

The inverse, bad prompts produce bad output too

Context isn't a magic bullet. Sometimes the prompt itself is the problem. "Help me with marketing" is a bad prompt regardless of how good your context is. "Draft three subject lines for the Captain's Log issue #042, focused on the Captain's Flywheel methodology, in Max's voice" is a good prompt, and combined with great context, produces useful output.

Both layers matter. Great context, great output, and a clearly-stated ask. Stack the leverage.

Why beginners overestimate prompt engineering

Because it's visible. Prompts are sexy. Long Midjourney-style prompts with words like "ultra-detailed cinematic 8K masterpiece" feel like you're doing real work. Saving them, sharing them, comparing them, that's where the early AI culture lived.

Context engineering is unsexy. It's organizing folders. Writing CLAUDE.md. Naming files correctly. Drafting wiki entries that nobody reads except your AI. There's no Twitter clip in it. There's no shareable artifact. There's just the slow compounding of better and better output every week.

Almost everything that's actually critical in operations turns out to be unsexy. Great context is the same.

MVC, Minimum Viable Context

The smallest amount of context that still gets great output. The MVC depends on the type of task, but the recipe is consistent:

• What's the goal output? What does it look like when it's right?
• What does bad look like? What pitfalls have we hit before?
• What's the expected use case? Where does this output go next?
• What's the next step after good output? So Claude knows the pipeline, not just the immediate ask.
• What's the framework or constraint? Brand voice, target audience, format requirement, anything that's true regardless of the specific task.

That's the MVC. Path of least resistance to a good outcome. Treat friction as opportunities to improve velocity, correctness, and accuracy of the next rotation.

Once you internalize MVC, you'll never write a context-free prompt again, and Claude will start to feel like the powerful collaborator it always was, but you weren't yet captain enough to use.