Pi Is Vim

Most coding agents today are built like IDEs. They ship with a long system prompt, dozens of tools, planning modes, memory, sub-agents, and opinions about how you should work. You install one and adapt to it.

Pi goes the other way. It has four tools (read, write, edit and bash), a short system prompt and a small loop. Its author’s rule is “if I don’t need it, it won’t be built.” Anything else, you add yourself as an extension.

The first time I used it, it felt familiar, and it took me a minute to see why. It’s the bet Vim made.

Vim gives you very little out of the box, and Neovim kept it that way. You get verbs and motions that combine, and a config written in Lua. Over the years your init.lua turns into yours. Most lines in it are there because something annoyed you once. No two engineers’ configs look alike, and each fits its owner like an old shoe.

IDEs bet the other way. They try to guess what everyone needs and build it in, out of sight. For most people, most of the time, that’s the right call. The cost is that the tool’s opinions sit between you and the work, and you can’t see most of them.

Agent harnesses are splitting the same way, and more is at stake. In an editor, hidden machinery costs you a few keystrokes. In an agent, it costs you control over what the model sees. A big harness adds instructions, context and tools you never picked. So when the agent does something strange, you can’t tell if it was the model, the prompt or a feature three layers down.

With a small harness you can tell. You wrote most of what the model sees, so when something breaks you can find it, and when something works you know why and can keep it.

That’s the real case for the Vim approach, and it isn’t about minimalism. Owning the tool is how you learn. Each extension you add teaches you something about how agents behave, like what context they need or where they drift. Over time the harness becomes a record of your judgment, the way an init.lua does.

Judgment is the scarce thing now. Agents will climb whatever hill you point them at, and the harness is how you point. Leave that layer to someone else’s defaults and you’ve given away the part that matters most.

This doesn’t mean everyone should build their own tools. Most people should use the IDE and the big harness. But the engineers I learn the most from tend to have an init.lua they’ve been tending for years, and I suspect they’ll soon have a harness too.

A few favorites from mine right now, not the full list:

• pi-subagents by tintinweb: runs sub-agents in their own sessions, each with its own tools, prompt and model, in the background or in parallel.
• pi-tasks, also by tintinweb: a task list the agent keeps as it works, with dependencies between tasks. It can hand tasks to pi-subagents.
• pi-posthorse: my experimental pick for long-running tasks, instead of the default compaction. When the context fills up, it starts a fresh window instead of writing a summary, and keeps notes and searchable history of what came before.

If you’re early in your career, build one. Start with the four tools and add only what you need. A month of that will teach you more about agents than a year in someone else’s harness.