Hacker RealtimeBuilt with Neon Realtime
connecting… · checking source…

Comment on Hacker News

  1. The mythical man-month was not only about programming itself, but everything around it. The argument was that projects in large organizations are more akin to pregnancies, with stages that cannot be sped up, rather than a bunch of tasks that can just be solved whenever, by whoever.

    This article seems to be instead about whether AI models can be parallelized. And if so, yes, absolutely, in fact you should be trying to break down tasks in a way that they can be worked in parallel. Looking at the frontier, the math results from openAI are coming from a massive parallelization of agents for example, which is why they could crack a millenium problem in like four days.

    reply
  2. > "Adding agents to a project with unclear requirements gets you the wrong answer faster."

    The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements.

    reply
  3. The author misapplies/misunderstands the mythical man month even in the first example. It does not apply for idea generation and also not to problem solving/ fixing things, only to software creation. Even then, it also does not apply when creation is cheap, if you can generate 100 solutions cheaply without coordination between them and pick the winner with a relatively fast eval, creation behaves way more like fixing / problem solving.
    reply
  4. Related thing is that LLMs are still notoriously bad at writing instructions for themselves (so managing themselves also). They tend to overspecify. If I had a copy of myself I would tell him "do the thing", but agents say "do the thing like this and this, it must be such and such, use X and put it together that way". The subagent is just as intelligent but now it's constrained, sometimes as you start developing something you discover some things are better organized in a different way etc. So it spends much time figuring out how to deliver exactly what was asked even if it's not optimal because that's the task.

    Basically a company where you can't ever question decisions of the higher ups, not even ask for clarification, but they force implementation choices on you. I mean, it definitely does happen, but the results are usually not great. Not alawys. For some tasks it works.

    reply
  5. > Throw nine autonomous agents at a single codebase without crystal-clear orchestration, and they will happily rewrite each other's work in a high-speed loop.

    This is an easily solvable "problem". Pretty much all harness/agent orchestrators support spawning subagents/threads with different models and get them to work together cleanly. I don't even need any kind of special skills. Inside a vanilla claude session, I sometimes ask it to use `codex` and review the kind and work on the findings it generates.

    reply
  6. But it’s not a man-month anymore. It’s like half a day.

    And if I break up an application then 9 coders with Claude Code can build that application in an unprecedentedly short period.

    reply
  7. Agents seem to be useful for quickly mapping a problem space through trial&error + throwing stuff at the wall and seeing what sticks.

    Anything grindy. Reverse engineering. Performance optimizations.

    That's where swarms shine I think. But that's a much much much smaller problem space than what these agents are being sold for.

    reply
  8. Curious to see if on average a group of agents reached the right solution[0]. Built a message-board for agents and me to interact. Has not produced anything better than a single agent session. The interactions are pretty funny.

    Maybe there need to be more agents before the averaging effect kicks in.

    [0] https://en.wikipedia.org/wiki/Wisdom_of_the_crowd

    reply
  9. i think of the mythical man-month at least once a day.

    if i would know EXACTLY what and how I had to build stuff, it would probably not apply. But at least for me and my projects, that is not the case. Planning and building in parallel has given me too many headaches.

    If you are building something stable, secure - well thought through and executed, you hardly get around sequential building.

    reply
  10. the bottleneck is now how fast can you plan requirements, how fast can you check those requirements were met. Stack : Greptile + TesterArmy
    reply
  11. There is a great turkish proverb about this "one hand is nothing,two hands make a sound" (i hope i translated it right). So,adding people to a task isnt necessarily bad in every situation. Honestly, it depends on the nature of the job beacuse everyone approaches a problem from diffrent perspective
    reply
  12. From my last month's clauding experience, these agents now understand what needs to remain sequential and just wait for the other agents to get done.
    reply
  13. A simple observation here is that historically inter people communication is the main scaling bottleneck in software teams. It's what's behind the main premise in the mythical man month that adding more people to a team makes it slower. You increase the man months, but you are adding so much overhead that it's a net loss.

    It's why big software companies struggle getting big things done whereas small and nimble startups tend to run circles around those. Google, Apple, Amazon, and Microsoft are great examples of companies that are really struggling with doing anything outside of the stuff they are already know how to do despite adding people by the thousands/tens of thousands. The more people they have the less likely any of them is going to be to do something completely new and different.

    How does AI impact all this? It makes the problem (inter people communication) much worse. Imagine five people doing things manually. They have to sync up regularly. But there's only so much they can do in a day so they can stay in sync relatively easy. Scale that to 50. Now your meeting overhead becomes very non trivial.

    Now add AI to the mix. Each of these people goes off and maxes out their tokens every day. They are refactoring, adding new sub systems/products, new UIs, etc. How do they coordinate their actions? How are they going to communicate their intentions and actions to each other. How do they brief each other on what's already been done?

    The day to day scope of the massive amount of changes done by each of those individuals quickly grows way beyond whatever fits in typical/reasonable meeting structures. So, all the obvious things start happening: people either don't communicate or communicate poorly. They work against each other, break each other's work, etc. Everybody has a hard time staying on whatever is happening. The easy implication is exactly what we see happening in most big organizations: not much happening at all. They were already bottle necked on their size. AI made the problem much worse and as a result they aren't getting more done. At best they are maybe getting about the same stuff done with a bit less people.

    AI clearly favors setups where you can minimize all of the communication. Small 1-3 person teams are probably a lot more optimal here. They always were and e.g. Jeff Bezos figured that out early in the life of Amazon (the two pizza rule). But AI just makes it much more obvious. Remove the need to sync lots of people and you free up time to actually do stuff (with or without AI).

    The same dynamic probably holds to some extent with using multiple agents. If you are burning a lot of tokens and time on getting agents to sync with each other, that overhead is only going to get worse if you add more agents probably. And if you need to be in the loop to micro manage them, you become the bottleneck. Even if you just work by yourself. The trick is providing enough autonomy so you don't have to micro manage as much. And structuring your agents to minimize the amount of other agents each agent has to sync up with. The two pizza rule still holds.

    reply
  14. Would an unlimited context window enable you to solve all requests instantly ? No
    reply
  15. The Mythical Token-Minute.
    reply
  16. Don't forget to tell the agent to never generate buggy code.
    reply
  17. How about RSI? Recursive Self Improvement? I wonder the author's view on that.
    reply
  18. Is it just me or is this article itself AI? Or is everyone just adopting the AI tone and writing style now?
    reply
  19. Here's a question, to people who delegate all their coding to AI agents now: What are you doing to keep your mind exercised in all this suddenly new free time you have? Personally I find talking with agents extremely tedious and unrewarding; I would rather just write the code, even if it's simply because it's more interesting than playing Sudoku or whatever the fuck you do when you have nothing to do with your brain.

    And talking to AI agents is not the same as using your brain. It's frustrating, it seems to be intelligent, you think you're using reason with them, but it rapidly degrades your ability to reason. It encourages you to accept answers without checking them thoroughly. So much for the skills of accuracy and integrity you built up. It's a sugar rush.

    reply
  20. How we've ended up cornered in this spot as an industry? From human craft to onboarding and baby sitting agents?? That sounds just stupid. I won't be surprise to learn, after ai companies go public, that those who pushed hard for agentic coding just disappear o will push for something else. What we have produced so far of extraordinary or even just good value? Please no math conjectures or advancements, there is no field benefit in brute forcing problems
    reply