Building a Pi‑style AI Coding Agent in Go: An Autonomous Development Journey

pigo: Go implementation of the Pi coding agent

pigo is an AI coding agent written in Go that reproduces the functionality of the original Pi coding agent.

Installation:

curl -fsSL https://raw.githubusercontent.com/smallnest/pigo/master/install.sh | sh

Configuration can be done via a config file or command‑line flags.

Background of Pi coding agent

Pi was created by libGDX author Mario Zechner and is now maintained by the Earendil team. It is a minimalist terminal‑based coding agent that exposes a small set of primitives: LLM suggestion, context memory, and tool actions.

Why Pi is studied

Its small codebase and clear structure make the core loop of a coding agent easy to understand.

Differences between pigo and Pi

pigo rewrites each module in Go, gaining Go’s static type system, built‑in concurrency, and explicit package boundaries. The result is a single binary with no runtime dependencies, usable as a daily coding agent or as an SDK.

Main features

Headless mode ( -p): outputs only the final result, suitable for scripts and CI.

REPL mode : interactive stateful command line.

TUI : built with bubbletea and lipgloss, handling multiline input, image paste, line‑wrapping, viewport scrolling, theming, status prompts, Markdown rendering, and verb‑waiting.

Extension mechanism

New capabilities can be added without modifying the core source, organized into four layers:

Skills : slash commands defined in a markdown file (e.g., /command).

Prompt templates : invoked with /template-name.

Plugin : separate processes communicating via JSON‑RPC, language‑agnostic, installable from npm with pigo install.

Hook : custom logic injected at key points such as directory‑trust checks or goal reminders.

Development workflow

The project was built in one week by a single developer, with AI driving the implementation. All steps were recorded in a tasks directory.

Requirement documents generated with the /prd skill and spec documents with /prd-to-spec.

Each document was split into GitHub issues via /to-issues.

Implementation proceeded through the goal‑workflow loop: /goal → /review-it → /note-it → /ship-it Serial execution used /loop-it; parallel wave‑based execution used /graph, which leverages git worktree to handle multiple issues concurrently. When potential code conflicts were detected, /graph suggested switching to /loop-it.

Key feature implementations

Harness engineering

A harness‑engineering requirement was created with /prd, split into issues with /to-issues, and realized via /graph.

/btw command

The /btw slash command provides side‑questions that do not affect the main workflow. It was generated by a single /prd invocation and then implemented through the same issue‑graph pipeline.

TUI requirement generation

TUI features were specified with /prd "bubbletea + lipgloss", producing markdown requirement files that were turned into tasks, issues, and finally implemented via /graph.

Future directions

Planned extensions include adopting features from agents such as oh‑my‑pi, Claude Code, Codex, OpenCode, Kimi Code, Mimo Code, and Qoder, adding remote‑control capabilities, desktop‑application support, and tighter runtime integration.