DEV Community: erin

Elves Work While I Sleep: A Night with GraphOps Autopilot

erin — Mon, 05 Oct 2026 08:24:07 +0000

There is a Grimm fairy tale called The Elves and the Shoemaker. A poor shoemaker cuts his last piece of leather, leaves it on his workbench, and goes to bed. When he wakes up the next morning, a beautifully finished pair of shoes is waiting for him. During the night, a band of elves had crept in and quietly stitched them together.

As a child, I thought it was just a fairy tale.

Lately, though, I've started leaving a single ticket out before bed, typing this into my terminal, and going to sleep:

/graph-ops:autopilot-tree <ticketId>

When I wake up and glance at the screen, the work is done. A plan has been drawn up, the work has passed review after review from several different angles, the tests have been run, and a PR has been opened. Even the bugs found along the way have been filed as separate tickets, and those have been taken care of too.

This article is a sequel to my earlier introduction, "Introducing GraphOps: An Easy-to-Use Graph Engineering Plugin for Claude Code
". That one covered how GraphOps works and how to use it. This time, I want to share what I learned from spending a few nights with the Autopilot feature that has since been added to GraphOps, letting the elves work while I sleep.

A Quick Recap

GraphOps is a ticket management plugin for Claude Code. File a ticket and run /graph-ops:process-ticket, and the work is assembled into an execution graph and carried out step by step.

When I wrote the previous article, a person still had to click an "Approve" button at every approval gate along the graph. Is this plan good to go? Is it OK to release? And so on.

The shoemaker still had to stay up at his workbench.

Enter the Elves

Autopilot is a mechanism that drives a ticket all the way to the end on its own judgment, instead of waiting for a person at those approval gates. It comes in two modes:

/graph-ops:autopilot-ticket <ticketId>: carries a single ticket through to the end
/graph-ops:autopilot-tree <ticketId>: carries that ticket, plus every ticket derived from it, through to the end

You can of course also start it from the "Autopilot" button in the Web UI. The confirmation dialog lets you choose between "Tree (this ticket and its descendants)" and "This ticket only."

And there isn't just one elf at work here.

The master elf (orchestrator): This is the session where you typed the command. The master elf doesn't sew any shoes. It only plans out the work.
Lead elves (child sessions): Independent Claude Code sessions that the master elf summons in separate terminals. Each elf takes charge of one ticket and, on a git worktree and branch dedicated to that ticket, handles everything from start to finish: refining the ticket, processing the execution graph, releasing, and deciding what to do with the carry-over items. When it's done, it sends the master elf nothing more than a short, one-to-three-line report.
Worker elves (subagents): Agents that a lead elf calls up for each node in the execution graph. One elf writes the plan, another implements, another reviews. During parallel reviews, many elves work at the same time.

The approval gates that used to wait for a person are now judged by the elves themselves. They check the deliverables against the ticket's completion criteria and approve unless they can name a concrete defect. Each decision is saved as a deliverable along with its reasoning, so you can read it back in the Web UI once morning comes.

Layer upon Layer of Review Gates

Is it really safe to leave everything to the elves?

That was my first thought, too. But as I watched the execution graphs, I noticed that the elves' work passes through layer upon layer of review gates.

The lineup of review gates is assembled per ticket. Starting from the plan and its plan review, the elves look at what the ticket involves and decide which reviews to include, whether to write tests, and whether to update documentation. There is no fixed template set in advance.

For a ticket that involves implementation and tests, for example, the review gates line up like this:

A review of the plan, then approval of the plan
A review of the test cases (the Gherkin test specification)
Parallel reviews of the implementation, such as code, QA, security, and non-functional reviews (which perspectives are included depends on the ticket)
A review of the test results
If the ticket updates documentation, a review of that documentation
If a report is written, a review of that report
Finally, approval of the release

