π“Ÿ host1.bitchan.one

𓀐 @37t6hUVq

⏱ 4d seenβ›“ 0πŸ‘ 0β§– 1

filter [-]

languages:onother

and resolved shared things that were out of scope for the implementation workers. Initially the implementation workers would just create PRs, I would then manually review and add review comments on GitHub, then comment `/fix address review comments` or `/fix resolve merge conflicts`, this would get picked up by the orchestrator and send it back to the queue. Eventually I had done enough manual reviews to fold my new merge rubric into the implementation workers, then the implementation workers would follow things through to merge, while still leaving shared things to be resolved by the coordinator session. Overall this worked very well, after folding in the merge rubric I manually checked some of the merged PRs and found none of the issues that were enforced, in a very small amount I found issues like only eager attention instead of using flash attention because the original/source only had eagar, so I added that as a hard gate too. It's always an evolving process, you don't know what you need to enforce until you notice the issues. However, if your project isn't at the >1m LOC scale (mine is >2m), or you don't have parallel similar work, or whatever, then you don't need anything like this. If you're starting a fresh project from an idea then all you need is to prompt, no subagents that will only waste your tokens and time, literally just tell it to do the thing you want. My project started the same way, I just prompted what I wanted, then it evolved to using loops, until that wasn't enough and it evolved again, and so on until the point I'm at now.⏱ 4d↩ 1
Very interesting. What about the futanari hypothesis?⏱ 4d↩