[fhd2]

Even if somebody shows you what they've built with it, you're none the wiser. All you'll know is that it seemingly works well enough for a greenfield project.

The jury is still very far out on how agentic development affects mid/long term speed and quality. Those feedback cycles are measured in years, not weeks. If we bother to measure at all.

People in our field generally don't do what they know works, because by and large, nobody really knows, beyond personal experiences, and I guess a critical mass doesn't even really care. We do what we believe works. Programming is a pop culture.

[briantakita]

I am now releasing software for projects that have spent years on the back-burner. From my perspective, agent loops have been a success. It makes the impractical pipe-dream doable.

[Nadya]

Yeah, I have a never ending need of things I could easily make myself I I could set aside 7-10 hours to plan it out, develop and troubleshoot but are also low priority enough that they sit on the back burner perpetually.

Now these things are being made. I can justify spending 5-10 minutes on something without being upset if AI can't solve the problem yet.

And if not, I'll try again in 6 months. These aren't time sensitive problems to begin with or they wouldn't be rotting on the back burner in the first place.

[sarchertech]

That’s completely ignoring the point of the person you are responding to. They weren’t talking about small greenfield projects.

[briantakita]

Agent loops also enables the "hard discipline" of making sure all of the tests are written, documentation is up to date, specs are explicitly documented, etc. Stuff that often gets dropped/deprioritized due to time pressure & exhaustion. Gains from automation applies to greenfield & complex legacy projects.

[sarchertech]

Well that’s more on topic as a response to the original poster. Still not really in keeping with the original thread question though of show me the beef.

[echelon]

I'm using Claude Code (loving it) and haven't dipped into the agentic parallel worker stuff yet.

Where does one get started?

How do you manage multiple agents working in parallel on a single project? Surely not the same working directory tree, right? Copies? Different branches / PRs?

You can't use your Claude Code login and have to pay API prices, right? How expensive does it get?

[ecliptik]

Check out Claude Code Team Orchestration [1].

Set an env var and ask to create a team. If you're running in tmux it will take over the session and spawn multiple agents all coordinated through a "manager" agent. Recommend running it sandboxed with skip-dangerous-permissions otherwise it's endless approvals

Churns through tokens extremely quickly, so be mindful of your plan/budget.

1. https://code.claude.com/docs/en/agent-teams

[bernardom]

git checkout four copies of your repo (repo, repo_2, repo_3, repo_4) within each one open claude code Works pretty well! With the $100 subscription I usually don't get limited in a day. A lot of thinking needs to go into giving it the right context (markdown specs in repo works for us)

Obv, work on things that don't affect each other, otherwise you'll be asking them to look across PRs and that's messy.

[cronin101]

Look into git worktrees and thank me later!

[tbcj]

Agreed here’s a blog I read where I found out about Claude’s support https://jamesanglin.com/blog/claude-code-worktrees

[suzzer99]

Does good design up front matter as much if an AI can refactor in a few hours something that would take a good developer a month? Refactoring is one of those tasks that's tedious, and too non-trivial for automation, but seems perfect for an AI. Especially if you already have all the tests.

[qudat]

I’m constantly using code agents to work on feature development and they are constantly getting things wrong. They can refactor high level concepts but I have to nudge them to think about the proper abstractions. I don’t see how a multiagent flow could handle those interactions. The bus factor is 1, me.

[cloverich]

Try building review skills based on how you review. I built one recently based on how I review some of the concurrent backend stuff one of our tools does. I have it auto-run on every PR. It's great, it catches tons of stuff, and ranks the issues by severity. Over 10 reviews, only 1 false positive (hallucination) and several critical catches. I wish I'd set it up sooner.

Can also after those sessions where they get stuff wrong, ask for an analysis of what it got wrong that session, and produce a ranked list. I just started that and wow, it comes up with pretty solid lists. I'm not sure if its sustainable to simply consolidate and prune it, but maybe it is?

[veilrap]

Upgrades, API compatibility, and cross version communication are really important in some domains. A bad design can cause huge pain downstream when you need to make a change.

[Jensson]

> Especially if you already have all the tests.

Most tests people write have to be changed if you refactor.

[suzzer99]

They shouldn't. Refactor shouldn't affect requirements, and tests should be based on requirements. I'm talking about integration and e2e tests, not unit. In this brave new world I'm not sure you need unit tests.