A new angle to context engineering

A common and increasing problem

Here is a scene I've watched play out dozens of times, across different teams, with only minor variations.

A senior AI engineer opens a 600-word system prompt from a Python file a colleague sent over. They paste it into Claude to reproduce a bug, then delete the Markdown headers they'd written for Gemini ADK and rewrite the whole thing as XML tags to match Claude's rules — by hand.

On the other side, a senior PM writes a mix of functional and technical instructions to test a core workflow after a feature ships. They figure it out late at night, split across Slack and Notion, then run it through Claude Code across a few iterations until it “works.” No dataset to evaluate against. No criteria. No version control. Just a helpful artifact buried in the day-to-day rush, that someone might need again — if they can find the right thread.

Codebases are a prompt's buried inbox. But they're not the only one. Notion docs, Slack threads, and Claude conversations all accumulate prompts that worked once or twice and then disappeared.

Prompts alone are no longer enough to power AI at scale. Static prompts produce vague outputs and waste tokens. And the average professional now writes thousands of them a year with no structure, no reuse, and no way to get one back.

What context actually means

It's the term we're all using now.

“Context engineering” was popularised in mid-2025 by people like Andrej Karpathy — “the delicate art and science of filling the context window with just the right information for the next step” — alongside Tobi Lütke and others. Gartner formalised it as an enterprise discipline. By 2026 it had stopped being a debate: the 2026 State of Context Management report found 82% of IT and data leaders now agree that prompt engineering alone is no longer sufficient to power AI at scale, and 95% of data teams plan to invest in context engineering this year.

Context engineering is the discipline of designing the full informational environment a model receives. Not just the prompt, but its meta structure, retrieved knowledge, tool outputs, conversation history, memory state, system instructions, output schemas, infrastructure — everything the model sees before it generates the next token.

But almost everyone is talking about the infrastructure of context engineering. Almost nobody is talking about the part where a human sits down and writes the thing.

I see it as a mix of prompt and context engineering: the practice of authoring the knowledge, instructions, and files that let humans and machines communicate well. prompt-x exists to make that half real.

The adoption bias

In early 2026, Gallup found that about half of employees use AI at least a few times a year in their role — which means the other half rarely or never touch it, in the country where adoption runs highest. Microsoft's Global AI Adoption 2025 report found usage concentrated in technology, finance, and professional services, with entire industries still at the starting line. The people who have never opened an LLM are not a minority.

Most of the time, when we do use these models, we write a natural-language instruction and delegate the hard parts to the machine — the role, the tone, the framing. That delegation is fine until it isn't. Whatever the tooling around it, we still have to sit down and choose the right words for the communications that matter.

Accounting for AI usage will define the next few years. The model takes on part of the work; we hold the line on human-crafted criteria and authored instructions that actually function in collaborative tasks.

The authoring gap

Remember the AI engineer and the PM?

Six months later they need to do a similar task, and the hunt begins. Where was that “perfect prompt”? Slack thread? Notion doc? Cursor file? Gone. So you rebuild the module descriptions, the backend schemas, the endpoint definitions from memory — because you never stored the thing properly, and never kept it updated.

Imagine this at scale.

Notice the asymmetry. The runtime half of context engineering has real infrastructure and is future-proof and VC-backed: vector databases, retrieval pipelines, agent frameworks, tool orchestration, evaluation harnesses, observability stacks, token budgeting, context compression. Engineers are building serious systems for the retrieved, orchestrated, dynamically assembled parts of the context window.

Even the prompt-management tools that have appeared in the last year — the ones that promise to “treat prompts like code” — sit on the runtime side. They version, test, and observe prompts you've already written. Useful, real, and still downstream of the moment that decides quality. The authored portion has no equivalent. The craft of writing the structured input has no workspace, no IDE.

Authoring is upstream of everything in the AI productivity process.

Prompts are like code. They deserve the same discipline from the start: structure, version control, testing, refinement, reusability, and tools that compile cleanly to wherever they need to run.

The reframe is this: authoring is not just vibe-writing.

The prompt anatomy

Prompts are instructions. Instructions are knowledge blocks.

In a world where ideas, updates, and information move constantly, we still have to sit down and choose the right words. So try this: think of a message you're about to type into your favourite LLM, but don't hit send yet. Now break that natural-language message into smaller instruction blocks.

The industry-standard answer to “what are the components of a prompt?” has been stable for a couple of years. Google, OpenAI, Anthropic, and others converge on roughly 6 pieces: a role (who the AI is), context (background knowledge), a task (what to do), examples (demonstrations), an output format (how to structure the response), and constraints (boundaries and prohibitions). If you've ever written a system prompt for production, you've used all 6 — plus a few more.

At prompt-x I defined 9 blocks in a flexible structure — you can specify more or less as the task demands — enriched with a variable system so I can author at scale and run many tasks in parallel.

Same content, different encoding

The platforms we use every day encode structured instructions differently.

The content of the role field doesn't change across these targets. Only the encoding does.

Yet the dominant workflow in 2026 is still to write the prompt once and reformat it by hand for each platform. People try to remember platform-specific rules, lose a little information on each pass, and accept that their multi-platform versions drift apart within two weeks — because nobody has time to reconcile them.

If the content is stable and the encoding is platform-specific, then encoding is a compilation step.

Authored context should be written once, in a canonical structured form, then compiled for each platform at the point of use. A compilation engine generates XML for Claude, Markdown for GPT, uppercase labels for Gemini, prose for Lovable, plus whatever platform-specific instructions each one needs. Write once, compile everywhere.

Let me ground it.

A product manager is designing a spec — a new feature request to hand to Claude Code or Lovable to prototype for a customer demo. One canonical, authored artifact:

One source. Then the compilation step. In Claude, each field becomes an XML element. In GPT, a Markdown section under a header. In Gemini, an uppercase label. In Lovable, the same fields recombine into prose — the role becomes the opening paragraph of a development brief, the tools become named references to existing components and assets.

Three outputs, one source. That's what a prompt engineering platform looks like when it takes authoring and compilation seriously — and it's what prompt-x does today, from the same 9-field artifact, with a CLEAR evaluation on the output so you can tell whether the prompt actually got better.

Notice what isn't in this picture: no retrieval, no vector stores, no context compression, no memory strategy. No infrastructure at all. Those are real and necessary — and a different conversation. Good authoring, structure, and compilation don't replace good retrieval. They make it work, by giving the model a clear frame to interpret what it pulls in.

The two layers are complementary. The industry built the first half. Now it meets the second.