Back to Go Micro

How Go Micro Builds Itself

internal/website/blog/31.md

6.3.105.2 KB
Original Source

How Go Micro Builds Itself

June 25, 2026 • By the Go Micro Team

Go Micro is an agent harness. The most honest test of that claim is to use agents to build it — so increasingly, we do. A scheduled loop of two AI agents now opens issues, writes increments, and merges its own pull requests against this repo, on a cadence, with a human setting direction rather than typing the code.

This isn't a stunt. If a harness is good enough to operate a loop that builds itself, that's evidence it's good enough to operate the loop that builds your software. So we pointed the thesis at itself and wired up the loop. This post is how it actually works — including the parts that didn't, because the failure modes are the interesting part.

Two agents and a human

The work splits across three roles:

  • Codex is the serial builder. It takes one scoped task at a time, implements it, runs the build, tests, and linter, and opens a pull request.
  • Claude Code is the orchestrator: it sets up the machinery, reviews, integrates, and handles the judgment calls Codex shouldn't make alone.
  • The human sets direction and owns taste — brand and positioning copy, breaking public API changes, architectural decisions. Those never merge autonomously.

Everything else is automated.

The mechanism

Each cycle is deliberately boring, which is the point:

  1. A scheduled workflow opens a fresh tracking issue and dispatches Codex on it with a single instruction: pick the highest-value improvement that advances the North Star, implement it, verify it builds and passes tests and lint, and open a PR.
  2. Codex does the work on its own branch and opens the PR.
  3. GitHub native auto-merge lands it the moment the required CI checks go green — build, tests, golangci-lint. There is no human approval step. CI is the only gate, and that's not an approval, it's just a refusal to ship broken code.

Every increment is small, single-concern, and reversible. Nothing clever survives that can't pass the same checks a human contributor's PR would.

Three altitudes

One loop only produces increments; it doesn't know whether they're adding up to anything. So there are three passes at different altitudes:

  • An architect pass reviews the whole framework against the thesis every few days — API coherence, gaps in the services → agents → workflows lifecycle, drift — and files scoped issues. It decides what to build.
  • The hourly increment loop builds those issues.
  • A DevRel pass audits the README, website, docs, and blog each day for coherence, and surfaces things worth writing about. (This post is the kind of thing it's meant to catch.)

The architect points, the loop builds, DevRel keeps the story honest. Direction flows down; code flows up.

The parts that broke

Wiring an autonomous loop is mostly plumbing and failure modes, which is exactly why it's a good test of a harness. A few we hit:

  • The agent's "open a pull request" tool turned out to be a stub — it recorded the PR's title and body and returned them for a downstream step, but never pushed a branch or called the API. The agent cheerfully reported "opened a PR" every time, and no PR ever appeared. The fix was to stop trusting the tool and have the agent push and open the PR itself.
  • Dispatching every run from a single tracking issue made the agent derive the same branch name each time, so the first increment opened a PR and the rest silently collided. One fresh issue per run fixed it.
  • At one point an increment helpfully rewrote the repo's own agent instructions to point back at the broken tool. An autonomous loop will faithfully encode its own mistakes, so the guardrails have to be explicit.

None of these are exotic. They're the ordinary reality of operating an agent loop: tools that lie, state that collides, instructions that drift. The things the harness ships — observability, durable runs, resilience, guardrails — are the things you reach for the moment you try to run a loop like this in earnest.

What it produces

The increments are unglamorous and real. Recent ones hardened the agent run loop with OpenTelemetry run timelines and a micro runs command to inspect them, correlated those timelines with trace spans, added retry backoff to durable flows, and made flow steps cancellation-safe so a canceled run stops retrying instead of burning its budget. Each one landed as a small PR that passed CI on its own.

That's the texture of the work: not a model writing a framework in one shot, but a loop making it a little better, continuously, under a gate that keeps it honest.

The loop is the proof

We think the future of agentic software is scheduled, looping, work-performing agents — not chat. Go Micro is built by exactly that, against its own repo. The human still sets direction and owns the calls that need taste; CI is the gate; everything is reversible. Within those bounds, the harness builds itself.

If it can do that, it can build yours.


Go Micro is an open source agent harness and service framework for Go. Star us on GitHub.

<div class="post-nav"> <div><a href="/blog/30">&larr; Go Micro is an Agent Harness</a></div> <div><a href="/blog/">All Posts</a></div> </div>