Spoke at Yurutech 'Something-Like-a-Study-Session' 2026.08 in Kumamoto — Autonomous Development with Hermes Agent
I spoke at Yurutech “Something-Like-a-Study-Session” 2026.08, held in Kumamoto. My talk was “Autonomous Development with Hermes Agent” and walked through the loop between handing off a GitHub Issue and getting a PR back, how Skills encode a repeatable development process, and why designing how the agent stops matters more than how autonomously it runs. I am also leaving short notes on the other two talks.
Event Overview
- Name: Yurutech “Something-Like-a-Study-Session” 2026.08
- Date: Friday, August 21, 2026
- Venue: Kumamoto
- I usually work fully remote, so on-site speaking is one of the last jobs left to humans, and I made the trip out for it
My Talk: “Autonomous Development with Hermes Agent”
The talk followed one thread: from GitHub Issue, to investigation and planning, to implementation and validation, to review, and finally to Human handoff, wrapped up in a single loop. The demo goal is not to generate code, but to move the Issue itself to a state where it can be completed.
flowchart LR
A[GitHub Issue] --> B[Investigate & Plan]
B --> C[Implement & Validate]
C --> D[Review]
D --> E[Human handoff]
From Code Generation to Autonomous Development
The contrast between chat-based and autonomous use lines up along four axes.
| Aspect | Chat-based | Autonomous |
|---|---|---|
| Who decides the next move | The human | The agent |
| Center of the workflow | Code generation | Goal completion |
| Who does the validation | The human reviews outputs | The agent validates via tools |
| Where state lives | Inside the conversation | In the Issue and the repository |
In chat-based use, state accumulates inside the conversation, so it disappears when the conversation ends. In autonomous use, state lives in the Issue and the repository, which is why a fresh session the next day can pick up where the previous one left off. My phrasing was: hand off state transitions, not code.
Hermes Agent Is a Runtime
Hermes Agent is easier to design against when you think of it not as an LLM in isolation, but as a runtime bundling the tools and context needed to finish a job. The human hands over goals, constraints, and evaluation; the runtime combines Tools (file, Git, browser), Skills (reusable procedures), Memory (carrying assumptions forward), and Delegation (separating implementation from evaluation) to move the work.
Skills Are the Code of the Development Process
A Skill is not a long prompt template. It is a reusable definition of who owns which step, what evidence advances the process, and where it must stop. In the demo, I introduced three Skills from oh-my-hermes.
| Phase | Skill | Role |
|---|---|---|
| PLAN | omh-plan-issue | Turn a request into a plan, then produce an implementation-ready Issue through independent reviews by codex and Claude Code |
| IMPLEMENT | omh-issue-loop | Starting from an Issue URL, drive implementation, local validation, multi-reviewer review, fix loops, PR, CI monitoring, and Human handoff. The Skill never merges; the final call goes back to the human |
| REVIEW | omh-pr-multi-review | Run and aggregate three Claude Code review passes and one codex review independently. Failed review runs are kept visible in the report, not hidden |
The framing: share reproducible procedures and stop conditions, not prompts.
How the Agent Stops Matters More than How Autonomously It Runs
To trust an agent with the loop, you need explicit stop conditions in addition to success conditions. I listed six on the slide.
- Do not report a test failure as success
- If a validation cannot be run, mark it unverified
- Anchor reviews to the actual diff under review
- Cap permissions, wall time, and fix iterations
- Surface technical blockers explicitly
- If evidence runs out, hand back to the human
The claim is that trust is not decided by how long the agent keeps running, but by whether it stops itself the moment it runs out of evidence.
Three Design Choices That Paid Off in Real Work
I distilled three design choices that have held up in day-to-day project use.
- Judge the goal mechanically: reduce success into a binary evaluation function (tests, type checks, lint, build, acceptance criteria, real-browser validation)
- Move context out of the conversation: put it where it survives a lost chat (Issue, AGENTS.md, docs, Skills, tests, PR checklist)
- Separate implementation from evaluation: run implementation, code review, security review, CI, and Human approval as distinct roles
Roll It Into an Organization Gradually
Do not open up permissions all at once. Widen the permitted surface as verifiability grows, roughly along this sequence.
flowchart LR
S1["1<br>Investigate & explain"] --> S2["2<br>Local implementation"]
S2 --> S3["3<br>Test & review"]
S3 --> S4["4<br>PR & CI verification"]
S4 --> S5["5<br>Deploy & prod verification"]
Starting with small, easy-to-evaluate Issues is the practical trick.
Wrap-Up
Three closing lines from the deck.
- Autonomous development is the automation of the development loop, not code generation
- The human’s job is to design the goal, the constraints, and the evaluation function
- Trusting the agent requires explicit stop conditions, not just success conditions
The one-liner I ended on: humans set the goal, AI runs the loop.
Notes on the Other Talks
”Engineering Harnesses and Loops” by Tomoki Takate
There was a lot of vocabulary overlap with my own talk, so I listened with quite a bit of sympathetic energy. The point that harnesses and loops apply beyond code generation, and land just as cleanly on video generation, stuck with me.
AI動画の進化すごすぎ
— 智基/Tomoki (@tomolld) August 10, 2026
芥川龍之介の蜘蛛の糸作ってもらったんだけど、セリフとかも自然で凄い pic.twitter.com/vpNkJHWrzz
Apparently the video above was produced for roughly 10,000 JPY in token spend. Designing a harness and writing the scenario is enough to get a coherent video back, which is genuinely impressive. It felt like the same story I was telling about code (lean into reproducible procedures rather than prompts) holds across modalities as well.
”Lost Technologies in the AI Era, Vol.1: RDB Indexes” by Ryo Ohno
An LT titled roughly as “let me talk loosely about a thing that gets used all the time but often used casually, the RDB index.”
The B-Tree internals, the column ordering of composite indexes, and how to reason about selectivity brought back memories of a university lecture. Even when the AI writes the query for you, the human side still needs to be able to read how much physical I/O that query will cost, and I felt that knowledge is well worth holding on to. The series title “Lost Technologies in the AI Era” is good branding, and I am looking forward to the next volume.
That’s all from speaking at Yurutech “Something-Like-a-Study-Session” 2026.08, on autonomous development with Hermes Agent, along with notes on the other talks, from the Gemba.