Spec to ship: fitting AI into my daily dev loop

My daily work as a developer is a loop. Pick up a ticket, understand it, change some code, open an MR, move the ticket. This post is about how I have been fitting AI into that loop. There is no exotic new platform involved, just glue between tools I already had open every day: Claude Code, Jira, cron, and Hermes Agent.

In my ESM migration post I ended up with a supervised workflow. I broke the work into small pieces, let the agent build one piece, and examined it before moving on. That was about surviving one big task. This post is about the ordinary day, and the question of where an agent actually belongs in it.

How I got uncomfortable

I have been using AI tools from pretty early on, and I have watched them evolve quickly. I started with Cursor just to fix bugs. Now I can ship entire features with an agent. And that is exactly what started to bother me.

I caught myself just hitting enter and clicking yes. Every time, the AI made the feature happen, and at some point I couldn't tell what value I was adding anymore. I was simply trusting the output. That made me stop and think about the balance. What should the AI do, and what should a good developer keep doing as a human? What does a workflow look like that keeps the judgment with the engineer, but still uses AI for all the speed it genuinely offers?

Where the time actually goes

Think about what picking up a ticket really costs. Even when you know the area, you spend real time reading the ticket, the comments, the linked pages, and the code around the change before you touch anything. This is exactly where AI shines. Given specific context, it can tell you which lines need to change, and it will read every comment and every linked document without getting bored.

So the first half of the workflow is to hand the agent the ticket, let it investigate the code, the commit history, and all the linked context, and have it write a spec instead of code. The spec says what the problem is, what needs to change, where the catches are, and what the coding agent will need to know. Nobody codes yet.

Then I review the spec. That review is the whole point, and I will come back to it.

The setup

Why Hermes Agent

The assistant side runs on Hermes Agent, which is a different kind of tool from a coding agent, and the difference matters more than I expected. A coding agent forgets everything when you close the session. Hermes keeps its memory, runs with profiles (my work profile points at the work vault and the Jira connection), and has a gateway process that lets it run cron jobs. Given an instruction, it can even create its own skills. I described the workflow I wanted, and it wrote the "pull a ticket" and "create a spec" workflow documents itself.

That persistence is why it earns a place in the stack. Every ticket it pulls, every log it writes, every spec that comes back through review adds to its memory, so the assistant grows with the project instead of starting from zero each morning. In theory, the more of the project's history the agent can see, the closer its output gets to what an engineer who lived through that history would produce.

Why a brains vault

The shared memory is a folder of plain markdown I call the brains vault. The name and the shape are borrowed from Obsidian, where I already keep my personal notes, so the agents get a vault of their own instead of a new database to maintain. There is no special app behind it, which is the point: any agent that can read files can use it.

brains/work/
  Registry.md            ← the join point: Jira key → codebase → vault folder
  Workflows/             ← how tickets sync, how a ticket becomes a spec
  Templates/             ← Ticket.md, Spec.md
  Projects/
    <project>/Tickets/<KEY>.md
    <project>/Specs/<KEY>-spec.md
  Daily/  Inbox/  ...

Registry.md is the piece I would keep even if I threw everything else away. It maps each Jira board to a codebase path and a vault folder, so a bare ticket key like XXXX-1675 resolves to a ticket file, a spec file, and the repo to investigate. Any agent can construct the exact path instead of searching for it.

How a ticket becomes a spec

Filling the vault is Hermes's job. It connects to Jira through the Atlassian MCP server, and a scheduled cron job keeps my open tickets synced into the vault, including the description, the comments, and even the attached screenshots, so an agent doing an investigation can actually look at them. The sync is incremental, and only tickets that actually changed get re-pulled, which matters when you are paying for tokens. Jira stays the source of truth; the vault file is just a readable copy.

The other half is turning a ticket into a spec. I run it as a custom command in Claude Code, /investigate XXXX-1675, but it works just as well as a Hermes skill, since both simply follow the Create-Spec workflow stored in the vault. The agent reads the ticket file, investigates the codebase, and writes a spec with five sections: Goal, From the ticket, Current code, Plan, Open questions. The one rule that matters is that the agent plans only. It never implements, never commits, and never invents requirements that are not in the ticket.

Where the setup goes next

Today the pipeline stops once the spec is written. The next workflows to hand Hermes are the mechanical tail of the loop: commit and push, open the MR with a proper write-up, move the ticket, and post a steps-to-test comment for the reviewers. The part I am most curious about is letting an agent record the screen while it walks through those test steps itself, then pasting the recording into the ticket. If the agent can demonstrate the feature working, that is a better handoff than any comment I would write by hand.

Agents do the work, you keep the gates

Everything in this workflow follows from one rule. The agents do the work, and the developer keeps two gates.

Gate A comes before any code exists. Is the spec right? Wrong plan in, wrong code out. Read the spec the way you would read a colleague's plan, adjust it until you would be willing to implement it yourself, and only then approve it. The agent has done the digging, but whether the plan makes sense is your call. This is where being an engineer actually matters.

Gate B comes before anything ships. Is the code right? Did it follow the spec? Is there anything extra, unsafe, or unfinished? You read the diff, and only then does the change leave your machine.

Both gates are owned by the developer. Nothing else in the pipeline needs to be.

Eight steps, two of them are you

Here is the full line, from ticket to shipped:

Steps 3 and 5 are the two gates, approving the spec and approving the code. Everything after Gate B is pure mechanics with no judgment in it, which is exactly why it is the tail I am handing to Hermes next.

I have the first steps working (pull ticket, investigate, generate spec) and I have run them on real tickets. The specs come back as genuinely good summaries of what to look at, where the catches are, and what the coding agent needs to do. Some days they will be wrong. That is what Gate A is for.

Never outsource your judgment

This is the part I care most about.

The newer models changed behavior in a way that worries me a little. Around Opus 5, the agents stopped laying out their plan by default. They just make it happen. You follow the instructions, and the feature appears. It is impressive, and it is exactly how a developer ends up copy-pasting a ticket into a chat window and calling it a day.

The workflow above is my answer to that feeling. Let the agent do the investigation, the typing, and the mechanics, all of it. But the two decisions, "this plan is right" and "this code is right," never get delegated. The moment you outsource those, you are not supervising the work anymore. You are just forwarding it.