Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • One thing I'm wondering: have you tried this on a team with multiple humans as well, or is it mainly optimized for a single developer coordinating a bunch of Claude Code agents?
    by vasanthrb
  • set up a channel for agents to communicate and you shouldn't have issues with messy merges.

    your force quitting is probably more from your build pipeline than anything agents are doing.

    i use an m2 8gb air with no performance issues at up to 10 parallel claude code interactive sessions (ghostty), each with deep/transient subagent heirarchies that mix claude and codex.

    very rarely need to force quit. only seen a couple restart-level failures, and those were on me for being cowboy with subagent delegation logic, resulting in 100s of claude moles popping up faster than i could whack them with force close.

    by otekengineering
  • SelfCI: https://radicle.network/nodes/radicle.dpc.pw/rad:z2tDzYbAXxT... , supports git & jj
    by dpc_01234
  • I have CI set up so that I can just let that handle builds and exclusive locks for me, but there are particular limitations (network connectivity is mandatory). I did this because I wanted to avoid something like you built, which theoretically can't scale as well as a dev box (much easier to extend deploy environments versus my local machine). I can see that you are working within resource constraints though which is admirable :)
    by orsorna
  • idea looks nice, but can you share what's your workflow to push 90 commits/day?

    I understand each commit might have different size, but I am guessing your commits == Pull Request (because you need this constant merge queue to rebase, merge, test) and each are around 40-80 lines of code (additions and removals), and you are probably not reviewing the code because at this rate even if one commit takes 2 minutes to review we are talking about 3 hours of non stop code review.

    if you are not reviewing each code, probably your commits are small items and 10-20 of them are a part of single PR, then how do you sustain working across multiple projects?

    by throwaw12
  • Definitely going to look into this!

    I just built something pretty much in the same vein of this with Claude over the past 2 months. It's a custom deployment system that uses work trees and each work tree has to to run end-to-end tests (Playright, Supabase, Astro) and other tests and create a stamp based on the contents of the entire tree. And then if another work tree has the same digest that matches the stamp then it can bypass the tests. So nothing can land on main without tests passing. Which is all in in enforced with a pre-push hook that checks the digest.

    Then once it's on main it is deployed to Dev and then from there it can be promoted to prod.

    I like the idea of just having one branch and the work trees funnel into it.

    But definitely going to have my setup analyze this and see what can be improved with it or if I should just throw out mine and use that one.

    by ElijahLynn
  • A decent idea, however it seems to me a good chunk of it is because of git limitations. Have you looked jj?

    I'm having a much better time with jj and a workspace per subagent than I was with git and worktrees.

    It's still useful to have the CI gating on updating the master branch pointer, but you largely stop working with branches once you switch to jj.

    by barrkel

Explore Birbla archives