Michelin Kitchens for Agentic Code

What Is This?

“Michelin Kitchens for Agentic Code” is a better metaphor for reliable coding agents than the usual “software factory.” A factory metaphor suggests linear production: spec in, code out, defects removed later. Agentic coding behaves more like service in a serious kitchen: a constrained station, prepared ingredients, fast execution, constant checking, and a final taste before anything reaches the table.

Professional kitchens survive because they turn volatile work into a disciplined operating system. Mise en place covers preparation, station setup, tools, small wares, clean-up, and readiness before service starts.[8] For coding agents, that maps to scoped tickets, available commands, known fixtures, local environment setup, and explicit acceptance checks.

The kitchen model says: do not ask the agent to “go build the feature.” Give it a station, prep, a ticket, a pass, and a tasting ritual.

Why Does It Matter?

Coding agents are now strong enough to read files, run commands, change code, and iterate with less human typing.[4] That autonomy creates leverage, but it also removes the old safety rail where the human saw every line being written. If the only instruction is a vague outcome, the agent fills gaps with assumptions.

Modern agents can resolve a large share of real GitHub issues on SWE-bench, but the leaderboard still measures bounded tasks with observable outcomes, not open-ended “make it good” work.[3] The lesson is not that agents are unreliable. The lesson is that they become reliable when the task is shaped into an environment where success can be observed.

Anthropic’s agent guidance makes the tradeoff explicit: use the simplest solution possible, add agentic complexity only when needed, and remember that workflows give predictability while agents give flexibility.[6] In kitchen terms: do not hire a brigade to make toast. When the work is complex enough for a brigade, define the stations.

The Kitchen Model

1. Prep Before Service

A chef does not start dinner service by discovering there are no onions, no clean pans, and no printed tickets. Agents fail the same way when they begin by discovering missing dependencies, unclear test commands, ambiguous product intent, or half-known conventions.

Prep for an agent means:

• the repo is clean enough to distinguish agent changes from background noise;
• dependencies are installed or installable;
• build, lint, test, and typecheck commands are known;
• the acceptance criteria are short and externally checkable;
• the agent knows where not to touch.

This is why context engineering beats heroic prompting. A good prompt is not a speech; it is a stocked station.

2. Stations Beat Swarms

The factory metaphor invites horizontal scale: more agents, more throughput. Kitchens scale differently. A station owns a bounded surface — grill, pastry, garde manger, sauce — and hands work across the pass only when its piece is ready.

Agentic code should use the same pattern. One agent can own a UI component, another a migration, another a test harness, but each needs a tight contract. Unbounded parallel agents working in the same files are not a brigade. They are cooks reaching for the same pan.

A station contract should say:

• files or modules in scope;
• files explicitly out of scope;
• allowed tools and commands;
• expected artifact;
• verification command;
• review owner.

This is less glamorous than multi-agent orchestration, but it is easier to debug. Anthropic warns that frameworks can hide prompts and responses, making systems harder to debug and tempting teams to add complexity before it is needed.[6] Station design keeps the work inspectable.

3. The Pass Is Review

In a restaurant, the pass is where dishes are checked before service. In an agentic coding workflow, the pass is not a vibes-based skim of the diff. It is the review boundary where code, tests, screenshots, logs, and product intent meet.

Claude Code’s best-practice guide is blunt: without a check the agent can run, “looks done” is the only signal available; with a test, build, linter, fixture diff, or screenshot check, the agent can read failure and iterate.[4] That means review should start before implementation. If the agent cannot name the check, the station is not ready.

The pass should include three layers:

1. mechanical checks: typecheck, lint, tests, build;
2. behavioural checks: fixture, browser flow, API response, benchmark, or golden output;
3. taste: human judgement about simplicity, fit, naming, product feel, and whether the change belongs.

The first two can often be delegated. The third cannot.

4. Taste Beats Output

Factories optimize for quantity. Kitchens optimize for dishes that should actually leave the pass. That distinction matters because agentic code can generate plausible volume faster than humans can review it.

Martin Fowler’s argument about quality is useful here: internal quality is not an aesthetic extra; high internal quality makes software cheaper to change, while low quality slows future work.[7] For agents, taste is the practice of protecting internal quality when the output looks superficially complete.

Taste asks:

