Shipping Code with Hermes: A 7-Step Workflow for Building Your Dream App

I have an AI agent that writes code for me. Not “helps me write code” — writes it. Commits it. Opens PRs. Runs tests. Fixes the failures. Ships.

His name is Nick. He runs on Hermes Agent. Over three months, we built Muchiround — commerce, social, logistics, wallets, and AI on a multi-tenant Rails platform — across dozens of sessions and hundreds of tool calls.

This isn’t a think piece about AI. It’s a practical workflow you can follow. Seven steps, from install to shipped app. Each step is something we actually did. Let’s go.

Step 1: Install and Configure

Install Hermes, then point it at your project.

pip install hermes-agent
hermes setup

The setup wizard walks you through model selection, tool configuration, and messaging platform connections. Pick a model with strong tool-use — we use GLM-5.2 via Nous, but Claude Sonnet or GPT-4o work too.

Then connect your tools. Hermes needs:

• A terminal (local shell access)
• A filesystem (read/write files)
• A browser (for visual QA)
• The web (search, extract content)

hermes setup tools
hermes setup terminal

You’ll know it’s working when hermes status shows green across the board.

Step 2: Write the Context File

Hermes reads an AGENTS.md file in your project root. This is your agent’s system prompt — it tells the agent what the project is, what conventions to follow, and how to run things.

# Muchiround

Rails 8 monolith with multi-tenant architecture.

## Commands
- Dev server: `bin/rails server -p 5000`
- Tests: `eval "$(mise activate bash)" && bundle exec rspec`
- Linter: `bundle exec rubocop`

## Conventions
- API routes scoped under `/api/v1/<domain>/`
- Use money-rails for all currency handling
- Sharp borders (border-border rounded-lg) on all cards
- Mobile-first, progressive disclosure UX

This file is the single highest-leverage thing you’ll write. Every session starts here. The agent reads it before touching code. If something goes wrong, the fix usually goes in here.

We learned this the hard way. Early on, Nick didn’t know we use mise for Ruby version management. He’d run bundle exec rspec and get a Ruby version error. He’d try to debug it. Ten minutes wasted. Once we added eval "$(mise activate bash)" to AGENTS.md, he never hit that error again.

Step 3: Build Memory

Hermes has persistent memory across sessions. Two stores: user preferences and operational notes. Both are injected into every new session.

You don’t configure this manually — the agent saves facts as it learns them. But you can accelerate it by telling it your preferences upfront:

“I prefer direct execution over descriptions. I use mise for Ruby. I want sharp borders on all UI cards. Treat the money gem as the single source of truth for currencies.”

Nick saved each of these to memory. Now, session 100 is as productive as session 5 — because the accumulated knowledge compounds. He never asks me which Ruby version we use. He never asks if he should use git add -A. He knows.

The discipline: save facts that will matter in 6 months. Don’t save task progress or commit SHAs — those go to session history, which is searchable via session_search.

Step 4: Run the Feature Loop

This is the core workflow. Everything else is a variation of it.

You describe intent. The agent executes. Here’s the loop:

Describe — “Add RBX fee indicators next to comment submit actions across all commentable domains.”

Investigate — Before writing code, the agent reads the codebase. It runs search_files to find all commentable views, reads each one, checks the model layer, looks at the routes. No guessing. If it hasn’t seen it in the repo, it goes and looks.

Implement — Changes go through patch and write_file. The patch tool does fuzzy find-and-replace, so minor whitespace differences don’t break edits. No code blocks printed to chat — actual file edits.

Verify — The agent runs the build and tests:

npm run build
# or:
eval "$(mise activate bash)" && bundle exec rspec spec/requests/commentable_spec.rb

If tests fail, it reads the output, diagnoses the root cause, fixes it, and re-runs. It stops at “passing,” not at “I found the problem.”

Ship — “Open a PR.” The agent stages relevant files, writes a conventional commit message, pushes, and opens a GitHub PR with a structured description:

feat: add RBX fee indicators across commentable domains

## What Changed
- Inline RBX fee indicators next to submit actions in:
  - Standard Posts (app/frontend/pages/post/show.tsx)
  - Direct Replies (app/frontend/pages/reply/show.tsx)
  - Launch Directory (app/frontend/pages/discovery/show.tsx)
  - Newsletter Editions (app/frontend/pages/pulse/editions/show.tsx)

## Risk
Low. UI-only changes, no backend logic affected.

Total elapsed: 12 minutes. Before Hermes, this was a 2-hour task.

