A good chef does not begin dinner service by rummaging through the pantry, discovering the menu mid-order, and hoping the oven has the right settings. The prep happens before the heat: ingredients portioned, tools arranged, sauces started, stations assigned. That discipline is called mise en place — everything in its place.

Coding agents need the same thing.

The industry has spent the last year asking which model writes the best code, which IDE has the slickest autocomplete, and which agent can survive the longest benchmark. Those questions matter. But for teams trying to use agents inside real repositories, the more immediate question is usually simpler: what did the agent know before it touched the code?

Andrew Zigler’s recent paper, “Mise en Place for Agentic Coding,” gives a useful name to this missing layer. The paper argues that the common “vibe coding” workflow — move fast, prompt broadly, debug whatever comes back — creates a predictable alignment problem. If the agent does not have the domain context, constraints, design intent, and task structure, it will still produce something. It may even look impressive. But the unpaid bill arrives later as review churn, refactoring, brittle integrations, and confused ownership.

Zigler proposes a three-part preparation method: contextual grounding, collaborative specification, and task decomposition. In plain terms: write down the knowledge that is currently trapped in people’s heads; turn vague requests into design artifacts through human-agent discussion; then convert that specification into dependency-aware tasks agents can actually execute.

That sounds slower than “just ask the agent.” It is not. It is a trade: spend more time before the first diff so you spend less time unwinding the wrong diff.

This is where coding-agent work starts to look less like prompt magic and more like engineering operations. The important asset is not a clever one-liner prompt. It is the repo’s agent operating surface: context files, architectural notes, coding rules, task records, test expectations, permission boundaries, and review criteria.

A second recent paper, “Configuring Agentic AI Coding Tools,” shows that this surface is already forming in the wild. The authors studied 2,853 GitHub repositories and analyzed configuration mechanisms across Claude Code, GitHub Copilot, Cursor, Gemini, and Codex. Their finding is both encouraging and sobering: context files dominate, and AGENTS.md is emerging as an interoperable convention, but more advanced mechanisms such as skills and subagents remain uncommon.

That is exactly what early infrastructure looks like. Teams have discovered that agents need repo-level instructions, but many have not yet turned those instructions into a maintained system. A stale context file can become a second source of truth. A vague “follow best practices” note can produce false confidence. A giant undifferentiated memory dump can be worse than no memory at all, because it gives the model more tokens without giving it better judgment.

Anthropic’s context-engineering guidance makes the constraint explicit: context is the set of tokens available when the model acts, and good context engineering is about curating the smallest high-signal set likely to produce the desired behavior. Bigger context windows do not remove the need for curation. They make sloppy curation easier to hide until the agent starts missing the important thing buried on page forty-seven of the transcript.

So the practical version of mise en place is not “put everything in the prompt.” It is “put the right things in stable places.”

For a software team, that might mean:

  • A short repo map that explains the major services, data flows, and ownership boundaries.
  • A decision log that captures why the system is shaped this way, not just what files exist.
  • A task brief template with problem, constraints, non-goals, acceptance criteria, and known risks.
  • Dependency-aware implementation slices instead of one heroic “build the feature” request.
  • Tool and permission rules that say what the agent may inspect, modify, run, or never touch.
  • Test commands and review expectations written for the agent and the human reviewer.
  • A habit of updating these artifacts when the repo changes, not only when an agent fails.

This preparation also changes how leaders should evaluate agent productivity. The wrong metric is “how quickly did the first patch appear?” Fast first patches are easy. The better metrics are rework rate, reviewer correction volume, test failure patterns, context defects found during implementation, and whether the agent’s actions are traceable to a spec the team actually approved.

That is where Microsoft’s recent agent trust-stack framing connects to the coding workflow. Its Build 2026 post describes ASSERT for policy-driven evaluation and ACS for portable runtime controls, arguing that written policies often fail to become working controls and that evaluation must be tied to the specific agent, use case, and production context. Even if a team never adopts those exact tools, the loop is the right one: define the policy, evaluate against it, add controls at the failure points, rerun, and observe in production.

For coding agents, the same loop belongs before and after implementation. The spec is not merely a planning document. It is the thing you evaluate against. The context file is not merely a convenience. It is a control surface. The task decomposition is not just project management. It is how you limit ambiguity, concurrency risk, and blast radius.

The shift is subtle but important: context becomes infrastructure.

Once context is infrastructure, it needs ownership. Someone must decide which instructions are canonical, which are obsolete, and which are too broad to be useful. Someone must review agent rules the same way they review CI configuration. Someone must notice when a team’s AGENTS.md says one thing, the tests enforce another, and the production runbook says a third.

This is not bureaucracy for its own sake. It is how you make agent speed safe enough to matter.

The teams that get the most from coding agents will not be the ones with the longest prompts or the most theatrical demos. They will be the ones that can hand an agent a well-prepared station: the domain context it needs, the constraints it must respect, the slice it should complete, the tests that define done, and the controls that keep a mistake from spreading.

In other words: stop treating preparation as overhead. In agentic development, preparation is part of the execution engine.

A coding agent can move fast. But if you want it to move in the right direction, do the mise en place first.

Sources

Build Agents That Prove Their Work

If you are wiring agent workflows into real operations, Alchemic can help design the checkpoints, traces, and validation gates that keep automation honest.

Get the Field Guide - $10 ->