Luis M. Gallardo D.

Luis M. Gallardo D.

From Idea to Draft PR with Hermes Kanban

4 minute read

Hermes Kanban AI agent delivery header

I am experimenting with a more structured way to use AI coding agents.

Not as a one-shot assistant where I say “fix this bug” and hope the result is good, but as a delivery workflow:

goal -> plan -> implementation -> review -> draft PR -> human approval

The tool I am using for this is Hermes Kanban.

The idea is simple: every feature or fix becomes a durable task, with clear ownership, review steps, and handoffs between agents. Instead of keeping everything inside a long chat, Hermes Kanban gives the work a lifecycle.

Goal-driven coding agent workflow with Hermes Kanban

Why Not Just Ask an Agent to Code?

AI coding agents are powerful, but they can still fail in predictable ways:

  • They jump into code too early
  • They misunderstand the actual goal
  • They make plausible but incomplete changes
  • They review their own work too generously
  • They lose context across long conversations

For small tasks, that may be acceptable.

For real product work, I want something more reliable. So I am building a workflow where the agent does not start by editing files. It starts by understanding the goal.

The Workflow

The process begins with a feature request, bug, or product goal.

From there, the orchestrator creates a plan:

  • What needs to change?
  • What is the expected behavior?
  • What areas of the codebase are involved?
  • What does “done” mean?
  • What should be tested or reviewed?

Once the plan is clear, Hermes Kanban creates the implementation task.

The implementation agent works on the change, usually inside a dedicated branch or worktree. When it finishes, it does not mark the work as done immediately. Instead, it hands the result to one or more reviewer agents.

The reviewers check the diff, the tests, and whether the change actually satisfies the original goal.

If something is wrong, the task goes back into the loop:

implement -> review -> fix -> review again

Only when the review passes does the workflow produce a GitHub draft PR.

That draft PR is the handoff point for me.

The agents can investigate, implement, test, and review, but I still decide whether the change should be merged.

Human Approval Stays in the Loop

This is an important boundary.

I do not want agents silently merging code or promoting changes to production. The goal is not full automation without control.

The goal is leverage.

I want AI agents to handle the repetitive engineering work:

  • Investigating issues
  • Editing code
  • Writing or updating tests
  • Checking diffs
  • Preparing PRs
  • Summarizing what changed
  • Surfacing blockers

But I still want human approval for decisions that matter:

  • Product behavior
  • Architecture tradeoffs
  • Merge approval
  • Production releases

In this setup, the agents move the work from idea to review-ready PR. I remain the final gate.

Why Hermes Kanban Helps

A normal chat session is temporary. It can be useful, but it is not a great structure for multi-step delivery.

Hermes Kanban gives each task a state: ready, running, blocked, or done. Review can be another explicit task instead of a vague comment buried in a chat.

That makes handoffs visible. One agent can implement, another can review, and a later task can handle deployment or follow-up work.

That matters because real engineering work is rarely just “write code”. It involves decisions, review, feedback, and iteration.

Kanban gives the agents a shared operating model.

The Pattern I Am Aiming For

The workflow I want is:

1. Start with a goal
2. Challenge assumptions
3. Create a plan
4. Define success criteria
5. Implement autonomously
6. Review independently
7. Produce a draft PR
8. Wait for human approval

That is the shift I care about.

Not “AI writes code”.

More like:

AI agents move a task through an engineering delivery pipeline, while the human keeps control of the important decisions.

Early Lessons

A few things are already clear.

First, the plan matters more than the model. A strong model with a vague task still produces vague results.

Second, review must be explicit. If the same agent that wrote the code is the only reviewer, problems are easier to miss.

Third, agents need boundaries. In my case, the boundary is the draft PR. They can prepare the work, but they do not merge without approval.

Finally, feedback should go back into the workflow. If I request changes, that feedback becomes new input for the next iteration, not just a random chat message.

Final Thoughts

AI coding agents are becoming good enough to do meaningful engineering work, but the workflow around them matters.

For me, Hermes Kanban is a way to make that workflow more reliable.

It turns agent work into something closer to a delivery system:

goal -> plan -> build -> review -> draft PR -> human sign-off

That structure is what makes the difference between an impressive demo and something I can actually use to ship features and fixes.

You May Also Enjoy