Looper CLI

Looper started as a small shell script. I was tired of the repetition in my agentic workflow — building a plan, feeding it to an agent, waiting, reviewing the output, feeding it back — and wanted something that could handle more of that loop on its own. The script did the job, but it was brittle and awkward to use. It quickly became clear it was going to need more features than a shell script could gracefully support, and that bash was the wrong foundation for what I was trying to build.

I also noticed that agentic coders are genuinely good at using CLI tools — they’re structured, predictable, and easy to reason about. So I decided to adapt the script into a proper CLI. The problem was I had never built one before. My first move was to ask the agent: what should I write this in?

It came back with two options. Python, with the usual overhead of virtual environments and dependency management. Or Go, which compiles to a single binary and needs none of that. I had limited Python experience and none in Go, but I also saw it as an opportunity to learn some Go by proxy. I won’t pretend I’ve learned all that much — I’ve mostly vibe coded it — but it gave me a solid starting point. For a personal tool I wasn’t planning to distribute, the calculus was simple: I wanted it easy to install, easy to run, and easy for an agent to use. Go won.

How it works

The core pattern is a loop: implement, review, decide. The looper implement command runs this cycle up to a configured number of times, or until the reviewer passes the work. Each cycle is checkpointed so you can resume if something goes sideways.

Linear integration means the ticket is the spec. Looper reads the issue description and uses it as the basis for the plan — so the quality of your tickets directly affects the quality of the output. Writing a detailed acceptance criteria section makes a real difference.

What I learned

Building this without writing Go myself was a strange experience. I directed the agent, reviewed every PR it produced, and debugged errors I didn’t fully understand at first. I hoped I would learn the language backwards — reading before writing, understanding by necessity rather than by practice.

A few things surprised me:

The generated code was more readable than expected. I skimmed most PRs rather than reading them wholesale — I’d catch a method name that looked odd and ask about it in the conversation, or push back when something felt off. Whether I would have spotted bad patterns with a closer read, I honestly don’t know. But nothing caught fire, so that’s something.

The implement/review loop pattern is genuinely useful. Having a second agent review the work catches a surprising number of issues — not just bugs, but things like “this doesn’t actually match the acceptance criteria” or “you forgot to handle this edge case.” It’s a different kind of check than tests.

You’re still responsible for what ships. Even skimming, the judgment calls were still mine — whether to push back, whether something felt right, whether to ship it. The agent writes the code; you’re still the engineer accountable for what lands.

Looper is experimental and rough around the edges, but it works — and I use it to build my other projects.