8 ms·

This is interesting to hear, but I don't understand how this workflow actually works. I don't need 10 parallel agents making 50-100 PRs a week, I need 1 agent

• baby 9mo ago
  I usually have 4-5, but it's because they are working on different parts of the codebase, or some I will use as read only to brainstorm
• quijoteuniv 9mo ago
  This is it! “I don't need 10 parallel agents making 50-100 PRs a week, I need 1 agent that successfully solves the most important problem.”
  • tuananh 9mo ago
    maybe more like throw shits to the wall and see what sticks?
  • MattGaiser 9mo ago
    Do you generally only have one problem? For me the use case is that I have numerous needs and Claude frees up time to work on some of the more complicated ones.
• stoneforger 9mo ago
  The captive audience is not you, it's people salivating at the train of thought where they can 100x productivity of whatever and push those features that will get paying customers so they can get bought from private equity and ride out on the sunset. This whole thing is existential dread on a global scale, driven by sociopaths and everyone is just unable to not bend over.
  • gherkinnn 9mo ago
    Painfully true. A lot of YouTube on LLM coding tools has become just that. Make quick bucks, look it generated a dashboard of some sort (why is it always dashboards?) and a high polished story of someone vibing a copy of a successful Saas and selling it off for a million. A shame really, for there are good resources for better making use of LLMs in coding.
• ex-aws-dude 9mo ago
  Yeah I don’t understand these posts recently with people running 10 at once Can someone give an example of what each of them would be doing? Are they just really slow, is that the problem?
  • MattGaiser 9mo ago
    Yep. For one of the things I am doing, I am the solo developer on a web application. At any given point, there are 4-5 large features I want and I instruct Claude to heavily test those features, so it is not unusual for each to run for 30-45 minutes and for overall conversations to span several hours. People are correct that it often makes mistakes, so that testing phase usually uncovers a bunch of issues it has to fix. I usually have 1-2 mop up terminal windows open for small things I notice as I go along that I want to fix. Claude can be bad about things like putting white text on a white button and I want a free terminal to just drop every little nitpick into it. They exist for me to just throw small tasks into. Yes, you really should start a new convo every need, but these are small things and I do not want to disrupt my flow. There are another 2-3 for smaller features that I am regularly reviewing and resetting. And then another one dedicated to just running the tests already built over and over again and solving any failures or investigating things. Another one is for research to tell me things about the codebase.
    • sleepychu 9mo ago
      Where is Claude's checkout? Do you have them all share the same local files or does each use its own copy?
      • MattGaiser 9mo ago
        People are doing this lots of different ways. Some run it in its own containers or in instances on the web. Some are using git worktrees. I use a worktree for anything large, but smaller stuff is just done in the local files. Sloppy? Perhaps, but Claude has never made such a big mess that it has needed its work wiped.
• danso 9mo ago
  Yes thank you! I find I get more than enough done (and more than enough code to review) by prompting the agent step by step. I want to see what kind of projects are getting done with multiple async autonomous agents. Was hoping to find youtube videos of someone setting up a project for multiple agents so I could see the cadence of the human stepping in and making directions
• CraigJPerry 9mo ago
  >> I need 1 agent that successfully solves the most important problem In most of these kinds of posts, that's still you. I don't believe i've come across a pro-faster-keyboard post yet that claims AGI. Despite the name, LLMs have no agency, it's still all on you. Once you've defined the next most important problem, you have a smaller problem - translate those requirements into code which accurately meets them. That's the bit where these models can successfully take over. I think of them as a faster keyboard and i've not seen a reason to change my mind yet despite using them heavily.
  • TeodorDyakov 9mo ago
    Why do you assume AGI needs to have agency?
    • ponco 9mo ago
      Not OP, but I think that without some creative impetus like 'agency', how useful is an AGI going to be?
      • TeodorDyakov 9mo ago
        If cars do not have agency how useful are they going to be. If the Internet does not have agency how useful is going to be. if fire has no agency (debatable) how useful is going be.
    • losvedir 9mo ago
      Call it what you want, but people are going to call the LLM with tools in a loop, and it will do something. There was the AI slop email to Rob Pike thing the other day, which was from someone giving an agent the instruction to "do good", or some vague high level thing like that.