• Is this the smallest change that solves the problem?
• Did it follow the local architecture, or invent a parallel one?
• Are names and boundaries obvious to the next maintainer?
• Did tests check behaviour rather than implementation trivia?
• Did the agent delete complexity, or just add code around it?

Taste is how the human stays valuable as the keyboard work becomes cheaper.

Why Smart People Get This Wrong

Smart teams over-trust factory metaphors because software already has pipelines, queues, tickets, and throughput charts. Those are useful for coordination, but they hide the messy part: code is design material, not only manufactured output.

The second mistake is treating agent failure as either “the model is bad” or “the prompt was bad.” Often the real failure is operational. The agent had no prep list, no station boundary, no executable check, and no pass. A better model will still drift in that environment.

The third mistake is confusing blame with learning. Amy Edmondson argues that many organizations want to learn from failure, run after-action reviews, and still see little change because they misunderstand failure itself.[10] Google’s SRE book makes a similar operational point: blameless incident reviews focus on system contributors rather than punishment, so teams can learn and improve resilience.[11] Agent incidents need the same treatment. Do not only ask “why did the agent do that?” Ask “what station condition allowed that output to pass?”

How To Use This

Use the kitchen model as a lightweight operating procedure for agentic coding.

Before assigning the agent

Write a prep card:

Goal: one sentence.
Station: files/modules in scope.
Out of bounds: files/modules not to touch.
Prep: dependencies, env, fixtures, docs to read.
Acceptance: commands and observable behaviour.
Pass: what the human will review.
Taste: simplicity constraints and style preferences.

During the run

Keep the agent inside the station. Redirect when it starts global refactors, speculative abstractions, or unrelated clean-up. If the task uncovers a larger problem, cut a new ticket rather than letting the station expand until review becomes impossible.

After the run

Run the pass:

• inspect the changed files;
• run the declared checks;
• verify the behavioural path;
• ask whether the result is simpler than the starting point;
• record the prep mistake if the agent failed.

The goal is not bureaucracy. The goal is to make the cheapest reliable loop: prep, station, service, pass, taste.

Practical Takeaways For Jamie

For Jme-Loop and Lloyd-managed engineering, the paved path should look more like a kitchen than a factory.

• Steward tickets should include station boundaries, not just goals.
• loop steward --goal "..." --execute-one should surface the prep card and verification command before it touches code.
• Repo lanes should make review visible: what changed, what passed, what still needs human taste.
• Multi-agent work should be split by station, not by vague “parallelize this” prompts.
• Failures should update the recipe: missing fixture, unclear boundary, bad acceptance check, or review gap.

That is the durable model: agents do the line work; Lloyd maintains the kitchen; Jamie tastes what matters.

Key Terms

• Mise en place — preparation, setup, tools, and readiness before service.[8]
• Station — a bounded work surface with clear ownership, tools, and scope.
• Pass — the review boundary where work is checked before release.
• Taste — human judgement about simplicity, fit, maintainability, and product feel.
• Executable acceptance — a check the agent can run and interpret, such as tests, build output, screenshots, or fixture diffs.[4]
• Blameless review — a failure review focused on system conditions and learning rather than punishment.[11]

Recall Questions

1. Why is a Michelin-kitchen metaphor more useful than a software-factory metaphor for coding agents?
2. What belongs on an agent prep card before implementation starts?
3. How does a station boundary reduce agent drift?
4. What is the difference between mechanical checks and taste?
5. When an agent produces bad code, what should the incident review inspect besides the model output?

Best Resources to Learn More

• The Culinary Pro on mise en place for a concrete description of prep, station setup, tools, and readiness.[8]
• Anthropic’s Claude Code best practices for operational advice on verification loops and context limits.[4]
• Anthropic’s “Building Effective Agents” for the workflow-versus-agent distinction and the case for simple composable patterns.[6]
• SWE-bench for a grounded benchmark of agent performance on real software issues.[3]
• Google SRE’s blameless incident review chapter for a mature model of failure review.[11]

Sources

[3] https://swebench.com [4] https://www.anthropic.com/engineering/claude-code-best-practices [6] https://www.anthropic.com/engineering/building-effective-agents [7] https://martinfowler.com/articles/is-quality-worth-cost.html [8] https://www.theculinarypro.com/mise-en-place-savory [10] https://hbr.org/2011/04/strategies-for-learning-from-failure [11] https://sre.google/sre-book/postmortem-culture