The reviews don't just go around in circles forever. With each round, the tier is raised (Normal / Important / Final), and minor findings are passed along as "carry-over items" so the work can move on. Only newly introduced bugs and regressions, security problems, and serious findings that are still unfixed are never relaxed, no matter the tier. Each loop also has an iteration limit (3 by default), so it always ends eventually. If a ticket still hasn't passed after reaching the limit, it stops as "blocked" and waits for morning.

The gatekeepers are all different elves, too. An elf that reads the code, an elf that hunts for gaps in the tests, an elf that eyes every input with an attacker's suspicion. Different elves look at the same deliverable at the same time. What one elf misses, the elf next to it picks up. The workshop is quiet at night, but on the workbench, a fairly strict inspection is going on.

Even back when I was developing with the normal, pre-Autopilot flow, most of what I did at the approval gates was rubber-stamping. I'd open a deliverable that had already made it through stage after stage of review, nod, and click Approve. I almost never sent anything back.

With this many gates stacked up, there isn't much left for a person to catch at the final approval. Human judgment has become nearly unnecessary. That is my honest impression after using Autopilot.

My job has shrunk to just this: looking at the PR in the morning and deciding whether to merge it. (You can also configure it to stop at creating a branch, or to go all the way and merge.)

The Elves File New Tickets

Using tree mode (/graph-ops:autopilot-tree) took the quality up another notch.

While the elves are working, they sometimes find problems that are separate from the main task: a performance issue spotted by a review, a gap noticed during testing. These are the kinds of things a person would jot down as "I'll do it later" and then promptly forget.

The elves don't let them slide. Once a ticket has been released, they gather up the reviews' carry-over items, the open issues from the report, and the follow-up notes from the implementation notes, and sort them one by one:

Skip: Things outside the supported scope, harmless differences in wording, things that can't be verified without real hardware or an external environment, things that don't reproduce, and things already accepted in the plan or reviews. None of these become tickets.
Child tickets: Things that should be dealt with within the scope of this ticket. They are filed as new tickets with the current ticket as their parent. The master elf picks those tickets up as part of the same run, and elves in other terminals take care of them.
Backlog: Pre-existing problems that aren't part of the main task are bundled into a single backlog ticket and filed as a ticket with no parent. The master elf does not work on it during the run. It's a little something the elves leave behind.

Once an elf finishes a child ticket, it merges its branch into the parent's branch. Grandchildren's work goes into the child's branch, and the child's work goes into the parent's branch. Everything is merged from the bottom up, until it all comes together in the parent ticket's branch. The tickets in the tree are processed one at a time, in order.

"I'll do it later" actually gets done later. That's why tree mode improves quality.

A Record of One Day

One day, I decided to add a batch of new commands to a VS Code extension that collects commands for transforming selected text. It already had around 800 commands, so this was an extension of an existing feature.

That night, I filed the parent ticket and went to sleep with tree mode running. The ticket was to grow the 800 commands to 1,000.

The first elf took stock of the existing commands, designed which commands to add, checked them from a security standpoint as well, and then split the work into several tickets, filing them with its own ticket as the parent.

All through the night, terminals kept appearing on the screen, one after another. The master elf would pick up a ticket, hand the job to a lead elf, receive a short report, and reach for the next ticket. In a workshop with no one watching, that cycle went on all day long.

The elves implemented the twenty-odd commands listed in each ticket, and every time, code, QA, security, and non-functional reviews ran in parallel, followed by the documentation review and the approval gates.

The gates were doing their job. A process that took quadratic time. An expansion routine that could blow up explosively depending on the input. Tests that had been broken for a while. Everything the reviews found became grandchild tickets, and other elves fixed them. There were also problems caused by my local environment that weren't part of the main task, and those were left in the backlog as the elves' parting gift.

After working through a double-digit number of tickets, the run finished almost a full day later. The extension now had more than 1,000 commands, with nearly 200 newly added.

Bedtime Pays for the Time

Autopilot does not make the work faster.

Every gate it passes through triggers a review, and every rejection sends it around another loop. The more tickets are spun off, the more elves there are. It takes far longer than a person could sit there and watch.