• csomar 9mo ago
  It's all smokes really. Claude Code is an unreliable piece of software and yet one of the better ones in LLM-Coding. (https://github.com/anthropics/claude-code/issues https://github.com/anthropics/claude-code/issues). That and I highly suspect it's mostly engineers who are working on it instead of LLMs. Google itself with all its resources and engineers can't come up with a half-decent CLI for coding. Reminder: The guy works for Claude. Claude is over-hyping LLMs. That's like a Jeweler dealer assistant telling you how Gold chains helped his romantic life.
  • TheRoque 9mo ago
    Gemini CLI is decent.
    • me_bx 9mo ago
      Is it? Yesterday, gemini told me to run this: echo 'export ANDROID_HOME=/opt/my-user/android-sdk' > ~/.bashrc Which would have effectively overriden my whole bashrc config if I had blindly copy-pasted it. A few minutes later, asking it to create a .gitignore file for the current project - right after generating a private key, it failed to include the private key file to the .gitignore. I don't see yet how these tools can be labeled as 'major productivity boosters' if you loose basic security and privacy with them...
      • csomar 9mo ago
        We were discussing the CLI, the output that's on the model.
• gherkinnn 9mo ago
  LLM agents can be a bit like slot machines. The more the merrier. And at least two generate continuous shitposts for their companies Slack. That said, having one write code and a clean context review it is helpful.
• raducu 9mo ago
  > don't need 10 parallel agents making 50-100 PRs a week I don't like to be mean, but I few weeks ago the guy bragged about Claude helping him do +50k loc and -48k loc(netting a 2k loc), I thought he was joking because I know plenty of programmers who do exactly that without AI, they just commit 10 huge json test files or re-format code. I almost never open a PR without a thorough cleanup whereas some people seem to love opening huge PRs.
• MattGaiser 9mo ago
  > I need 1 agent that successfully solves the most important problem. If you only have that one problem, that is a reasonable criticism, but you may have 10 different problems and want to focus on the important one while the smaller stuff is AIed away. > I don't understand how you can generate requirements quicky enough to have 10 parallel agents chewing away at meaningful work. I am generally happy with the assumptions it makes when given few requirements? In a lot of cases I just need a feature and the specifics are fairly open or very obvious given the context. For example, I am adding MFA options to one project. As I already have MFA for another portal on it, I just told Claude to add MFA options for all users. Single sentence with no details. Result seems perfectly servicable, if in need of some CSS changes.
  • vidarh 9mo ago
    Exactly. And if that problem is complex, your first step should be to plan how to sub-divide it anyway. So just ask Claude to map out interdependencies for tasks to look for opportunities to paralellise.
• victorbjorklund 9mo ago
  Depends on the project you are working on. Solo on a web app? You probably have 100s of small things to fix. Some more padding there, add a small new feature here, etc.
• exitb 9mo ago
  Multiple instances of agents are an equivalent to tabs in other applications - primarily holders of state, rather than means for extreme parallelism.
  • Deukhoofd 9mo ago
    Personally I just use /resume to switch back to other states when I need to.
  • yoz-y 9mo ago
    I have not used Claude. But my experience with Gemini and aider is that multiple instances of agents will absolutely stomp over each other. Even in a single sessions overwriting my changes after telling the agent that I did modifications will often result in clobbering.
    • adam_patarino 9mo ago
      Proper sandboxing can fix this. But I didn’t see op mention it which I thought was weird
      • marcsto2 9mo ago
        Op mentions in the follow up comments that he does a separate git checkout, one for each of the 5 Claude Code agents he runs. So each is independent and when PRs get submitted that's where the merging happens.
    • allan_s 9mo ago
      See the agent as a coworker ssh-ing on your machine, how would you work efficiently ? By working on the same directory ? No You give each agent a git worktree and if you want to check, you checkout their branch.
    • someguyiguess 9mo ago
      You should try Claude opus 4.5 then. I haven’t had that issue. The key is you need to have well defined specs and detailed instructions for each agent.
