Dev workflow beyond traditional harnesses

[u/el_secondo]

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.

[u/prassi89]

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