[Pi Series 1] Why I started looking at pi instead of heavier coding agents

The biggest problem I feel with LLM coding agents lately is not just model quality. It is the weight of the workflow.

At first, more tools sounded better. If the agent can read files, run commands, open a browser, connect MCP servers, call subagents, and create automatic plans, it feels like work should move faster. MCP stands for Model Context Protocol, a standard way to connect external tools and services to LLM clients. A subagent is a structure where part of a larger task is delegated to another specialized agent.

But when I use these tools all day, a different problem appears. Responses get slower. Even a small edit can lead to a long chain of tool calls. As sessions grow, old context starts pushing against the current task. On some days, I feel like I finish less than half of what I used to finish in the same amount of time.

So in this series, I want to look at a tool that moves in the opposite direction. pi is a terminal coding harness built around starting small and staying light. Here, pi is the tool name, not the mathematical constant π. A harness means the layer that connects the LLM to the file system, shell commands, and editing tools so that real work can happen.

What this post covers

This post does not try to cover installation yet. First, it focuses on why I started looking at pi and what philosophy pi brings to the table.

Why some LLM coding agents feel slower
How tool calls and large context can reduce productivity
The minimal design philosophy behind pi
Who pi is likely to fit, and who may find it uncomfortable

Installation and first use come in the next post.

Why a lighter harness became necessary again

Some of the LLM coding tools I have used kept moving toward adding more features.

At first, copying code back and forth from a web chat was already impressive. Then agents inside IDEs started reading and editing files. After that, terminal-based CLI agents, MCP servers, subagents, plan modes, automatic TODO lists, and permission UIs all appeared quickly.

More features are not automatically bad. For complex work, they can be genuinely useful. The problem is that not every task is complex.

In real development, these requests are much more common:

Explain the flow of this file.
Rename this variable in a clearer way.
Look at this failed test log and find the cause.
Clean up the frontmatter and paragraph flow of this blog post.
Check the result of npm run check and find what needs to be fixed.

For this kind of work, a fast loop of reading the right file, editing only what matters, and checking the result is more useful than a large planner or multiple layers of subagents.

If every tool is spread out on your desk, you can do almost anything. But when all you need is a screwdriver, finding it inside the pile takes time. Some modern coding agents feel like that to me.

Looking at slowness from the harness perspective

The speed problem of LLM coding agents cannot be explained only by saying “the model is slow.” Real speed also depends on the model, provider, network, and project size. But the harness also matters: what information it gives the model, which tools it exposes, and which procedures it forces into the loop.

The first issue is tool selection cost. When many tools are available, the model has to decide which tool to use on every turn. Tool descriptions also take context. More tools mean more candidates for the model to read and compare.

The second issue is context bloat. MCP server descriptions, extension descriptions, long system prompts, previous conversation, automatic plans, and TODO lists can pile up until surrounding information becomes larger than the actual working file.

The third issue is over-automation of small tasks. If every small change triggers planning, confirmation, multiple tools, and a summary, one assistant turn becomes much longer. For writing edits and simple refactors, this delay directly hurts productivity.

Feature-rich agent harnesses are not bad. Environments such as OpenCode and omo provide strong automation and extensibility. I have also saved a lot of time with those tools. The issue I have felt recently is that this richness becomes a cost even when I do not need it for the task at hand.

What is pi?

pi describes itself as a minimal terminal coding harness. In plain terms, it is a small coding-agent harness for the terminal.

When you install and run it, it gives the model the core tools needed for coding work: reading files, writing files, editing parts of files, and running shell commands. The official Quick Start highlights read, write, edit, and bash. The CLI reference also lists built-in tools such as read, bash, edit, write, grep, find, and ls.

The important point is that pi is not “a tool with no features.” pi simply does not put every feature into the core. Instead, it lets you attach capabilities in several ways.

Extension path	Role
Prompt Templates	Reuse repeated prompts as commands
Skills	Define task procedures and usage conditions in `SKILL.md`
Extensions	Add tools, commands, UI, and event handling with TypeScript
Themes	Change the terminal UI style
Pi Packages	Share extensions, skills, templates, and themes via npm or git

In other words, pi is closer to a small terminal-based LLM workbench than an all-in-one coding agent.

pi's philosophy: start small and attach only what you need

pi's philosophy is clear. Things that other tools include by default are intentionally left out of the core.

Not included by default	pi's view
MCP	Attach Model Context Protocol support through an extension if needed
Sub-agents	Run multiple pi instances in tmux or build/install an extension/package
Permission popups	Use a container or an environment-specific confirmation flow
Plan mode	Write plans to files or build/install an extension
Built-in TODO	Use a normal file such as `TODO.md` instead
Background bash	Use tmux so the process stays observable and interactive

At first, this may feel like “why is so much missing?” But this design is not just a lack of features. It is a choice about cost.

MCP, subagents, plan modes, and automatic TODOs are powerful. But if they are in the core, even users who do not need them pay part of the cost through extra instructions, tool descriptions, or workflow steps. pi avoids making that cost the default.

Who pi fits

pi will not be the most comfortable tool for everyone. But it is likely to fit well if you:

prefer terminal-centered development,
are comfortable with shell commands and Git, and can use tools such as tmux or git worktree when needed,
feel burdened when an agent automatically starts doing too many things,
care about fast responses and small context,
prefer composing your own workflow over accepting a large default set,
want to manage project rules in text files such as AGENTS.md.

On the other hand, pi may feel uncomfortable at first if you want a GUI-first all-in-one coding agent, or if you expect MCP, subagents, and plan mode to be enabled by default.

Summary

Item	Summary
Tool type	Terminal-based minimal coding harness
Core direction	Small core, attach only what you need
Basic work loop	Read files, edit, run shell commands, check results
Extension model	Prompt templates, skills, extensions, themes, pi packages
Intentionally excluded	Built-in MCP, subagents, plan mode, built-in TODOs, and more
Best fit	Terminal-centered development and text-based project rules

In the next post, we will install pi and start the first session.