Step 5: Save Skills

When the agent learns a non-trivial workflow, it saves it as a skill. Skills are markdown files with exact commands, step-by-step instructions, and pitfalls. They load automatically when a task matches.

You don’t trigger this manually either — but you can nudge it:

“Save what you just did as a skill so we don’t have to figure it out again.”

The first time we set up a self-hosted Pelias geocoder, it took 3 hours of trial and error. Nick saved the entire process as a skill: Docker Compose config, data import commands (in the right order — Pelias is picky), API endpoint format, the verification curl command. The second time, on a new server, it took 15 minutes. The skill loaded and he followed the steps.

After three months, we have dozens of skills. Each one makes the next session faster. The compounding effect is real — session 50 is dramatically faster than session 5, not because the model got smarter, but because the skills and memory built up.

Skills rot though. When we switched our test suite to rspec-retry for flaky PostGIS tests, the old testing skill was wrong. Nick patches skills immediately when he discovers they’re outdated — it’s built into his instructions. A wrong skill is worse than no skill.

Step 6: Delegate Parallel Work

Some tasks are embarrassingly parallel. That’s where subagent delegation comes in.

When we needed to migrate 35+ ERB view files from inline styles to a new semantic design system, doing it one file at a time would take days. So Nick spawned subagents — each one gets its own conversation, terminal session, and tool access. Only the final summary returns.

# Pseudocode for the delegation pattern
tasks = [
    {
        "goal": "Redesign social/search/profile views",
        "context": "Files: _post.html.erb, search.html.erb, profile.html.erb. "
                   "Replace inline styles with .card, .text-headline classes. "
                   "Remove all decorative emojis."
    },
    {
        "goal": "Redesign commerce views",
        "context": "Files: cart.html.erb, product.html.erb, checkout.html.erb..."
    },
    {
        "goal": "Redesign messaging views",
        "context": "Files: messages.html.erb, message_thread.html.erb..."
    }
]

delegate_task(tasks=tasks)  # All three run in parallel

The critical insight: subagents have no memory of the parent conversation. You must pass all relevant context explicitly. “Redesign the commerce views” produces generic work. “Redesign cart.html.erb — replace style=\"color: var(--color-success)\" with class=\"text-success\", remove the emoji, add for attributes to all labels” produces precise work.

We learned the limit the hard way too. Early on, Nick tried to batch all 30 remaining files into a single wave. The subagents produced inconsistent results because the design system was still evolving. The fix: small, focused refactors. One file at a time for the tricky ones, small batches for the mechanical ones.

Step 7: Automate and Review

Not everything needs you in the loop. Hermes can run scheduled jobs:

schedule: "0 6 * * *"
prompt: "Read overnight CI failures from the last 12 hours.
         Categorize: flaky, broken, or environmental.
         For flaky tests, re-run them once.
         For broken tests, open a GitHub issue.
         Post a summary to Telegram."
workdir: "/home/kuda/work/zim-platform"

The job runs in a fresh session — the prompt must be self-contained. This is a constraint that forces clarity: if you can’t describe the task in a self-contained prompt, you don’t understand it well enough to automate it.

For code review, every PR goes through an automated pipeline:

1. Diff analysis — categorize changes by risk
2. Security scan — SQL injection, XSS, hardcoded secrets
3. Quality gates — RuboCop, ESLint, Brakeman
4. Inline comments — posted to GitHub on specific lines

The agent flags issues. You make the decisions. For critical paths — payments, auth, data migration — read every line yourself. For everything else, trust the review and skim the diff.

And for visual QA, Hermes doesn’t just curl endpoints. It opens a real browser, navigates to the page, takes a screenshot, and checks for layout issues, overflow, contrast failures. API responses don’t catch a button that’s off-screen on mobile. Eyes do. Hermes has both.

The Mental Model

An assistant waits for instructions. A chief of staff operates: you give intent, the agent gives execution.

You’re not writing code anymore. You’re directing work, reviewing output, and building the system of skills and memory that makes the agent better over time.

Seven steps. Install, configure, remember, build, save, delegate, automate. Each step compounds on the last. By step 50, you’re not 10x faster — you’re operating like a team of five, and the agent never sleeps.

Feels like magic, right? Now you know the trick. There is no trick. Just files, memory, skills, and a model that reads instructions carefully. Build the system, and the magic becomes routine.

And routine, in engineering, is called shipping.

Running a full agentic company on top of this loop? Start here: The Agentic Company · Shipping production at speed · How we work.