Designing an AI-Operable Release Workflow

Source: Dev.to

What My Release Process Looks Like Now

When I release a new version I simply say:

“Release version 1.2.0.”

That’s it.

I no longer:

• build packages
• run tests manually
• check CI logs
• verify tags
• push artifacts
• coordinate release order

The AI does all of that — not by blindly executing scripts, but by reasoning about what should happen next.

This Is Not Automation

The distinction matters.

The AI validates README consistency, checks semantic versioning, verifies branch state, creates tags, triggers GitHub Actions, publishes to NuGet — and explains why at each step.

I call this pattern Decision/CD: the pipeline doesn’t just execute, it decides.

The Workflow I Designed

Here’s the actual release flow I use for my OSS project:

Local → RC → Verify → GO/NO‑GO → Tag → Stable → Publish

flowchart TD
    A["Local prep\nbuild/test + docs"] --> B["Publish RC\n(GitHub Packages)"]
    B --> C["Download RC & verify\n(restore + smoke test)"]
    C --> D["GO decision\n(coordinator)"]
    D --> E["Lock commit hash"]
    E --> F["Publish stable\n(nuget.org)"]
    F --> G["Aftercare\ndocs + announcements"]

Each stage has conditions, evidence requirements, and clear ownership.

Roles: Who Does What

In my workflow these roles are assigned to AI agents. The human (me) only handles the coordinator role — i.e., the GO/NO‑GO decision.

Decision Gates: Where Human Judgment Lives

The GO/NO‑GO decision requires all of the following to be true:

• ✅ Unit tests are green
• ✅ Physical tests are green (with evidence)
• ✅ Diff log recorded (if changes exist)
• ✅ README works as user documentation

If the conditions are met I say “GO.” The AI then handles everything else.

The CI/CD That Makes It Work

Two simple GitHub Actions workflows power this:

RC Publish (triggered on release/** branch push)

on:
  push:
    branches:
      - "release/**"

This workflow builds, tests, packs with a -rcN suffix, and pushes the artifact to GitHub Packages.

Stable Publish (triggered on v*.*.* tag push)

on:
  push:
    tags:
      - "v*.*.*"

This workflow validates SemVer, runs tests, packs the stable version, and pushes it to nuget.org.

That’s it. The AI creates the branch, verifies conditions, creates the tag — and the pipelines do the rest.

A Real Interaction

Below is a trimmed transcript of an actual release session.

Human: Check the README.

AI:

Conclusion: The English in README.md is clear and accurate.
Reasoning:
- Meaning is clear and concise
- Technically accurate
- Consistent with other documentation
Suggestion: Let me know if you need consistency checks on other READMEs.

Human: Commit and push.

AI:

Conclusion: Commit and push completed.
Reasoning:
Commit: docs: translate src README
- Changed: README.md (English translation)
release/1.2.0 pushed to remote
Suggestion: Let me know if other READMEs need English consistency checks.

Human: Merge to main and release to NuGet.

AI:

Conclusion: Merged release/1.2.0 to main. NuGet release requires a tag.
Reasoning:
- main now includes latest from release/1.2.0
- Release is triggered by v*.*.* tag push (per nuget-publish.yml)
- VersionPrefix in Directory.Build.props is 1.2.0
Suggestion: Ready to create and push v1.2.0 tag? (If OK, I'll run `git tag v1.2.0` → `git push origin v1.2.0`. Please confirm NUGET_API_KEY is set in GitHub Secrets.)

Human: Create and push v1.2.0 tag.

AI:

Conclusion: Created and pushed v1.2.0 tag.
Reasoning:
- git tag v1.2.0 executed
- git push origin v1.2.0 executed
- Matches NuGet publish workflow trigger conditions
Suggestion: GitHub Actions workflow "Publish stable to nuget.org" should now be running. Let me know if you need completion confirmation.

Pattern Summary

No manual verification after the decision gate. The entire release — from verification to NuGet publish — took four human messages.

Why Most AI Workflows Fail

Typical AI usage in development looks like this:

• ❌ “Write code for me”
• ❌ “Fix this bug”
• ❌ “Optimize this function”

That’s outsourcing, not a workflow. There’s no structure, no decision gates, no evidence requirements, and no ownership model. The result is unpredictable.

The Division of Labor

The human decides what and whether; the AI handles how and when. This separation makes the workflow operable.

What Makes a Workflow “AI‑Operable”

A workflow is AI‑operable when:

1. Stages are explicit – the AI knows exactly where it is and what the next step is.
2. Inputs/outputs are well‑defined – each stage consumes and produces concrete artifacts (e.g., a tag, a package, a log).
3. Evidence requirements are codified – the AI can verify conditions (test results, diff logs, README checks) before proceeding.
4. Decision gates are isolated – only the human can make the GO/NO‑GO call; everything else is automated and justified.
5. Ownership is assigned – every stage has a responsible “agent” (human or AI) so accountability is clear.

When these criteria are met, the AI can act autonomously while still keeping the human in the loop where judgment matters.

TL;DR

I no longer build, test, or publish manually. I just declare “Release vX.Y.Z.” The AI validates everything, creates the branch, tags the commit, and lets the CI pipelines do the heavy lifting—all while explaining its reasoning.

# It Is in the Process

**Conditions are verifiable** — The AI can check them programmatically.  
**Evidence is defined** — The AI knows what proves success.  
**Decision points are marked** — The AI knows when to stop and ask.  
**Failure modes are specified** — The AI knows what to do when things break.

If your workflow has these properties, an AI can operate it. If not, you're just hoping for the best.

Final Thought

CI/CD automates pipelines. It does not automate decisions.

That’s the layer I built.

I didn’t make my workflow smarter. I made it operable by AI.

And that changed everything.

This is part of my “Beyond Prompt Engineering” series, where I explore human‑AI collaboration patterns that go beyond optimizing prompts. The workflow shown in this article is from Kafka.Context, an OSS project I develop entirely through human‑AI collaboration.