This has been frustrating me for a while and is part of why I explore other coding agents.
As many advantages as pi has in some areas, there are definitely areas where I believe the hype to be a bit overstated. While the config folder is, ultimately, not relevant for performance, how this was and is continued to handled is a bit frustrating for me.
They have made it abundantly clear it's not going to change however so I'm looking at how other coding agents perform currently.
In practice this requires duplicating the upstream build and release pipelines, so now you need yet another agent running in the background (+ periodically going off the rails + eating tokens) which incurs more up front cost and cognitive overhead.
In my experience "throw another agent at it/fork it" consistently creates unsupervised trainwrecks.
Sure but I'm really not that invested in one single harness. I tried out pi because people were recommending it so much. It turns out I personally have some things which annoy me, so I try out others now as well.
If I don't find anything which fits me I might fork it, but even that little effort is not really worth it if theres something which fits me better.
I already found maki which...seems to do the exact same job pi did for me, and I wanna check out crush as well.
Who cares, geez. Is a single github issue so important that this needs to land on the front page? You can move it and configure your own env to have it wherever you want.
This has been frustrating me for a while and is part of why I explore other coding agents.
As many advantages as pi has in some areas, there are definitely areas where I believe the hype to be a bit overstated. While the config folder is, ultimately, not relevant for performance, how this was and is continued to handled is a bit frustrating for me.
They have made it abundantly clear it's not going to change however so I'm looking at how other coding agents perform currently.
LLMs make it gloriously simple to fork and patch and existing repo. If you run into a merge conflict down the line, its a snap to fix too.
Just make the changes you want to your favorite harness and move on.
In practice this requires duplicating the upstream build and release pipelines, so now you need yet another agent running in the background (+ periodically going off the rails + eating tokens) which incurs more up front cost and cognitive overhead.
In my experience "throw another agent at it/fork it" consistently creates unsupervised trainwrecks.
Sure but I'm really not that invested in one single harness. I tried out pi because people were recommending it so much. It turns out I personally have some things which annoy me, so I try out others now as well.
If I don't find anything which fits me I might fork it, but even that little effort is not really worth it if theres something which fits me better.
I already found maki which...seems to do the exact same job pi did for me, and I wanna check out crush as well.
404 on the page, main page: "Cannot retrieve latest commit at this time." [1]. GitHub are you okay?
Edit: Known issue: https://news.ycombinator.com/item?id=49330597
[1] https://github.com/earendil-works/pi/
Who cares, geez. Is a single github issue so important that this needs to land on the front page? You can move it and configure your own env to have it wherever you want.
I use pi and couldn’t care less.
I keep getting the Unicorn or 404.
I think this is a GitHub issue (of course it is) as I'm not able to search for anything atm.