| ▲ | coldbrewed a day ago | |
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. | ||
| ▲ | taosx a day ago | parent [-] | |
Fully agree with this. I did that for pi for a while, maintained it and brought merges from upstream while having my own patches on top but then went on holidays and there was that refactor where the agent pipeline failed... now I'm stuck on the version from april/may (works great but I can't use extensions; and I'm too lazy to debug/fix while everything works great). off: I'm working on my spare time on a code mode lisp alternative (great opportunity to learn lisp) and might switch to it fully as long as I built some simple evals (I'm concerned about token usage, which is why i forked pi the first time) | ||