DEV Community

Cover image for Designing an AI-Operable Release Workflow
synthaicode
synthaicode

Posted on

Designing an AI-Operable Release Workflow

#ai #devop #automation #productivity

I Don't Release Software Anymore. I Just Declare It.

Most people use AI to write code.

I don't.

I use AI to run my development workflow.

Today, I want to show you something different: how to design a release process where the human only declares intent — and the AI handles everything else.

What My Release Process Looks Like Now

When I release a new version, I say:

"Release version 1.2.0."

That's it.

I no longer build packages, run tests manually, check CI logs, verify tags, push artifacts, or 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

This distinction is important.

Automation means: "Do these steps faster."

What I built is: A decision-aware workflow.

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: where the pipeline doesn't just execute, but 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
Enter fullscreen mode Exit fullscreen mode 
flowchart TD
  A["Local prep<br/>build/test + docs"] --> B["Publish RC<br/>(GitHub Packages)"]
  B --> C["Download RC & verify<br/>(restore + smoke test)"]
  C --> D["GO decision<br/>(coordinator)"]
  D --> E["Lock commit hash"]
  E --> F["Publish stable<br/>(nuget.org)"]
  F --> G["Aftercare<br/>docs + announcements"]
Enter fullscreen mode Exit fullscreen mode

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

Roles: Who Does What

Here's how I divided responsibilities:

Role Responsibility
Release coordinator GO/NO-GO judgment, final checklist
Implementor Build, API consistency, package verification
Physical test owner Run tests, record evidence, document conditions
Env/Infra owner Docker, Kafka, environment troubleshooting
Quality review README, examples, documentation review
Evidence & log Maintain diff logs, prevent gaps

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

Decision Gates: Where Human Judgment Lives

The GO/NO-GO decision requires:

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

If all conditions are met, I say "GO." The AI handles everything after that.

The CI/CD That Makes It Work

Two simple GitHub Actions workflows power this:

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

on:
  push:
    branches:
      - "release/**"
Enter fullscreen mode Exit fullscreen mode

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

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

on:
  push:
    tags:
      - "v*.*.*"
Enter fullscreen mode Exit fullscreen mode

This workflow validates SemVer, runs tests, packs the stable version, and pushes 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

Here's what an actual release session looks like:

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.

The pattern:

Human AI
4 short commands 4 structured reports
"Check" / "Push" / "Merge" / "Tag" Conclusion → Reasoning → Suggestion
No manual verification Decision gate before irreversible action

The entire release — from verification to NuGet publish — took 4 human messages.

Why Most AI Workflows Fail

Most AI usage in development looks like this:

  • ❌ "Write code for me"
  • ❌ "Fix this bug"
  • ❌ "Optimize this function"

That's not a workflow. That's outsourcing.

There's no structure. No decision gates. No evidence requirements. No ownership model.

When you outsource without structure, you get unpredictable results.

The Division of Labor

Here's how I think about human-AI collaboration:

Human AI
Intent Execution
Judgment Procedure
Responsibility Operations
Declaration Action

The human decides what and whether. The AI handles how and when.

This separation is what makes the workflow operable.

What Makes a Workflow "AI-Operable"

A workflow is AI-operable when:

  1. Stages are explicit — The AI knows where it is in the process
  2. Conditions are verifiable — The AI can check them programmatically
  3. Evidence is defined — The AI knows what proves success
  4. Decision points are marked — The AI knows when to stop and ask
  5. 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.

Top comments (0)