• giancarlostoro 9mo ago
  I use Beads which makes it more easy to grasp since its "tickets" for the agent, and I tell it what I want, it creates a bead (or "ticket") and then I ask it to do research, brain dump on it, and even ask it to ask me clarifying questions, and it updates the tasks, by the end once I have a few tasks with essentially a well defined prompt, I tell Claude to run x tasks in parallel, sometimes I dump a bunch of different tasks and ask it to research them all in parallel, and it fills them in, and I review. When it's all over, I test the code, look at the code, and mention any follow ups. I guess it comes down to, how much do you trust the agent? If you don't trust it fully you want to inspect everything, which you still can, but you can choose to do it after it runs wild instead of every second it works.
• elmigranto 9mo ago
  [flagged]
• ponco 9mo ago
  I agree. I'm imagining a large software team with hundreds of tickets "ready to be worked on" might support this workflow - but even then, surely you're going to start running into unnecessary conflicts. The max Claude instances I've run is 2 because beyond that, I'm - as you say - unable to actually determine the next best course during the processing time. I could spend the entire day planning / designing prompts - and perhaps that will be the most efficient software development practise in the future. And/or perhaps there it is a sign I'm doing insufficient design up front.
• stingraycharles 9mo ago
  I hope self-promotion isn't frowned upon, but I've been spending the past months figuring out a workflow [1] that helps tackle the "more complicated problems" and ensure long-term maintainability of projects when done purely through Claude Code. Effectively, I try to: - Do not allow the LLM to make any implicit decisions, but instead confirm with the user. - Ensure code is written in such a way that it's easy to understand for LLMs; - Capture all "invisible knowledge" around decisions and architecture that's difficult to infer from code alone. It's based entirely on Claude Code sub-agents + skills. The skills almost all invoke a Python script that guides the agents through workflows. It's not a fast workflow: it frequently takes more than 1 hour just for the planning phase. Execution is significantly faster, as (typically) most issues have been discovered during the planning phase already (otherwise it would be considered a bug and I'd improve the workflow based on that). I'm under the impression that the creator of Claude Code's post is also intended to raise awareness of certain features of Claude Code, such as hand-offs to the cloud and back. Their workflow only works for small features. It reads a bit like someone took a “best practices” guide and turned it into a twitter post. Nice, but not nearly detailed enough for an actual workflow. [1] https://github.com/solatis/claude-config/ https://github.com/solatis/claude-config/
  • erichocean 9mo ago
    > Ensure code is written in such a way that it's easy to understand for LLMs Over the summer last year, I had the AI (Gemini Pro 2.5) write base libraries from scratch that area easy for itself to write code against. Now GPro3 can one-shot (with, at most, a single debug loop at the REPL) 100% of the normal code I need developed (back office/business-type code). Huge productivity booster, there are a few things that are very easy for humans to do that AI struggles with. By removing them, the AI has been just fantastic to work with.
    • djmips 9mo ago
      How would you characterize code is easy for AI to write code against. - and wouldn't that also be true for humans?
• AtlasBarfed 9mo ago
  Claude is absolutely plastering Facebook with this bullshit. Every PR Claude makes needs to be reviewed. Every single one. So great! You have 10 instances of Claude doing things. Great! You're still going to need to do 10 reviews.
  • eru 9mo ago
    That's why you have Codex review the code. (I'm only half joking. Having one LLM review the PRs of another is actually useful as a first line filter.)
    • vidarh 9mo ago
      Even having Opus review code written by Opus works very well as a first pass. I typically have it run a sub-agent to review its own code using a separate prompt. The sub-agents gets fresh context, so it won't get "poisoned" by the top level contexts justifications for the questionable choices it might have made. The prompts then direct the top level instance to repeat the verification step until the sub-agent gives the code a "pass", and fix any issues flagged. The result is change sets that still need review - and fixes - but are vastly cleaner than if you review the first output. Doing runs with other models entirely is also good - they will often identify different issues - but you can get far with sub-agents and different persona (and you can, if you like, have Claude Code use a sub agent to run codex to prompt it for a review, or vice versa - a number of the CLI tools seems to have "standardized" on "-p <prompt>" to ask a question on the command line) Basically, reviewing output from Claude (or Codex, or any model) that hasn't been through multiple automated review passes by a model first is a waste of time - it's like reviewing the first draft from a slightly sloppy and overly self-confident developer who hasn't bothered checking if their own work even compiles first.
      • eru 9mo ago
        Thanks, that sounds all very reasonable! > Basically, reviewing output from Claude (or Codex, or any model) that hasn't been through multiple automated review passes by a model first is a waste of time - it's like reviewing the first draft from a slightly sloppy and overly self-confident developer who hasn't bothered checking if their own work even compiles first. Well, that's what the CI is for. :) In any case, it seems like a good idea to also feed the output of compiler errors and warnings and the linter back to your coding agent.
