The line cook does not run the pass

In a professional kitchen the line cook is fast, tireless and genuinely skilled. They do not decide what leaves the kitchen. That happens at the pass, where somebody looks at every plate against a standard the cook cannot see from where they are standing.

That division is the whole reason a brigade works, and it is not about trust. The cook has been staring at this one plate for four minutes. The person at the pass has seen the last forty.

Why this is in a Power Platform cookbook

Because most of my delivery work now goes through a coding agent, and the interesting problems turned out not to be the ones I expected.

“Can it write the code” stopped being the question fairly quickly. The question that replaced it is harder and much less discussed: what stops it from confidently shipping something wrong into a customer system? That question is sharper in Power Platform work than in most places, for three reasons that have nothing to do with AI.

The environments are live. There is no local Dataverse to break in private, so the difference between a development environment and a production one is a setting, a habit and your attention. The tooling is sometimes absent — in a customer tenant you may have no CLI, no service principal and no pipeline, which removes exactly the machinery that would otherwise catch a bad change. And a wrong write is often not a crash. It is a consent record, a permission, an email that went out. Those do not turn a build red. They turn up in a conversation weeks later.

What this thread assumes

Nothing exotic. A repository, an agent that runs in the terminal against it — I use Claude Code, but nothing here is specific to it — a conventions file the agent reads at the start of every session, and at least one command that reliably tells you the code is broken.

If you have all four, the articles in this thread are directly usable. If you have the first two, start by writing the third, because everything else is built on being able to point at a rule.

The stance, in three sentences

Capability is cheap. Adding a tool, a permission or a new agent is a line of configuration. Nothing about that decision is difficult, which is exactly why it deserves more thought than it gets.

An agent’s judgement about its own work is worth very little. The context that produced the code contains every shortcut taken on the way there, plus the reasoning that made each one seem fine. Ask it whether the result is good and it will agree with itself.

Restraint is the design work. The interesting question is never what the loop can do. It is what the loop is not allowed to do, decided in advance, while nothing is on fire.

None of that is scepticism about the tools. I would not go back. It is the same reasoning that puts the knives in a block and gives raw chicken its own board: not because anybody is dangerous, but so that nobody has to think about it at eleven on a Friday.

Three failure shapes

The rest of this thread is three specific versions of the same problem, each written up on its own and readable in any order.

The first is the green build that is wrong anyway. Lint passes, types pass, and the code still breaks a rule the project wrote down a year ago. That is a job for a second pair of eyes with its own context, and for turning prose conventions into something that can actually block a commit.

The second is the tooling that is not available. Editing cloud flows in a tenant with no CLI, where the safety net has to be rebuilt by hand out of a folder convention and a script — and where an import can report success and create absolutely nothing.

The third is the failure that never turns red. The change that passes every check and produces a data protection problem anyway, and the layers of guard rail that are the only thing standing in front of it.

They share a shape. In each one, the tooling says everything is fine, and the tooling is not lying — it is answering a narrower question than the one that mattered.

That is what the pass is for.