[HN Gopher] LLM codegen go brrr - Parallelization with Git workt...
___________________________________________________________________
LLM codegen go brrr - Parallelization with Git worktrees and tmux
Author : skeptrune
Score : 74 points
Date : 2025-05-28 15:13 UTC (7 hours ago)
(HTM) web link (www.skeptrune.com)
(TXT) w3m dump (www.skeptrune.com)
| juancn wrote:
| Now you can do 4X more code reviews!
| arguflow wrote:
| Why review the code? Most of the time you just want is a good
| starting point.
| oparin10 wrote:
| If all you need is a good starting point, why not just use a
| framework or library?
|
| Popular libraries/frameworks that have been around for years
| and have hundreds of real engineers contributing, documenting
| issues, and fixing bugs are pretty much guaranteed to have
| code that is orders of magnitude better than something that
| can contain subtle bugs and that they will have to maintain
| themselves if something breaks.
|
| In this very same post, the user mentions building a
| component library called Astrobits. Following the link they
| posted for the library's website, we find that the goal is to
| have a "neo-brutalist" pixelated 8-bit look using Astro as
| the main frontend framework.
|
| This goal would be easily accomplished by just using a
| library like ShadCN, which also supports Astro[1], and has
| you install components by vendoring their fully
| accessibility-optimized components into your own codebase.
| They could then change the styles to match the desired look.
|
| Even better, they could simply use the existing 8-bit styled
| ShadCN components[2] that already follow their UI design
| goal.
|
| [1] - https://ui.shadcn.com/docs/installation/astro [2] -
| https://www.8bitcn.com/
| arguflow wrote:
| Frameworks and libraries are useful to keep the code style
| the same.
|
| Using multiple agents helps when the endgoal isn't seen.
| Especially if there is no end state UI design in mind. I've
| been using a similar method for shopify polaris[1] putting
| the building blocks together (and combing through docs to
| find the correct blocks) is still a massive chore.
|
| [1] - https://polaris-react.shopify.com/getting-started
| skeptrune wrote:
| I think AI makes personal software possible in a way that
| it wasn't before. Without LLMs, I would have never had the
| time to build a component library at all and would have
| probably used 8bitcn (looks awesome btw) and added the neo-
| brutalist shadows I wanted.
|
| However, despite my gripes with ShadCN for Astro being
| minor (lots of deps + required client:load template
| directive), just small friction points are enough that I'm
| willing to quickly build my own project. AI makes it barely
| any work, especially when I lower the variance using
| parallelization.
| eikenberry wrote:
| > If all you need is a good starting point, why not just
| use a framework or library?
|
| A good starting point fixes the blank page problem.
| Frameworks or libraries don't address this problem.
| vidyootsenthil wrote:
| or also 4x productivity!
| juancn wrote:
| Coding has never been for me the bottleneck, it's all the
| other crap that takes time.
| morkalork wrote:
| What's the issue, everyone loves doing code review right?
| thepablohansen wrote:
| This resonates- my engineering workflow has started shifting from
| highly focused, long periods of building out a feature to one
| that has much more context switching, review, and testing.
| asadm wrote:
| ooh i was exploring this path, aider is so slow. thanks for
| validating it.
| arguflow wrote:
| Is aider supposed to do worktrees by default?
| asadm wrote:
| i dont think so?
| asadm wrote:
| i dont see uzi code on github.
| skeptrune wrote:
| Hadn't pushed from our remotes. There now![1]
|
| - [1] https://github.com/devflowinc/uzi
| uludag wrote:
| I completely see the benefit for this strategy. Defaulting to
| something like this would seem to inflate costs though, as a
| tradeoff for time. I know certain LLM usages can be pretty pricy.
| I hope that something like this doesn't become the default though
| as I can see parallelization being a dark pattern for those
| making money off of token usage.
| ramoz wrote:
| I don't think it's a great representation on of the utility of
| worktrees or even efficient practical use of agents.
| vFunct wrote:
| It pretty much is though. This is exactly what you'd do if
| you had 100 different employees.
| ramoz wrote:
| I wouldn't ask for 100 different versions of the same
| feature from each of them.
|
| 1 agent is supposed to be powerful with proper context and
| engineering design decisions in mind - whether UI or
| backend.
|
| Asking 3 different agents to do the same engineering task
| reeks of inefficient or ineffective development patterns
| with agents.
| TeMPOraL wrote:
| > _I wouldn 't ask for 100 different versions of the same
| feature from each of them._
|
| You wouldn't because human labor is too expensive to make
| it worthwhile. You would if it were too cheap to meter.
|
| We actually do that at the scale of society - that's
| market competition in a nutshell. Lots of people building
| variants of the same things, then battling it out on the
| market. Yes, it's wasteful as hell (something too rarely
| talked about), but we don't have a better practical
| alternative at this point, so there's some merit to the
| general idea.
|
| (Also the same principle applies to _all life_ - both in
| terms of how it evolves, and how parts of living
| organisms work internally. Actively maintained equilibria
| abound.)
| vFunct wrote:
| I actually don't use them that way. I use 100 different
| agents on 100 different worktrees to develop 100
| different apps for the overall project.
| tough wrote:
| what if you have 100 lint errors that you can parallelize
| fixing to 100 small local 1B llms
| greymalik wrote:
| This is discussed in TFA. The absolute costs are negligible,
| particularly in comparison to the time saved.
| arguflow wrote:
| I think the most annoying part is when a coding agent takes a
| particularly long time to produce something. AND has bad
| output, it is such a time sink / sunk cost
| vercantez wrote:
| Very cool! Actually practical use of scaling parallel test time
| compute. I've been using worktrees + agents to work on separate
| features but never considered allocating N agents per task.
| maximilianroos wrote:
| I posted some notes from a full setup I've built for myself with
| worktrees: https://github.com/anthropics/claude-code/issues/1052
|
| I haven't productized it though; uzi looks great!
| senko wrote:
| TIL worktrees exist! https://git-scm.com/docs/git-worktree
|
| Thanks :)
| dangoodmanUT wrote:
| thank you for not writing this in python
| crawshaw wrote:
| This is a good strategy we (sketch.dev) experimented with a bit,
| but in the end we went with containers because it gives the LLM
| more freedom to, e.g. `apt-get install jq` and other tools.
| sureglymop wrote:
| I love how the one non-broken toggle still wasn't great. Now you
| can save time while wasting your time ;)
| skeptrune wrote:
| It _was_ better than starting from scratch though. Imo, getting
| a functional wireframe for $0.40 is a good deal.
| hombre_fatal wrote:
| I find that my bottleneck with LLMs on a real project is
| reviewing their code, QAing it, and, if it's novel code,
| integrating it into my own mental model of how the code works so
| that I can deliberately extend it in a maintainable way.
|
| The latter is so expensive that I still write most code myself,
| or I'll integrate LLM code into the codebase myself.
|
| I've used parallel Claude Code agents to do chore work for me.
|
| But I'd be curious about examples of tasks that people find best
| for OP's level of parallelization.
| CraigJPerry wrote:
| I'm in a different direction on this, worktrees don't solve the
| problem for me, this is stuck in 1 agent = 1 task mode. I want a
| swarm of agents on 1 task.
|
| There's a couple of agent personas i go back to over and over
| (researcher, designer, critic, implementer, summariser), for most
| tasks i reuse 90%+ of the same prompt, but implementer has
| variants, one that's primed with an llms.txt (see answerdotai)
| for a given library i want to use, another that's configured to
| use gemini (i prefer its tailwind capabilities) rather than
| claude etc.
|
| To organise these reusable agents i'm currently test driving
| langroid, each agent contributes via a sub task.
|
| It's not perfect yet though.
| skeptrune wrote:
| I think you misread. The point I make is that it's _many agents
| = 1 task_.
|
| Since the probability of a LLM succeeding at any given task is
| sub 100%, you should run multiple of the same LLM with the same
| prompted task in parallel.
| danielbln wrote:
| What I don't like about this approach is that it mainly improves
| the chances of zero-shotting a feature, but I require a ping pong
| with the LLM to iterate on the code/approach. Not sure how to
| parallelize that, I'm not gonna keep the mental model of 4+
| iterations of code in my head and iterate on all of them.
|
| For visual UI iteration this seems amazing given the right
| tooling, as the author states.
|
| I could see it maybe useful for TDD. Let four agents run on a
| test file and implement until it passes. Restrict to 50
| iterations per agent, first one that passes the test terminates
| other in-progress sessions. Rinse and repeat.
| Flemlo wrote:
| I write docs often and what works wonders with LLM is good
| docs. A readme a architectural doc etc.
|
| Helps me to plan it well and the LLM to work a lot better
| diggan wrote:
| > but I require a ping pong with the LLM to iterate on the
| code/approach
|
| I've never got results from any LLM when doing more than one-
| shots. I basically have a copy-pastable prompt, and if the
| first answer is wrong, I update the prompt and begin from
| scratch. Usually I add in some "macro" magic too to
| automatically run shell commands and what not.
|
| It seems like they lose "touch" with what's important so
| quickly, and manages to steer themselves further away if
| anything incorrect ends up at any place in the context. Which,
| thinking about how they work, sort of makes sense.
| skeptrune wrote:
| >From the post: There is no easy way to send the same prompt to
| multiple agents at once. For instance, if all agents are stuck
| on the same misunderstanding of the requirements, I have to
| copy-paste the clarification into each session.
|
| It's not just about zero shotting. You should be able to ping
| pong back and forth with all of the parallel agents at the same
| time. Every prompt is a dice roll, so you may as well roll as
| many as possible.
| layoric wrote:
| > Every prompt is a dice roll, so you may as well roll as
| many as possible.
|
| Same vibe as the Datacenter Scale xkcd ->
| https://xkcd.com/1737/
| vFunct wrote:
| Yah it's not really usable for iteration. I don't parallelize
| this way. I parallelize based on functions. Different agents
| for different function.
|
| Meanwhile, a huge problem in parallelization is maintaining
| memory-banks, like https://docs.cline.bot/prompting/cline-
| memory-bank
| lmeyerov wrote:
| I like to think about maximizing throughput while minimizing
| attention: both matter, and the proposal here is expensive on my
| attention. Optimizing per-task latency matters less than enabling
| longer non-interactive runs.
|
| For parallelism, I'm finding it more productive to have multiple
| distinct tasks that I multitask on and guide each to completion.
| Along the way I improve the repo docs and tools so the AI is more
| self-sufficient the next time, so my energy goes more to enabling
| longer runs.
|
| Ex: One worker improving all docs. I can come back, give
| feedback, and redo all of them. If I'm going to mess with
| optimizing agent flows, it'd be to make the repo style guide
| clearer to the AI. In theory I can divide docs sections and
| manually run sections in parallel, or ask for multiple parallel
| versions of it all for comparison... But that's a lot of
| overhead. Instead, I can fork the repo and work another another
| non-docs issue in parallel. A. Individual task is slow, but I get
| more tasks done, and with less human effort.
|
| I'd like tools to automate fork/join parallelism for divide-and-
| conquer plans, and that feels inevitable. For now, they do fairly
| linear CoT, and easier for me to do distinct tasks vs worrying
| about coordinating.
| dgunay wrote:
| This looks like a much more sophisticated version of my setup. I
| had Aider vibe code me a script that just manages cloning a repo
| into a subfolder, optionally with some kind of identifying suffix
| on it, and then wrote a tiny script to automate calling that
| script, `cd`ing into the directory, and then running codex-cli on
| it. The resulting workflow: I open a new terminal, type `vibe
| --suffix=<suffix> <prompt>`, and then I can go do something else.
| 8200_unit wrote:
| Could you share your scripts?
___________________________________________________________________
(page generated 2025-05-28 23:00 UTC)