On the one hand, sure, why not have a default install throw a bunch of bells+whistles via skills and extensions.
But I like pi precisely because it is so minimal. I want understand and work around the simplest possible agentic coding setup, find the sharp edges, maybe even improve my prompting ability. And doing all three with a locally hosted LLM.
At some point, if I don't understand the foundations, am I just punting on actually thinking about what I'm doing?
Of course, making individual choices about how to do agentic coding are precisely just making individual choices. People should do what makes them happy and productive.
Pi makes you think about what you’re doing with it on purpose. This defeats that, as the Mario quote on the page says, and therefore isn’t worth using.
People really need to try out “less is more”. The new models are quite smart, so suffocating their context with dozens of MCPs and skills isn’t necessary like it used to be. A cli tool with good built in help and good errors is amazingly easy for the model to figure out.
If Pi is too minimal for you and you don’t want to dig into it, OpenCode is pretty good out of the box. I use it for general work I haven’t setup Pi for. The only thing I add to OpenCode is some commands that are shortcuts to save me typing frequent prompts, and a subagent with a fixed model for implementing changes.
> The new models are quite smart, so suffocating their context with dozens of MCPs and skills isn’t necessary like it used to be.
Genuinely curious, how MCPs can suffocate the context? And what exactly do you mean by this?
I have probably more than a dozen of MCPs enabled in my Claude Code (slack, jira, github, many internal ones), and I have never seen model calling into them unnecessarily unless it’s explicitly needed for a task. And in the latter case, well, it cannot do much without the right tools access (MCP in this case).
Skills and plugins are a bit of grey zone, yes, but even there it heavily depends on what you put there. Just plugin loading always takes infinitesimal portion of the context in my experience
My first thought when reading about this was, why does Pi with 8 custom skills and one extension work so well for me, and apparently so poorly for others that they are compelled to go to these lengths?
Quite the opposite is true. The agent and the harness is more important than the model on normal tasks. Just for extremely deep problems Fable 5/... are needed.
I'm using oh-my-pi with gortex MCP, context7 and LSP servers. Plus tons of skills. Without that enhancements it's almost useless, missing all the file edits, git amend or fixup strategies, or github api calls.
I think the developers of Pi made a supply chain mistake by stripping down the core agent and requiring features like subagents to load plugins written by some random person.
I made my own subagent implementation in a couple of hours using Pi itself. It aligns with my needs better than any existing plugin, none of which seems to be what I was looking for.
You don't _need_ to use someone else's plugin if you don't want to, and for simple functionality, you can get pretty good resulting rolling your own.
From my limited time using pure Pi, I found quite a few of the plugins lacking and had no desire to upgrade/fix and maintain them myself. I know others feel differently though.
I like the idea of keep Pi minimal but having “official”, high quality optional plugins to make it more usable.
I'm exploring the pi based options now and I like that Oh-my-pi actually adds new value over extensions (the advisor and stream interruption hooks are pretty clever).
I just wish it had a way for me to downlimit tool access (I love midsized local models, and I'd love to enable only 30% of the power for some usecases).
I've been using oh-my-pi for a while and I'm very happy with it. If you're not going to build out your own Pi setup I'm not sure why you'd pick this over oh-my-pi.
What AGENTS.md and skills are people relying on these days?
I have little to none and am successful building full stack Go apps Claude Code, Codex, and Shelley which covers the spectrum of crazy black box to simple `bash` clanker.
It makes me think the models are continually improving in knowing what to do on their own.
I do put some major work into the classic "Developer Experience" (DX) of my code base. Standard Go tooling, idiomatic Go, well designed initial test harnesses, GitHub actions that enforce some linting.
I think that works better than any markdown instructions ever will.
I like peeping at other people's skills but it is unclear to me what/where the claimed 60+ skills are actually located. Compound Engineering conveys a few but nowhere near 60.
60+ ! oh my, while this is cool it seems that is overkill. I want to know all my skills back and forth.
But I like this kind of projects where I can peak of what extensions other people use. Is like .vimrc file back in the day. Do not clone blindly, but peak, learn and copy what is needed.
I can understand someone being overwhelmed and not wanting to configure and "build your own pi" which is really one of the beautiful points of pi, but like with vim, I do recommend that after playing with this for a while you go back to pure pi and then decide what do you really need and incrementally add it.
The power of the incremental in control approach is huge. It allows you to keep moving in whatever direction you want instead of taking yet another dependency.
> One command. Everything configured. Nothing to research.
Being talked at by someone's AI copypasta feels like being in the Truman Show.
"Why don't you let me fix you some of this new Mococo drink? All natural cocoa beans from the upper slopes of Mount Nicaragua, no artificial sweeteners!"
"What the hell are you talking about? Who're you talking to?"
34 comments
[ 1.7 ms ] story [ 64.0 ms ] threadBut I like pi precisely because it is so minimal. I want understand and work around the simplest possible agentic coding setup, find the sharp edges, maybe even improve my prompting ability. And doing all three with a locally hosted LLM.
At some point, if I don't understand the foundations, am I just punting on actually thinking about what I'm doing?
Of course, making individual choices about how to do agentic coding are precisely just making individual choices. People should do what makes them happy and productive.
People really need to try out “less is more”. The new models are quite smart, so suffocating their context with dozens of MCPs and skills isn’t necessary like it used to be. A cli tool with good built in help and good errors is amazingly easy for the model to figure out.
If Pi is too minimal for you and you don’t want to dig into it, OpenCode is pretty good out of the box. I use it for general work I haven’t setup Pi for. The only thing I add to OpenCode is some commands that are shortcuts to save me typing frequent prompts, and a subagent with a fixed model for implementing changes.
Genuinely curious, how MCPs can suffocate the context? And what exactly do you mean by this?
I have probably more than a dozen of MCPs enabled in my Claude Code (slack, jira, github, many internal ones), and I have never seen model calling into them unnecessarily unless it’s explicitly needed for a task. And in the latter case, well, it cannot do much without the right tools access (MCP in this case).
Skills and plugins are a bit of grey zone, yes, but even there it heavily depends on what you put there. Just plugin loading always takes infinitesimal portion of the context in my experience
I'm using oh-my-pi with gortex MCP, context7 and LSP servers. Plus tons of skills. Without that enhancements it's almost useless, missing all the file edits, git amend or fixup strategies, or github api calls.
You don't _need_ to use someone else's plugin if you don't want to, and for simple functionality, you can get pretty good resulting rolling your own.
From my limited time using pure Pi, I found quite a few of the plugins lacking and had no desire to upgrade/fix and maintain them myself. I know others feel differently though.
I like the idea of keep Pi minimal but having “official”, high quality optional plugins to make it more usable.
I just wish it had a way for me to downlimit tool access (I love midsized local models, and I'd love to enable only 30% of the power for some usecases).
I guess it's the same kinda friction with vanilla vim/neovim vs vim 'distributions' that provide a bunch of stuff out of the box.
I tried pi before but the gap between codex and pi is too big for me to be productive. Ideally lazypi is easy to disable or add plugins as well.
I have little to none and am successful building full stack Go apps Claude Code, Codex, and Shelley which covers the spectrum of crazy black box to simple `bash` clanker.
It makes me think the models are continually improving in knowing what to do on their own.
I do put some major work into the classic "Developer Experience" (DX) of my code base. Standard Go tooling, idiomatic Go, well designed initial test harnesses, GitHub actions that enforce some linting.
I think that works better than any markdown instructions ever will.
What, no kitchen sink?
But I like this kind of projects where I can peak of what extensions other people use. Is like .vimrc file back in the day. Do not clone blindly, but peak, learn and copy what is needed.
But it's a useful list of things and they are links.
The power of the incremental in control approach is huge. It allows you to keep moving in whatever direction you want instead of taking yet another dependency.
Hm. Most users usually need 0 or 1 of those at a time. Makes me question other choices in there.
Being talked at by someone's AI copypasta feels like being in the Truman Show.
"Why don't you let me fix you some of this new Mococo drink? All natural cocoa beans from the upper slopes of Mount Nicaragua, no artificial sweeteners!"
"What the hell are you talking about? Who're you talking to?"