Write Repeat Processes as Code: Agent Workflow Codification in Practice

From "prompt collection" to "process code"

Every vibe coder has a few well-worn prompts in their collection: the pre-release checklist you make the agent run, the analysis routine before every refactor, the weekly dependency health scan. They work — but with a fatal flaw: every execution is an improvisation. The same checklist runs 5 steps today, 7 tomorrow, and skips the most critical one the day after.

GitHub's just-released Copilot Dynamic Workflows (which we covered yesterday) pushed this into the spotlight: processes can be written as code. Don't mistake this for one product's feature, though — it's an engineering paradigm: pull the "how" out of the prompt and into version-controlled, reviewable, testable programs. This guide covers when to upgrade, how to design, and which traps to avoid.

The upgrade signal: the third time you run the same process

The rule is simple: the third time you manually trigger the same multi-step process, consider writing it as code. The first time is exploration, the second is validation; if you're still copy-pasting prompts on the third, you're repeating labor in the most expensive way possible — your attention plus tokens.

Typical candidates: pre-release checks (run tests → scan dependencies → check migrations → draft changelog → pause for human confirmation); the new-feature trio (research → plan → implement → self-test); PR pre-screening (review changed files in parallel → run related tests → summarize risks); periodic patrols (weekly sweeps for slow queries, stale dependencies, security advisories).

Conversely, don't rush to codify: processes you've run only once (you don't yet know what the right steps look like); tasks that depend heavily on in-the-moment judgment (open-ended "does this code look off" questions); and processes that change faster than they execute — the code costs more than it ever pays back.

Design patterns: four building blocks

A good agent workflow, whatever tool implements it, combines four building blocks:

1. Sequence and parallelism. Dependent steps run in sequence (research before planning); independent ones run in parallel (review 5 changed files at once, query 3 systems' logs simultaneously). Parallelism isn't showing off — it compresses wall-clock time, the most directly felt cost of waiting on agents.

2. Structured handoffs. Stages pass structured data, not prose paragraphs: the research stage outputs JSON (risk list, affected-file inventory), and the implementation stage works from that JSON. Natural language drifts between stages; structured data doesn't. This is the core advantage of workflow-as-code over "one long prompt."

3. Cross-verification. Have a second agent (or a different model) verify the first one's conclusions. GitHub's example is elegant: find unresolved comments on merged PRs, have two models independently judge whether they still matter, and report only when both agree. It doubles the cost, but the false-positive drop is usually worth it — especially for "should we bother a human" decisions.

4. Human checkpoints. Pause before irreversible operations: before releasing, before deleting data, before merging to main. The art of checkpoints is placement — too dense and humans become the bottleneck; too sparse and they're theater. Rule of thumb: gate only where mistakes hurt, let everything else through.

Writing your first workflow: the release checklist

Take the most common case — "pre-release checks." A minimal viable version looks like this:

Step one (parallel): agent A runs the full test suite and summarizes failures; agent B scans dependency updates and security advisories; agent C checks for unapplied database migrations. Three lanes in parallel, results merged in structured form.

Step two (branching): code branches on the merged results — all green, generate release-note drafts; failures found, classify them (test failures / dependency risks / missing migrations) and pause.

Step three (checkpoint): pause and push the classified issue list to you. You glance, click "continue" or "send back for fixes."

Step four (wrap-up): on continue — tag, generate changelog, notify; on send-back — feed the issue list to a fixing agent, then loop back to step one.

Note the division of labor: code owns the process, agents own the judgment. Branching, parallelism, and pausing are code's job; "how serious is this test failure" is the agent's job. Get the division wrong (e.g., letting the agent decide "whether to parallelize") and you're back to improvisation.

Three anti-patterns

Anti-pattern 1: hard-coding judgment too. Be wary of workflow rules like "reject the release if coverage drops below 80%" — thresholds expire. Better: let the agent assess "is this coverage drop acceptable," and let code only route the assessment to the checkpoint.

Anti-pattern 2: workflows that are too long. Past ~7 steps, maintenance cost grows exponentially. Split into two small ones — one for "checking," one for "releasing" — connected by a human checkpoint. Small workflows joined by human gates beat one giant workflow for robustness.

Anti-pattern 3: no escape hatch. Every workflow needs a manual-takeover entry: if the agent gets stuck on a step, a human can execute that step directly and let the flow continue. Automation without an escape hatch becomes a production incident at the first anomaly.

The one-line summary

A prompt says "here's how I'd like you to do it"; a workflow says "this is how it must be done." When your vibe project moves from "it works" to "it ships reliably," writing repeat processes as code is the step from workshop to assembly line. Start with that checklist you've used three times — tonight.