But all of that happens at night, while the person is asleep.

By day, the shoemaker picks out the leather and decides what kind of shoes to make. In other words, he writes the ticket: what he wants to build, why he's building it, and what counts as done. As long as he writes that part carefully, the elves will work from that ticket through the night.

The hours we spend asleep were never producing anything to begin with. For work done in those hours, how long it takes hardly matters. In fact, precisely because you don't have to worry about time, you can add one more gate, or turn every crack found in the code and elsewhere into a ticket. You can go all in on quality without holding back.

Only one challenge remains: tokens.

The more gates and the more elves, the more tokens disappear. Just as the shoemaker had to pay for leather, the elves need to be fed. You'll have to decide how much to hand over based on your plan and your usage limits. This is the one cost that time can't cover for you.

Wrapping Up

When I wake up and open the terminal, an execution summary put together by the master elf is waiting for me. Which tickets got done? Which ones became child tickets, and which went to the backlog? Where did the elves approve something, and on what grounds? All of that can be read back in the Web UI. If any tickets stopped partway through (failed or blocked), that's where the shoemaker's work for the day begins.

On the workbench, the finished shoes are lined up. He picks them up and decides whether to put them in the shop. That's all the shoemaker's job is now.

Finally, let me sum up what I've covered:

Thanks to layer upon layer of review gates, approval becomes mostly rubber-stamping, and human judgment is hardly needed anymore
In tree mode, cracks found along the way get fixed as child tickets, and anything outside the main task is left in the backlog. "I'll do it later" actually gets done
It takes time, but bedtime pays for it. That's why you can go all in on quality
The only remaining challenge is token consumption

GraphOps is available on GitHub. Why not leave a ticket on your workbench tonight?

https://github.com/imahiro-t/graph-ops

Introducing GraphOps: An Easy-to-Use Graph Engineering Plugin for Claude Code

erin — Tue, 15 Sep 2026 14:38:01 +0000

In my day-to-day engineering work, I've been driving development by combining ticket-driven development (using Jira) with Graph Engineering (AI-driven development powered by execution graphs). While introducing graph engineering has significantly elevated the quality of our AI outputs, Jira itself can feel a bit heavy and over-engineered for solo developers or small, agile teams.

I wished there were an easier, more lightweight way to reap the benefits of graph engineering.

That's why I created and open-sourced GraphOps, a Claude Code plugin that combines lightweight ticket management with execution graphs (DAGs / parallel execution / loopbacks)! It requires no local build setup—you can control everything directly via Claude Code slash commands and an intuitive Web UI.

Far from being just another ticket-tracking tool, GraphOps' standout feature is how it structures a ticket's workflow into a dynamic execution graph made of "nodes" and "edges." It orchestrates autonomous, parallel execution to maximize the performance of AI agents.

In this article, I'll walk through the development experience GraphOps unlocks, the mechanics of how graph engineering elevates output quality, and how you can get started right away.

Why "Graph Engineering"?

When handing off a task to an AI coding assistant (like Claude Code) with a single, open-ended prompt like "Please implement feature X," developers commonly run into several pain points:

Misaligned Assumptions & Premise Drift: The agent jumps straight into writing code without validating plans or architecture, only for fundamental design flaws to surface later.
Overlooked Review Perspectives: Beyond basic code syntax and cleanliness, critical multidimensional checks—such as security, QA edge cases, non-functional requirements (performance, logging, availability), and accessibility—are rarely handled thoroughly in one pass.
Ambiguous Rework & Context Pollution: When a test fails, the agent often attempts haphazard in-place fixes, leading to messy regressions, infinite loops, and token-heavy context pollution.
Black-Box Execution: It’s difficult for humans to see which stage the AI is currently in and why it made specific design decisions along the way.

Graph Engineering is a proven paradigm designed to tackle these exact problems, and it served as the core motivation behind building GraphOps.

Solving Challenges with Execution Graphs (DAG + Loops + Parallelism)