• ukprogrammer 9mo ago
  skill issue same way a lesser engineer might say they cannot do X or Y
• thomasfromcdnjs 9mo ago
  I run 3-5 on distinct projects often. (20x plan) I quite enjoy the context switching and always have. I have a vanilla setup too, and I don't use plugins/skills/commands, sometimes I enable a MCP server for different things and definitely list out cli tools in my claude.md files. I keep a Google doc open where I list out all the projects I'm working on and write notes as I'm jumping thought the Claude tabs, I also start drafting more complex prompts in the Google doc. I've been using turbo repo a lot so I don't have to context switch the architecture in my head. (But projects still using multiple types of DevOps set ups) Often these days I vibe code a feedback loop for each project, a way to validate itself as OP said. This adds time to how long Claude takes to complete giving me time to switch context for another active project. I also use light mode which might help others... jks
• deleted 9mo ago
  [deleted]
• vidarh 9mo ago
  > I don't understand how you can generate requirements quicky enough to have 10 parallel agents chewing away at meaningful work. You use agents to expand the requirements as well, either in plan mode (as OP does) or with a custom scaffold (rules in CLAUDE.md about how to handle requirements; personally I prefer giving Claude the latitude to start when Claude is ready rather than wait for my go-ahead) > I don't understand how you can have any meaningful supervising role over 10 things at once given the limits of human working memory. [this got long: TL;DR: This is what works for me: Stop worrying about individual steps; use sub-agents and slash-commands to encapsulate units of work to make Claude run longer; use permissions to allow as much as you dare (and/or run in a VM to allow Claude to run longer; give Claude tools to verify its work (linters, test suites, sub-agents double-checking the work against the spec) and make it use it; don't sit and wait and read invidiual parts of the conversation - it will only infuriate you to see Claude make stupid mistakes, but if well scaffolded it will fix them before it returns the code to you, so stop reading, breathe, and let it work; only verify when Claude has worked for a long time and checked its own work -- that way you review far less code and far more complete and coherent changes] You don't. You wait until each agent is done, and you review the PR's. To make this kind of thing work well you need agents and slash-commands, like OP does - sub-agents in particular help prevent the top-level agents from "context anxiety": Claude Code appears to have knowledge of context use, and will be prone to stopping before context runs out; sub-agents use their own context and the top-level agent only uses context to manage the input to and output from them, so the more is farmed out to sub-agents, the longer Claude Code is willing to run. I when I got up this morning, Claude Code had run all night and produced about 110k words of output. This also requires extensive permissions to use safe tools without asking (what OP does), or --dangerously-skip-permissions (I usually do this; you might want to put this in a container/VM as it will happily do things like "killall -9 python" or similar without "thinking through" consequences - I've had it kill the terminal it itself ran in before), or it'll stop far too quickly. You'll also want to explicitly tell it to do things in parallel when possible. E.g. if you want to use it as a "smarter linter" (DO NOT rely on it as the only linter, use a regular one too, but using claude to apply more complex rules that requires some reasoning works great), you can ask it to "run the linter agent in parallel on all typescript files" for example, and it will tend to spawn multiple sub-agents running in parallel, and metaphorically twiddle its thumbs waiting for them to finish (it's fun seeing it get "bored" and decide to do other things in the meantime, or get impatient and check on progress obsessively). You'll also want to make Claude use sub-agents to review, verify, test its work, with instructions to repeat until all the verification sub-agents give its changes a PASS (see 12/ and 13/ in the thread) - there is no reason for you to waste your time reviewing code that Claude itself can tell isn't ready. [E.g. concrete example: "Vanilla" Claude "loves" using instance_variable_get() in Ruby if facing a class that is missing an accessor for an instance variable. Whether you know Ruby or not, that should stand out like a sore thumb - it's a horrifically gross code smell, as it's basically bypassing encapsulation entirely. But you shouldn't worry about that - if you write Ruby with Claude, you'd want a rule in CLAUDE.md telling it how to address missing accessors, and sub-agent, and possibly a hook, making sure that Claude is told to fix it immediately if it ever uses it.] Farming it off to sub-agents both makes it willing to work longer, especially on "boring" tasks, and avoids the problem that it'll look at past work and decide it already "knows" this code is ready and start skipping steps. The key thing is to stop obsessing over every step Claude takes, and treat that as a developer experimenting with something they're not clear on how to do yet. If you let it work, and its instructions are good, and it has ways of checking its work, it will figure out its first attempts are broken, fix them, and leave you with output that takes far less of your time to review. When Claude tells you its done with a change, if you stop egregious problems, fix your CLAUDE.md, fix your planning steps, fix your agents. None of the above will absolve you of reviewing code, and you will need to kick things back and have it fix them, and sometimes that will be tedious, but Claude is good enough that the problems you have it fix should be complex, not simple code smells or logic errors, and 9 out 10 times they should signal that your scaffold is lacking important detail about your project or that your spec is incomplete at a functional/acceptance criteria level (not low level detail)
• crystal_revenge 9mo ago
  My initial response to reading this post was "wow, I think I'd rather just write the code". I also remain a bit skeptical because, if all of this really worked (and I mean over a long time and scaling to meet a range of business requirements), even if it's not how I personally want to write code, shouldn't we be seeing a ton of 1 person startups? I see Bay area startups pushing 996 and requiring living in the Bay area because of the importance of working in an office to reduce communication hurdles. But if I can really 10x my current productivity, I can get the power of a seed series startup with even less communication overhead (I could also get by with much less capital). Imagine being able to hire 10 reliable junior-mid engineers who unquestionably followed your instruction and didn't need to sleep. This is what I keep being told we have for $200/month. Forget not needing engineers, why do we need angel investors or even early stage VC? A single smart engineer should be able, if all the claims I'm hearing are true, to easily accomplish in months what used to take years. But I keep seeing products shipped at the same speed but with a $200 per month per user overhead. Honestly I would love to be wrong on this because that would be incredibly cool. But unfortunately I'm not seeing it yet.
  • ChadNauseam 9mo ago
    I do stuff in my free time now that would have been a full time job a year ago. Accomplishing in months what would have taken years. (And doing in days what would have taken weeks.) I'm talking about actually built-out products with a decent amount of code and features, not basic prototypes. I feel like the vibe is "put up or shut up", so check out my bio for one example. I think your logic goes wrong because you assume that more productivity implies less desire for engineers. But now engineers are maybe 2x or 5x more productive than before. So that makes them more attractive to hire than before. It's not like there was some fixed pool of work to be done and you just had to hire enough to exhaust the pool. It's like if new pickaxes were invented that let your gold miners dig 5x more gold. You'd see an explosion in gold miners, not a reduction. For another example, I spend all my free time coding now because I can do so much now. I get so much more result for the same effort, that it makes sense to put more effort in.
    • llmslave2 9mo ago
• bob1029 9mo ago
  If you're trying to solve one very hard problem, parallelism is not the answer. Recursion is. Recursion can give you an exponential reduction in error as you descend into the call stack. It's not guaranteed in the context of an LLM but there are ways to strongly encourage some contraction in error at each step. As long as you are, on average, working with a slightly smaller version of the problem each time you recurse, you still get exponential scaling.
• Haaargio 9mo ago
  I would do the same thing if I would justifing paying 200$ per Month for my hobby. But even with that, you will run into throttling / API / Resource limits. But AI Agents need time. They need a little bit of reading the sourcecode, proposing the change, making the change, running the verification loop, creating the git commit etc. Can be a minute, can be 10 and potentially a lot longer too. So if your code base is big enough that you can work o different topics, you just do that: - Fix this small bug in the UI when xy happens - Add a new field to this form - Cleanup the README with content x - . . . I'm an architect at work and have done product management on the side as its a very technical project. I have very little problem coming up with things to fix, enhnace, cleanup etc. I have hard limits on my headcount. I could easily do a handful of things in parallel and keeping that in my head. Working memory might be limited but working memory means something different than following 10 topics. Especially if there are a few tpics inbetween which just take time with the whole feedback loop. But regarding your example of house cleaning: I have ADHD, i sometimes work like this. Working on something, waiting for a build and cleaning soming in parallel. What you are missing is the practical experience with Agents. Taking the time and energy of setting up something for you, perhaps accessability too? We only got access at work to claude code since end of last year.
• BiteCode_dev 9mo ago
  At the begining of the project, the runs are fast, but as the project gets bigger, the runs are slower: - there are bigger contexts - the test suite is much longer and slower - you need to split worktree, resources (like db, ports) and sometimes containers to work in isolation So having 10 workers will run for a long time. Which give plenty of time to write good spec. You need good spec, so the llm produce good tests, so it can write good code to match these tests. Having a very strong spec + test suite + quality gates (linter, type checkers, etc) is the only way to get good results from an LLM as the project become more complex. Unlike a human, it's not very good at isolating complexity by itself, nor stopping and asking question in the face of ambiguity. So the guardrails are the only thing that keeps it on track. And running a lot of guardrail takes time. E.G: yesterday I had a big migration to do from HTMX to viewjs, I asked the LLM to produce screenshots of each state, and then do the migration in steps in a way that kept the screenshit 90% identical. This way I knew it would not break the design. But it's very long to run e2e tests + screenshot comparison every time you do a modification. Still faster than a human, but it gives plenty of time to talk to another llm. Plus you can assign them very different task: - One work on adding a new feature - One improves the design - One refactor part of the code (it's something you should do regularly, LLM produce tech debt quickly) - One add more test to your test suite - One is deploying on a new server - One is analyzing the logs of your dev/test/prod server and tell you what's up - One is cooking up a new logo for you and generating x versions at different resolutions. Etc. It's basically a small team at your disposal.
• eaurouge 9mo ago
  > It's like someone is claiming they unlocked ultimate productivity by washing dishes, in parallel with doing laundry, and cleaning their house. But we do this routinely with machines. Not saying I don't get your point re 100 PRs a week, just that it's a strange metaphor given the similarities.
• port3000 9mo ago
  50-100 PRs a week but they still can't fix the 'flickering' bug
• William_BB 9mo ago
  This is just the creator of Claude Code overselling Claude Code
• david_shi 9mo ago
  > It's like someone is claiming they unlocked ultimate productivity by washing dishes, in parallel with doing laundry, and cleaning their house. In this case you have to take a leap of faith and assume that Claude or Codex will get each task done correctly enough that your house won't burn down.
• aforwardslash 9mo ago
  It depends on the specifics of the tasks; I routinely work on 3-5 projects at once (sometimes completely different stuff), and having a tool like cloud code fits great in my workflow. Also, the feedback doesnt have to be immediate: sometimes I have sessions that run over a week, because of casual iterations; In my case its quite common to do this to test concepts, micro-benchmarking and library design.
• CuriouslyC 9mo ago
  The problem isn't generating requirements, it's validating work. Spec driven development and voice chat with ticket/chat context is pretty fast, but the validation loop is still mostly manual. When I'm building, I can orchestrate multiple swarm no problem, however any time I have to drop in to validate stuff, my throughput drops and I can only drive 1-2 agents at a time.
• gedy 9mo ago
  > This is interesting to hear, but I don't understand how this workflow actually works The cynic in me is it's a marketing pitch to sell "see this is way cheaper than 10 devs!". The "agent" thing leans heavily into bean counter CTO/CIO marketing.
• drbojingle 9mo ago
  Prototyping.
• carefulfungi 9mo ago
  My impression is that people who are exploring coordinated multi-agent-coding systems are working towards replacing full teams, not augmenting individuals. "Meaningful supervising role" becomes "automated quality and process control"; "generate requirements quickly" -> we already do this for large human software teams. If that's the goal, then we shouldn't interpret the current experiment as the destination.
• dangus 9mo ago
  Let’s not forget the massive bias in the author: for all we know this post is a thinly veiled marketing pitch for “how to use the most tokens from your AI provider and ramp up your bill.” This isn’t about being the most productive or having the best workflow, it’s about maximizing how much Claude is a part of your workflow.
• HarHarVeryFunny 9mo ago
  I suppose he may have a list of feature requests and bug reports to work on, but it does seem a bit odd from a human perspective to want to work on 5 or more things literally in parallel, unless they are all so simple that there is no cognitive load and context switching required to mentally juggle them. Washing dishes in parallel with laundry and cleaning is of course easily possible, but precisely because there is no cognitive load involved. When the washing machine stops you can interrupt what you are doing to load clothes into the drier, then go back to cleaning/whatever. Software development for anything non-trivial obviously has a much higher task-switching overhead. Optimal flow for a purely human developer is to "load context" at the beginning of the day, then remain in flow-state without interruptions. The cynical part of me can't also help but wonder if Cherny/Anthopic aren't just advocating token-maxxing!
  • nbates80 9mo ago
    Same though here. I use Claude opus via api billing for tasks not that hard to implement but for which CC takes much less time than I would. However: * a small PR costs 5-16 usd (I’ve been monitoring this for the past two days). Management is already pushing for us to use Cursor or a new tool called Augment Cod. * I can submit 4 to 5 PRs in a day * the bottleneck becomes: - writing clear instructions and making the right choices - running tests - my mental capacity for context switching - code reviewing, correcting - Deployment - Even further live testing I don’t understand how I could have 10 parallel workers without the output being degraded due to my inability to manage them. But I can see myself wasting a lot of $$ trying. And something tells me the thread is just normalizing throwing money at them
    • HarHarVeryFunny 9mo ago
      I noticed yesterday that there were 5K+ issues filed against Claude Code on github (but down to 4.8K today!), so it may well be that this is what Cherny is churning through. https://github.com/anthropics/claude-code/issues https://github.com/anthropics/claude-code/issues If you read though a few pages of these issues, it doesn't seem to reflect too well on the quality of the code (self-written by Claude Code), so it seems the furious pace of development/bug fixing maybe shouldn't necessarily be taken as being the pace of generating production quality code. Claude Code is of course very useful, so people are very forgiving about issues, but I can't imagine most corporate software being very well regarded if the quality was such that it had 5K issues reported against it!
• headcanon 9mo ago
  Potentially, a lot of that isn't just code generation, it *is* requirements gathering, design iteration, analysis, debugging, etc. I've been using CC for non-programming tasks and its been pretty successful so far, at least for personal projects (bordering on the edge of non-trivial). For instance, I'll get a 'designer' agent coming up with spec, and a 'design-critic' to challenge the design and make the original agent defend their choices. They can ask open questions after each round and I'll provide human feedback. After a few rounds of this, we whittle it down to a decent spec and try it out after handing it off to a coding agent. Another example from work: I fired off some code analysis to an agent with the goal of creating integration tests, and then ran a set of spec reviewers in parallel to check its work before creating the actual tickets. My point is there are a lot of steps involved in the whole product development process and isn't just "ship production code". And we can reduce the ambiguity/hallucinations/sycophancy by creating validation/checkpoints (either tests, 'critic' agents to challenge designs/spec, or human QA/validation when appropriate) The end game of this approach is you have dozens or hundreds of agents running via some kind of orchestrator churning through a backlog that is combination human + AI generated, and the system posts questions to the human user(s) to gather feedback. The human spends most of the time doing high-level design/validation and answering open questions. You definitely incur some cognitive debt and risk it doing something you don't want, but thats part of the fun for me (assuming it doesn't kill my AI bill).
• xnx 9mo ago
  Agree. People are stuck applying the "agent" = "employee" analogy and think they are more productive by having a team/company of agents. Unless you've perfectly spec'ed and detailed multiple projects up front, the speed of a single agent shouldn't be the bottleneck.
  • someguyiguess 9mo ago
    That’s how it works though. You create a detailed spec up front. That’s the workflow.
• someguyiguess 9mo ago
  I see you haven’t tried BMAD-METHOD or spec-kit yet.
• bitfilped 9mo ago
  The only way to achieve that level of parallelism is by not knowing what you are doing or the peoblem space you are working in to begin with and just throwing multiple ill defined queries at agents until something "works". It's sort of a modern infinite monkey theorem if you will.