Externalized process: optional becomes skipped

I sketched the whole stack in the software factories post: memory, process, proof, coordination, execution, and gave each layer a paragraph. Here I want to expand on process, because it’s the layer I keep seeing other devs struggle to wrap their heads around. It’s also where I keep watching good agents quietly do the wrong thing for the most understandable reasons.

An agent is very good at getting to the satisfying part. Code changes, tests go green, and a confident summary lands that reads like a job well done. The model is optimizing for the shape of “done,” and the satisfying part looks exactly like done.

The trouble is everything that surrounds it. Shaping vague work before touching the keyboard, root-causing the bug instead of patching the symptom, designing before implementing, capturing evidence, reviewing before it ships; none of that produces the dopamine hit of green tests, and none of it is what models are trained to chase. So unless something forces the work through those parts, the models will shortcut around them.

”Be careful” is not a process

In the software factories post I made the claim that agents skip optional steps not out of malice but because they’re optimizing for completion, and that “be careful” is not a process. I still believe that, but I undersold exactly why it’s structural rather than a tuning problem.

Here’s the thing: to a completion-optimizing worker, every step that isn’t enforced is optional. Not “optional” as in low-priority. Optional as in invisible, as in the agent doesn’t even consider it part of the path. If the path to “done” can be reached without writing a design doc, the design doc is not a soft suggestion the agent weighs and usually honors. It’s a detour with no gravity pulling toward it.

So “be careful” falls apart for a specific reason. It describes a disposition, and the agent has no stable disposition between sessions: what survives a fresh context window is structure, not intentions. A path the agent has to physically pass through.

That’s the whole idea behind the design for Beislið. It isn’t trying to make the model more careful; you can do that with better prompting. It’s to make the path explicit enough that the careless route stops existing.

What a gate actually is

Across the last few posts, I’ve been throwing around the word “gate” a lot, and I realized I never defined it. So let me be precise about what I mean, because a vague gate is worse than no gate.

A gate is a checkpoint where the work cannot advance to the next stage until a specific condition is met. A gate is our way to tell the agent: “there is no path from shaping to implementation that doesn’t pass through a design that had to be produced and accepted.”

What separates a suggestion from a gate is whether skipping it is possible. If skipping is possible, a completion-optimizer will eventually skip it, not every time, but on exactly the run where you weren’t watching. A real gate removes the option.

There’s a failure mode worth naming here. A gate that asks for something but never inspects what comes back isn’t a gate. The agent writes “design: looks good, proceeding” and walks through. That’s a gate without evidence, and a gate without evidence is just a speed bump. This is exactly where process has to lean on proof: a gate is only as real as the evidence it checks. The two layers aren’t separate concerns. Process decides where the work must stop; proof decides what it must show to keep going.

The SDLC is not five boxes

The standard SDLC diagram is plan, build, test, review, deploy. Five tidy boxes. To a human those boxes are fine, because we fill in the micro-steps from experience without being told. To an agent the boxes are too coarse, and things slip through the gaps between them.

I went through this in the factories post, so I won’t relist every micro-decision. The point I want to push further, though, is that those micro-steps don’t all carry the same risk, and treating them as one box is what makes them skippable.

Take “plan,” for example. Inside it sits: is the problem even clear? Is the scope one coherent change or three tangled ones? One PR or several? Do we need a spec, or is this obvious enough to design directly? Each of those is a different question with a different stop condition. “Is the scope coherent” is a cheap check the agent can usually self-answer, if it’s good enough. “Do we need a human to confirm this assumption” is not; that’s a transition where the agent should stop and ask, and an agent left to its own completion drive will almost never choose to stop and ask.

So process isn’t just five boxes. It’s a sequence of small transitions, each with its own uncertainty and its own answer to a single question: what has to be true before this work is allowed to move forward?

That’s the question a factory runs on. Not “am I done.” The agent always has an answer for that one.

Where the gates go

If gates are where the work stops, then the real design problem is where to put them, and this is the part I’ve gone back and forth on the most.

Too few gates and you get slop. The agent sprints from a vague ticket to a confident PR, and the trust work all lands on the human at the end, in one undifferentiated lump, at the worst possible moment to catch anything. Too many gates and you get friction so thick the agent spends more tokens narrating its compliance than doing the work, and you spend your day rubber-stamping checkpoints that never had a real chance of failing. A gate that never catches anything isn’t safety. It’s ceremony, and ceremony for its own sake is the thing the IaC movement was supposed to kill, not resurrect.

My current instinct, and just to be clear, it is instinct, not proof, is to put gates where uncertainty is highest and where the cost of being wrong compounds. Shaping is one: a misunderstood problem poisons everything downstream, so the cheapest gate in the whole lifecycle is the one that confirms the agent and I mean the same thing before any code exists. Root cause is another, and it leans hard on whether you have a reliable memory layer. The gap between “I made the symptom go away” and “I understand why it happened” is where the worst bugs hide. Did the agent fix the cause or paper over it? Did it understand the boundary it just touched? Did it check whether this failure had been seen before? Those are stop-and-prove moments. A CSS nudge is not.

This is why the gate placements in Beislið are so open and configurable. I don’t believe this is something that can be broadly defined; it should be left to each team’s taste. I can encode the gate. I’m still the one deciding it belongs there.

Gates are where judgment gets injected

Which leads to the part I actually care about most.

A gate isn’t only a barrier the agent has to satisfy. It’s the slot where human judgment enters the system on purpose, instead of leaking in through panic at review time. When I decide a transition is risky enough to stop for a human, I’m not slowing the agent down for sport. I’m reserving my attention for the one decision in this stretch of work that actually needs a person, and letting the agent run unsupervised through the parts that don’t.

That’s the trade the whole harness is built around. The model is the horse; the gates are where I hold the reins, and the rest of the time I let it run. Less typing every line, more deciding where ambiguity requires me. That isn’t a smaller job, it’s a different one, and frankly a more interesting one than babysitting a confident worker through a chat transcript.

There’s a version of all this that fails, and I think it’s important to say it out loud: you can pour effort into gates and discover the model got good enough that half of them were guarding against a problem that no longer exists. Some of my gates will age out, and the ones tied to a specific model’s blind spots will go first. But that shape, work passing through stops, each stop checking evidence, judgment reserved for the transitions that earn it, will survive a model change in a way a clever prompt never will.

Externalized process.

The model’s job will always be to reach the satisfying part. Our job is to make sure the path to it runs through the unsatisfying parts that create trust, and to make those parts required, not optional, because optional always becomes skipped.