From Skills to Blueprints: Where AI Should Stop and Code Should Take Over

Where the pressure shows up

Many teams start with a "skill" or playbook that tries to describe the whole workflow in one instruction package. It plans the change, edits files, runs commands, checks output, decides whether tests are sufficient, and sometimes even decides how to ship. That can work for a careful human in the loop. It breaks down as soon as you want the workflow to be portable, testable, and reliable across repositories.

The reason is simple. Not every step in the workflow is ambiguous. Planning is ambiguous. Validation entrypoints should not be. Deciding how to interpret a ticket is ambiguous. Running the canonical test suite should not be. If you leave deterministic steps inside model behavior, you create variability where the system should have behaved like infrastructure.

This is where teams silently tax senior engineers. People become the reliability layer by compensating for missing deterministic stages. That does not scale, and it hides where the workflow is weak.

The failure mode

The anti-pattern is workflow overloading: letting the model own both judgment and mechanics. That makes success look impressive in demos because the system appears fluid. It also makes failure analysis miserable because every stage depends on what the model happened to do that run.

You see the cost when the same task takes a different validation path on different days, or when the model decides to skip the script you intended to be mandatory because it found a faster-looking path. If the workflow cannot tell the difference between "agent discretion" and "non-negotiable mechanics," it is not a mature workflow yet.

A common objection is "more scripts will slow us down." The right question is slower than what. Slower than a demo, yes. Slower than post-merge rework and exception churn, no.

The better pattern

The better pattern is blueprinting. Use AI where judgment and synthesis are useful. Then hand off to deterministic code for the steps that should never depend on a model. A blueprint is not a long prose recipe. It is a machine-readable sequence of stages with clear inputs and outputs: plan, execute, validate, package, and ship.

That handoff matters because it gives each stage a contract. The planner produces a task brief. The executor produces a patch. The validator runs the required scripts. The ship stage decides whether a PR can open, whether a reviewer is required, and what evidence has to be attached. Once these boundaries are explicit, the workflow becomes reusable across teams.

The rule to remember is simple: if a step should produce the same result for the same inputs, move it out of prompt behavior and into deterministic code.

Why security cares

Security cares because shell choreography and merge mechanics are terrible places to rely on model improvisation. Those stages should be bounded, inspectable, and consistent. The more mechanical the action, the stronger the case for moving it into scripts or policy.

This is also where Gait can make sense as implementation context. The value is not that a model "knows" a control. The value is that a deterministic boundary can evaluate an action before it executes and return a policy verdict the workflow must honor.

Why platform and engineering care

Platform teams care because blueprinting is how workflows scale. Once a large implementation skill is split into planning, execution, validation, and shipping stages, teams can improve one stage without destabilizing the whole system. They can swap validators, add proof steps, or tighten merge rules without rewriting the planner.

That modularity also makes failure recovery cleaner. If validation fails, you do not need to rerun the whole task from scratch. You can inspect the handoff artifact, retry the validator, or route the run to a reviewer. That is a better operating model than hoping a single long prompt will do the same thing twice.

It also clarifies ownership. Platform can own shared validators and run orchestration, while service teams own domain-specific planning inputs and acceptance criteria.

What to do next

Take one agent workflow that currently lives in prose and split it into stages.

• Identify which decisions genuinely require model judgment.
• Move every repeatable command, validation path, and merge mechanic into code.
• Define the artifact each stage hands to the next stage.
• Decide where policy verdicts and human approvals can interrupt promotion.

Once you do that, the workflow becomes teachable. It also becomes governable, because you can finally tell which stage failed and why.

The next post takes that idea out to its natural operating shape: the dark factory. Instead of supervising individual agents, you manage the system that turns work items into bounded, reviewable changes.