Video Summary - How I Turned Pi Into the Ultimate Coding Agent

Overview

This video is a follow-up to an earlier “first impressions” review of Pi (a coding agent). The speaker says Pi has become their primary day-to-day coding agent, replacing Codex for most work. They mainly use GPT 5.5 with low reasoning alongside the Pi agent.

What Pi is like “out of the box”

The speaker describes Pi’s initial setup as very minimal:

Four core tools by default
A simple system prompt
A clean, functional TUI (terminal UI)

They argue this minimal setup is still enough for strong results because models handle Bash file + filesystem workflows well—e.g., running Bash commands and reading/writing/exploring files.

Why Pi is “different”: the extension system

A major focus is Pi’s extension system, which the speaker claims is deeper than “typical extensions” in other tools.

Pi customization is presented as analogous to Neovim-style extensibility
Setup pain is reduced because the agent helps perform configuration
Pi extensions are designed so the agent can reference bundled docs and implement/modify functionality

How Pi extensions work (tutorial-like details)

Extension creation via agent guidance

The speaker installs Pi globally with npm and notes that Pi ships handwritten Markdown docs (e.g., extensions.md) inside node_modules.

Those docs are exposed to the agent via the default system prompt, so Pi can “know” how to build extensions.

Hot reload / no restart

Instead of restarting the agent when extensions change, Pi is described as fully hot reloadable.

Example workflow:

Create a basic “hello world” extension (writes hello_world.ts)
Run /hello world to test it in the TUI
Run /reload to load extension changes without restarting

Pi as an SDK / platform

The speaker emphasizes Pi’s minimal but powerful core, including:

Strong TUI robustness
A robust extension system
Core tools that are sufficient for most models

They also mention:

Pi has an SDK, and Pi itself is built on top of/with it
MCP support is not included by default, but can be added by instructing Pi to enable it

Their day-to-day workflow (tooling + “coding agent management”)

Terminal + tmux (via Cmux)

They use the terminal with tmux via Cmux, which enables multitasking across multiple projects using “side sections.”

This works well with running multiple Pi instances in splits/tabs.

Editor for manual edits

They still use Zed (or another editor) to manually edit code when needed.

Multiple agent threads/instances

They run parallel Pi instances/threads, such as:

one for backend
one for frontend

Pi slash commands for session/context control

They highlight Pi’s slash commands for managing sessions and context:

/copy and /copy all: move prior thread messages into new sessions as context
/new: start a new session with cleared context
/resume: return to an existing session
/tree: visualize the agent’s tool calls and message history to help with manual navigation and context control

Their framing

They position Pi as best for deep thinking about code (rather than “vibe coding”), while still enabling agent-driven execution.

Open-sourced configuration + stance on reuse

The speaker says their Pi configuration is fully open-sourced.

However, they don’t recommend copying it directly as a primary approach. Instead, they suggest:

browsing/inspecting extensions
using Pi to generate your own tailored extensions

The core advantage, they argue, is hyper-customization to match your workflow.

Extensions they built/uses (feature list)

/copy all
- Copies the entire thread (user + assistant messages) to the clipboard for reuse as context in another session.
/diff
- Shows which files changed in the last turn and opens the file in Zed for review.
Firecrawl web tools
- Added to restore “web search” capability (since they miss Codex’s internet/search advantages).
- Includes:
  - Search (Firecrawl)
  - Scrape: converts a URL into LLM-readable Markdown so Pi doesn’t rely on ad-hoc curl workflows
flow title
- Customizes the display title inside Pi.
OC
- Provides instructions for connecting to and working with the speaker’s Open Code instance (managed via their agents).
- Includes SSH connectivity to a Mac Mini using Tailscale.
Open Code login/auth workaround
- Mentions a specific login method (OAuth/API key setup), though they suspect it may not be strictly required.
TPS tracker
- Displays approximate token generation speed; example: ~140 tokens/sec for GPT 5.5 low reasoning.
TX9
- A “background agent / job runner” system:
  - snapshots the current project
  - sends it and a prompt to their Mac Mini
  - triggers a coding agent remotely
  - can later resume/follow up by rerunning TX9
/usage
- Calculates usage totals across agents (Pi, Codex).
- They prefer it not to be injected into context unless explicitly triggered.
/yeet
- Inspired by a Claude Code “yeet script” idea:
  - auto stages + commits with a message
  - asks whether to push
  - optionally creates a PR (push/PR workflow)
ZSH over Bash
- Ensures Pi shell commands run under ZSH for proper shell completions and PATH behavior (their environment uses ZSH).

Skills vs extensions (important design choice)

The speaker mentions Pi skills but prefers extensions for certain things because skills are semi-injected into context.

Example: they keep some tasks content-triggered only when explicitly called (e.g., BTCA local, yeet, TX9-related flows).

Skills shared vs project-specific

Skills can be shared across agents
Some are project-specific
They mention:
- a front-end design skill (teased as another video)
- BTCA local: instructions for exploring a repo (which they could turn into an extension later)

Comparison / community example

They show (and summarize) Dylan Monroe’s Pi setup, emphasizing that:

different people’s setups look totally different
Pi’s customization philosophy supports that diversity

Features mentioned from Dylan’s setup:

an update extension adding /update and auto-detecting the install method to update Pi and extensions
custom web tools using Exa instead of Firecrawl
MCP support via pieMCP (since MCP isn’t included by default)
Pi ephemeral UI (/ephemeral-style behavior):
- selectively load project local skills/prompts/extensions/MCP servers only when needed
- contrasted with the speaker’s approach where global skills are always loaded
a “mark sensitive text” tool to reduce accidental API key leaks
a whimsical customization example

Practical recommendation / “how to grow your setup”

The speaker recommends growing your setup gradually:

Don’t build everything up front
Start with minimal essentials
When a task repeats 3–4 times, convert it into a reusable extension
Pi hot reload makes iteration easier

They also highlight their convenience update extension:

automatically runs Pi updates via the agent (/update)
avoids manual npm i -g / upgrade steps

Sponsor / CI product (non-Pi but tech-relevant)

The video includes an ad for Depot:

claims it’s a CI engine outside GitHub Actions
positions it as faster and more reliable
uses an API-driven approach compatible with GitHub Actions syntax
provides a CLI migration command: depot ci migrate
performance claim example: Posthog builds drop from ~72 minutes to ~4 minutes
mentions a pull-through cache for Docker/container images via CDN to reduce fragile/frequent registry pulls and complex OAuth setup

Main speakers / sources

Primary speaker: the video author (first-person “I” perspective; no name given in subtitles)
Referenced third-party sources:
- Mario (creator of a Pi-related project; mentioned as someone to follow on Twitter)
- Dylan Monroe (another person’s open-source Pi setup)
- Theo (origin of the “yeet” concept/script inspiration)
- Depot (sponsor)

How I Turned Pi Into the Ultimate Coding Agent

Key takeaways