Context Engineering Beats Prompt Tricks

“Make it better” contains almost no information about a finished website.

Better for whom? Which decisions are still open? Is the problem the copy, the hierarchy, the implementation or the deployment? If an agent changes the typography and produces a polished page, it may have done impressive work on the wrong problem.

The briefs that became useful during this site’s development were more specific. They identified the approved implementation, the requested revision and the parts that had to survive unchanged. Some supplied exact copy. Others defined a production constraint, such as removing the only feature that required a backend.

That kind of preparation is less entertaining than collecting clever prompts. It is also closer to the work I actually need help with. The model needs a usable picture of the project, including what it must not infer from a vague request.

Context is an operating picture

Anthropic’s discussion of context engineering treats context as the information available during inference and emphasizes curating that information across an agent’s work. It includes more than the latest instruction: tool results, history and other supplied material also shape the next action.

For my purposes, the useful question is what the agent needs to know to make the next decision correctly. That may be a component, an acceptance criterion, a previous decision or a small example of the desired output. Supplying everything the project has ever produced is not a substitute for selecting those things.

I would organize the working picture around five questions: what exists, what should change, what is settled, what evidence is authoritative and what will demonstrate completion. They are ordinary project questions. AI assistance makes omissions in the answers particularly visible because the system can fill them with plausible assumptions very quickly.

The title of this article is a working preference, not a benchmark result. Prompt wording still matters. My argument is that a polished instruction cannot compensate for missing or contradictory project facts.

Tell the agent which decisions are already closed

A useful preservation instruction is concrete. “Keep the design” leaves room to reinterpret colors, spacing and hierarchy. “Use the existing article layout, preserve its typography, and add content through the current collection” identifies both the boundary and the implementation path.

The difference matters when a project has passed through several revisions. An older document may describe a design that was later replaced. A screenshot may show a temporary state. A README may still describe infrastructure the current code no longer uses.

I want the brief to identify the approved baseline and the precedence between these records. The current implementation can be the visual baseline while a new requirement overrides one specific behavior. Those roles can coexist if they are named.

On this site, the static-hosting revision changed infrastructure while preserving the product. That is more precise than asking for a “simpler site.” Simplicity could otherwise become a reason to remove navigation or rewrite a page that was never part of the request.

A boundary should help the agent choose, not merely tell it to be careful.

Give each fact a home

A source of truth is useful only if the task can point to it. For an article, the content schema defines valid metadata. For a career entry, a typed data file owns the text. For deployment, the current workflow and operating guide describe the supported path.

I prefer a short instruction that names those places to a long prompt that copies their contents and immediately starts becoming stale. The agent can inspect the current files and explain any conflict it finds.

There are exceptions. Exact replacement copy belongs in the request when wording matters. A verified external requirement may need a source link and a date. A one-time decision may not yet have a permanent home. The important distinction is whether supplied text is authoritative input, background material or an example.

Imagine a brief containing an old hosting proposal and a new static-only requirement. Without that distinction, an agent might preserve the obsolete service because it appears in a detailed document. With it, the old proposal becomes historical context and the new requirement governs the implementation.

This is also a maintenance concern for humans. If two documents contradict each other, adding a third summary rarely resolves the problem. Update the current guide and label the historical record.

Examples should expose the difficult boundary

Examples are most useful when they show what an abstract rule would miss. For publication gating, a draft article is an obvious case. A future-dated article with draft: false is a more revealing one. A demonstration template that must remain private is another.

Together, these examples clarify that publication is not controlled by one flag alone. They also suggest tests. The context has moved from a general intention to a distinction the implementation must preserve.

For visual work, I would provide a representative desktop and mobile view, then identify the expected change. A screenshot without an explanation can be interpreted as inspiration rather than a baseline. The explanation should say whether the layout is approved, which element changes and which differences count as regressions.

Negative examples can help too, provided they are specific. “Do not create a second navigation component” is actionable in a repository that already has one. A long list of generic prohibitions can overwhelm the actual task and make it harder to find the few constraints that matter.

I would rather supply three meaningful edge cases than thirty reminders to produce high-quality work.

Evidence must retain its status

The same problem appears outside coding. A product hypothesis can acquire the tone of a fact simply by being repeated through several summaries. An AI-generated synthesis can then look like research even though its premises were never checked with users.

My research interests include that boundary. The Research page describes Supporting Problem Exploration in Early-Stage Innovation Projects through Human-AI Collaboration, with Daniel Planötscher and Xiaofeng Wang, and Vibe Exploration: Human-AI Collaboration for Problem-Space Exploration in Software Startups, with Daniel Planötscher. I am referring to the project’s documented research summaries, not claiming that either establishes a universal productivity effect for coding agents.

The connection I draw is methodological: assistance with exploration should preserve the distinction between observations, interpretations and proposed next steps. It should help expose uncertainty rather than quietly convert it into confidence.

In a practical brief, I would label a statement as an owner-supplied fact, an external claim requiring verification, an assumption or an open question. That does not require elaborate machinery. A few honest labels can prevent a speculative sentence from becoming the foundation of a feature.

Keep context fresh as the work moves

A long task produces new information: a failing test, a missing credential, an implementation constraint, a decision that supersedes the original plan. If that information never updates the working picture, the agent can continue solving yesterday’s version of the problem.

I want progress updates to capture decisions and unresolved issues, rather than narrate every file read. “The provider has not been verified, so deployment remains disabled while local checks proceed” changes the operational boundary. “Opened three files” usually does not.

A useful handoff after an interruption should identify the current objective, completed changes, evidence collected and the next unresolved dependency. It should also preserve the reasons behind choices that would otherwise be easy to undo.

This is where context becomes an engineering artifact. It is maintained alongside the work, with obsolete statements removed or clearly marked. The aim is to make continuation possible without forcing the next pass to rediscover every decision from a long conversation.

I discuss the surrounding implementation loop in coding agents beyond autocomplete. Good context makes that loop easier to bound and review.

Finish with evidence, not a more confident sentence

A definition of done should describe a result the owner can inspect. For this editorial launch, that includes real article files, populated discovery pages, a rebuilt search index and a local preview. A statement that the content “should work” leaves the central question unanswered.

The final response should also distinguish what was verified from what remains conditional. Local rendering, a successful CI run and a completed provider upload are separate facts. Compressing them into one reassuring adjective loses information.

I do not expect context engineering to remove judgment. Someone still has to decide which sources deserve trust, which constraints matter and when a result is good enough. What it offers is a better place for that judgment to live: in the shared evidence and explicit decisions that guide the work, rather than in the hope that the next prompt sounds sufficiently clever.

Sources

1. Anthropic: Effective context engineering for AI agents — checked 2026-10-11