In GraphOps, every ticket's tasks are dynamically assembled into an execution graph:

Independent & Parallel Review Gates (review_gate): Multiple distinct perspectives—Code Quality, QA, Security (OWASP Top 10, etc.), Non-Functional Requirements (scalability/logging), and Accessibility (WCAG, etc. for UI changes)—are audited concurrently by independent subagents.
Loopback Structures for Automated Rework (loop_back_to): If a review gate fails or raises issues, the graph automatically loops back to the preceding implementation node. To prevent runaway infinite loops, built-in convergence controls relax criteria as iteration counts increase.
Human-in-the-Loop Approval Gates (approval_gate): By default, human approval gates are placed after the planning phase (plan_approval) and just before release (release_approval). Even if automated plan reviews pass, implementation will not start until a human signs off. Approvals can be granted with a single click from the Web UI, and rejections require a reason (free text), allowing the AI to re-triage context and automatically redo only the necessary nodes.

💡 Token Consumption vs. Output Quality
By formalizing a graph structure with explicit stages (Planning → Review → Approval → Implementation → Multi-perspective Parallel Reviews → Testing → Reporting) executed by dedicated subagents, the context processed by the AI naturally increases. Token consumption and execution time will undoubtedly rise (higher cost).

However, costly rework stemming from premise drift and missed requirements drops dramatically. Because plans are scrutinized before code is touched and implementations are vetted from specialized review angles, hallucinations and omissions are curtailed, yielding high-precision deliverables on the first pass. Because deliverables and artifacts from every node are cleanly persisted in the database and visible in the Web UI, the overall boost to development efficiency and peace of mind is substantial!

3 Core Components of GraphOps

GraphOps is architected around Claude Code in a minimal yet robust manner:

Go Core Binary (graph-engine):
- A single, CGO-free Go binary (utilizing a pure-Go SQLite driver) acting as both a CLI tool and a REST API server. Cross-compiles across macOS, Linux, and Windows.
- Manages persistence for tickets, nodes, edges, and deliverables (artifacts). Uses SQLite by default with zero config, but supports switching to MySQL for team collaboration.
- The engine handles graph expansion, DAG validation, convergence control, and artifact validation (such as HTML structural checks for reports).
Claude Code Plugin (@graph-ops/plugin):
- Exposes slash commands and skills (/onboarding, /create-ticket, /refine-ticket, /process-ticket, /ui).
- Dispatches dedicated graph-node-agent subagents to perform work node-by-node, running parallelizable nodes concurrently in the background.
Web UI Application (@graph-ops/web):
- A modern, responsive dashboard built with React, Tailwind CSS, and @xyflow/react.
- Features paginated/searchable ticket management with priority indicators, real-time interactive execution graph visualization, formatted artifact previews (Gherkin, Markdown, HTML), one-click approval/rejection for approval gates, and configuration editing.

Development Flow (The Practical Workflow)

A typical workflow with GraphOps proceeds as follows:

Launching the Dashboard: `/ui` (Web UI Visualization)

Simply run /ui in your project's working directory. It automatically spins up the background backend server if not already running, and opens your browser directly to the ticket list and execution graph for that project (or prompts a "New Project" modal if unregistered).

Subsequent actions like creating tickets, refining them, or running them can be driven directly from Claude Code or with a single click from the Web UI.

1. `/create-ticket` (Interactive Ticket Drafting)

When you submit a request, Claude Code doesn't just create a ticket blindly. It engages in a brief dialogue to clarify scope, edge cases, and impacted files before registering the ticket in the DB.

2. `/refine-ticket` (Articulating Acceptance Criteria & "Why")

Collaborate with the AI to crystallize concrete acceptance criteria (Definition of Done) and the underlying "Why" (background and motivation), updating the ticket's description with sharp, actionable requirements.

3. `/process-ticket` (Graph-Driven Execution)

Now, autonomous graph execution takes over:

Seed Execution: The "Plan Creation (plan)" and "Plan Review (plan_review)" seed nodes run first.
Dynamic Graph Assembly: Once the plan passes review, the AI analyzes the nature of the ticket (investigation-only, standard feature, UI changes, etc.) and dynamically builds an execution graph patch tailored to the task (wiring up code, QA, security, accessibility review gates, and documentation steps).
Approval Gates & Parallel Execution: A human approves the plan (plan_approval). Then implementation kicks off, followed immediately by parallel review subagents auditing different facets simultaneously.
Testing & Fixed HTML Reporting: Gherkin behavioral tests run, results are reviewed, and a structured HTML test report (with summary, checks, and captures) is generated and saved as an artifact.
Release Approval: Finally, a human signs off on the release approval gate (release_approval) to wrap up.

Key Highlights

Here are some of the most compelling aspects of GraphOps:

1. Dynamic Graph Generation Tailored to Ticket Content

Workflows aren't confined to a rigid, one-size-fits-all pipeline. For example, for a documentation-only ticket, heavy Gherkin tests are omitted; for tickets involving UI changes, an accessibility review gate is automatically injected. The AI constructs an optimal execution graph based on the approved plan.

2. Multi-Tiered Customization for Team Guidelines

Configuration files merge hierarchically: Plugin Defaults → User Config (~/.graph-ops/) → Project Config (.graph-ops/).

Add or override team-specific review criteria (e.g., custom naming conventions, architectural rules).
Define custom node types and prompt instructions in Markdown inside your repo.
Customize skill behavior or swap the HTML report template for your organization's theme. All of this is achievable without touching plugin source code—just add YAML or Markdown files, or edit them straight from the Web UI's Settings modal.

3. Launching Interactive Claude Code Terminals from the Web UI

Clicking "Create", "Launch Claude", "Run", or "Refine" buttons in the Web UI immediately opens an external, interactive terminal (Terminal.app on macOS, tmux, iTerm2, etc.) running Claude Code. You can press Cmd+Enter (Mac) or Ctrl+Enter (Windows) to submit prompts without taking your hands off the keyboard, keeping full human control while enjoying the convenience of a browser dashboard.

Installation & Getting Started

No local build or compilation is required. You can install GraphOps directly inside Claude Code using the marketplace commands:

1. Add the Marketplace

Run the following command inside Claude Code to register the GraphOps marketplace:

/plugin marketplace add imahiro-t/graph-ops

2. Install the Plugin

Next, install and enable the plugin:

/plugin install graph-ops@graph-ops

Automated Platform Binary Resolution
During the initial install, the precompiled Go binary (graph-engine) matching your OS and architecture (macOS Apple Silicon / Intel, Linux, Windows) is automatically downloaded from GitHub Releases, verified via SHA256 checksums, and stored in a local cache. You don't even need a Go development environment installed on your machine.

To update to future releases, simply run claude plugin update graph-ops@graph-ops.

Once installed, navigate to your target project folder and run /ui to launch the dashboard and experience graph-engineered development firsthand!

Repository

GitHub: https://github.com/imahiro-t/graph-ops

Feedback and issues are warmly welcome!

Summary

Lightweight Ticket Management + Graph Engineering: Empowers solo developers and agile teams to execute high-caliber AI-driven development without heavy corporate tools.
Execution Graphs (DAG + Loopbacks + Parallelism): Formalizing plan, review, approval, implementation, parallel auditing, testing, and reporting eliminates misalignment and overlooked edge cases.
Zero-Build Onboarding: Get started immediately with just two commands (/plugin marketplace add and /plugin install).
Seamless Synergy: The blend of Claude Code skills, a standalone Go binary, and a React-powered Web UI offers a fast, fluid developer experience.
Maximized ROI: While token usage increases, the reduction in manual rework and the consistency of high-quality outputs deliver immense returns.

If you've ever felt that prompting alone yields unpredictable AI code or that missed reviews cause frustrating regressions, give GraphOps a spin and experience graph-engineered development!