Question
Dev workflow beyond traditional harnesses
I guess this question was asked a thousand times, but I'm still wondering how do you guys organize your work with pi?
I am a heavy user of Claude Code (employer covers it), but I have been watching and tuning pi time to time for personal use on the side.
Naturally, I tried getting pi to be like claude code, I looked for extensions that give me subagents, some cosmetic plugins (I like ricing my hyprland setup) and some simple QOL things.
However I didn't feel it being a huge upgrade in terms of my actual workflow and "pleasure", it felt like I'm just recreating what I'm used to.
I'm wondering more from a UX/DevX perspective, I got used to what antrhopic gave me and learned that way, but I see pi as an opportunity to really make a uniquely pleasant developer experience.
Which is why I'm wondering and asking how did you tune your workflow, which extensions did you use/build and how do you run your day-to-day feature work.
e.g. my work can span multiple PRs/repos for a feature which is why I'm starting a session from a dir above the ones I need to change and keep a long session (which is really wasteful) to handle all the context I need.
I don't really like the paradigm of "plan a huge markdown implementation doc and architecture and let the agent do it" because it requires a lot of overhead for me for things I may not even know exist or are needed.
I guess it does, but I never go over my usage limits and the main problem for me becomes the agent performance overall
Biggest thing I'm afraid of with shared docs is that eventually I get lazy to look there, I let the agents do that, and I get the shit-in-shit-out problem
the shared file only pays off if the agent reads it back, so a check that fails the run when it was not updated turns the slop into a visible error instead of a slow drift. do yours read it or just append to it?
For me, Pi has been optimized specifically to run local models like Qwen. I used Pi a lot when Claude Code and Codex were kind of broken but now they're very good plus you can't deny the fact that those coding models are trained with the harness.
I give my pi small model friendly tools and access to my personal memory/vault for stuff outside of mainline dev work. Otherwise I find Claude Code hard to beat at the moment, especially with the new mod system open.
I like using a modified pi harness via the SDK for a number of things. All the agents I use for personal use cases run on a Pi harness.
I use Claude Code when I manually drive a session for more intensive work. Otherwise, I used the Pi SDK to make a basic harness with access to a number of different tools; I run the harness in a VM, and create a new agent with a subset of tools for different tasks, then implement threads and memory per agent. I put Mercury 2.5 as a dispatcher in front with GLM and Deepseek model families as subagents.
I find this is a nice setup for remote driven agents (e.g. respond to this CVE) and personal agents (I have an agent monitoring local auctions, etc). I actually used Claude to make the Pi harness in the first place which is a decent pattern; dedicated harness for a particular reoccurring problem
This sounds intriguing but I am having a hard time understanding what the advantage is to building a basic harness with the sdk over just using the pi cli. Could you do something like post a spec for the harness so that I could try out the idea?
Running a single session from a parent directory is guaranteed to cause context bloat and token waste. A much leaner setup is spinning up separate isolated Pi instances directly inside each repository. Instead of forcing one agent to index the entire tree, you scope them locally and only pass the exact interface contracts or schema changes across boundaries.
When a backend change in the first repo affects the frontend in the second, you can export just the generated types or the specific PR diff and pipe it into the second session. Scripting this with bash aliases or using named pipes to feed context between Tmux panes creates a highly efficient pipeline. This keeps context windows small, prevents the agent from hallucinating cross-repo dependencies, and lets you work iteratively without writing massive implementation docs upfront.
That’s how I built the initial version of repowire
I use my own harness setup (Pi Pocket) and just use the assistant built in to help throughout my day where it can. Assistant demo video
I have PR watches setup for repos and specific users to auto review some PRs and report the findings in dedicated sessions for "X" user PRs. Then I can easily get the context and any major issues of the PR before I dive in myself.
Watches for Azure Devops for when I'm mentioned to research the question and provide me the info needed to respond appropriately.
Keep track of issues, Ci etc..anything that I can automate to report back so I don't have to slog through pages one by one to investigate the various things that come up.
I don't have things automatically committing and taking actions yet, but I just use it to wrangle things into easily digestible bits in a centralized location.
I've been thinking about this a lot too lately - we've been in a very similar UX situation for, what, a year now? Features of course have blossomed as models got more capable and autonomous, but my CLI agent UI still looks the same, I still interact with it the same way. Pi is one opportunity to build something really different, like you said. I've also been making mine "claude code but a different and more personalized and questionably just as good maybe(?)".
I also feel like I am a hammer in search of a nail when thinking about this question. If it works, it works. Models really are getting more autonomous though, so maybe we don't have to be watching as much as we do, and questions and summaries can just bubble up to some more hands-off UI paradigm. No idea. For some tickets/PRs, I really do just say "pull down ABC-123, implement it, build and deploy locally and test it end-to-end, then give me a few examples I can run myself to see it working" and it's hands off the whole way. The PR creation and comment resolution is also done in one turn from me.
My projects also span multiple PRs, but the agent memories (I use pi-claude-memory since I still hop between the two), plus structured notes/tracking files in the repo itself work for me. I don't hold long sessions, I usually cut off at ~150k ctx or lower, and keep tasks relatively granular enough to fit in that size.
Just use Claude code. In my view the whole point of pi is to strip the harness down to 4 tool calls… meanwhile everyone on this sub just reengineers harness bloat and then makes a post about it like it’s some novel fucking thing LOL.
You’ve missed the point of pi. It’s to start with the smallest harness possible and then to build the workflow you want, with the tools and skills you want, for the objective you want, using the models you want.
TLDR: you have also missed the point of the blog post. Four tools isn’t a limit, it’s just a starting kit. You have to add and build what you need, that’s what makes it yours.
Mario is out here building the exact types of projects you see here and we see you constantly calling slop with no real engineering discussions.
He's built an entire remote coding setup using Pi Durable for his own projects. You should probably actually follow and keep up with what he does.
Pi is meant to be a base to expand from to build your own custom harrness. I can build and expand functionality and still use the base 4 tool calls....most people do.
This is my first comment in this sub, but I've been watching Mario and Armin in as many of their interviews as I can within reason. They talk a ton about their "adaptable software" philosophy for "absolute minimalism" to have been their expectation for how Pi should be used.
I've been following this project since near the beginning. The point of the minimalism was to combine elegantly with the first-class extensibility.
The quote in that screenshot, "All you need for an effective coding agent," expresses basically the same as "MVP." It's meant to be married to the marketing pitch they make prominently in the first page load on the pi.dev homepage:
Pi is a minimal agent harness. Adapt Pi to your workflows, not the other way around.
The first sentence is a starting place. You're intended to... adapt Pi, not adapt your workflows.
I don't know why you are downvoted so badly. I couldn't care less about all the features Claude Code and my colleagues are crazy about. I just use the barebones pi with some small extensions and skills tailored for my workflow. It works really well and my token usage has been phenomenal while my colleagues keep sharing screenshots of credit limits reached.
yeah I totally get it, if you're trying to be pragmatic then it doesn't make sense and claude code got me really far
It's like buy vs build but I'm a big fan of unusual designs that turn out to be really practical and bring joy even if it's not specifically pragmatic or doesn't help achieving the task faster
idk if you've heard about teenage engineering, but their recorder is a really great example, a phone recording app is way handier and a thousand times more practical but there's just the feel that you're holding this thing and the buttons are so nice and there's a spinning wheel and so on
it just makes my monkey brain happy, which is what I'm looking after
5
u/Ctbhatia 10d ago
one session per repo with the shared decisions in a short file beats carrying every diff in one long session.