HN

Comments (160)

• freefaler
  I have an interesting observation from the programmers on my team.The good ones are increasingly producing good solution much faster than before.The not so good ones, are doing the same bullshit they did before, but now the don't even bother to check it. For example one requirement to "not implement it in the frontend" led to 3 times PR rejected, because it still has been implemented (even if it's partially there) in the frontend.I'm not sure what's the reason, but I assume it's- inability to understand architecture choices and their consequences- "don't bother me with shit, just pay me a salary" attitudebut the AI lead to amplification of the good and the bad in people.
• Menu

  rimeice
  > "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.
• Menu

  s08148692
  Sequential tasks are still sequential. The difference is one engineer can you work on many sequential tasks in parallel.The old way of working where an engineer picks up a ticket and works it through to completion before working on the next one is over. Engineers in my team work on about 5 at a time, sometimes far more. That might mean working on multiple features at once, or working on CI or DX or tooling improvements or bug fixes while building a feature, but the days of working on one thing at a time are well and truly overContext size and ability to context switch without burnout is what will differentiate a median engineer from a great engineer, not technical ability
• Menu

  jFriedensreich
  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.
• Menu

  ChicagoDave
  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.
• Menu

  comboy
  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.
• impizulu
  > "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."Is it not the same with people? Just slower? Poor management leads to duplication of work all the time.Nowadays it feels like every software engineer also needs to learn management skills (to orchestrate AI agents) no matter how junior you are.
• mr-karan
  > 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.
• Menu

  hypfer
  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.
• pu_pe
  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.
• jleask
  It is an interesting question. Coordination was a key issue that Brooks identified, the more people you have working in a finite area the more they need to coordinate and communicate."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."Humans often do this too. Agents will have to coordinate in this scenario as much as humans. The question is would they be able coordinate more efficiently than humans and so not suffer from this problem as badly?
• iovrthoughtthis
  Ime the work is still a dag and there are still bottle necks when inter task dependencies exist
• Menu

  hizlikovboy27
  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
• oldsklgdfth
  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
• Menu

  LogicArsenal
  "Brooks Law" has not been broken but but we have found a silver bullet. Brooks said in 1986 "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."Claude Code and somewhere around Opus 4.5 I believe my personal productivity improved by at least 1 order of magnitude for the first time in my 25 year career.
• v3ss0n
  Git Worktress, Sub Agent WIth Team Leader agents. I get things done alot faster, You are just doing it wrong.
• portmanteur
  Everyone always said “you can’t put nine women on one pregnancy and get a baby in just one month.” Heck, Elon Musk tried to do it, and wouldn’t you know it, ended up with nine kids!
• Menu

  peterpommes
  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.
• pranavm27
  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.
• jillesvangurp
  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.
• smikhanov
  A usual reminder that this “law” (formulated in 1975, I kid you not) hasn’t been true for at least a decade now.There’s nothing in common between software development as an activity in Brooks’ times and now. This horse is dead, stop flogging it.
• GL26
  the bottleneck is now how fast can you plan requirements, how fast can you check those requirements were met. Stack : Greptile + TesterArmy
• kirykl
  Would an unlimited context window enable you to solve all requests instantly ? No
• adastra22
  The Mythical Token-Minute.
• Menu

  bozdemir
  How about RSI? Recursive Self Improvement? I wonder the author's view on that.
• feverzsj
  Don't forget to tell the agent to never generate buggy code.
• kissgyorgy
  Maybe I don't understand the reasoning or the premise, but subagents can make writing code, experimenting way faster and you don't have to manage them, a large and smart model will manage them for you.Also there are harnesses (e.g. omp) which are using multiple LLMs debating, questioning, reviewing other LLMs output and you get a pretty good result at the end that way, which makes your job of reviewing them faster too.
• hollowturtle
  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
• mytailorisrich
  If you use AI then that is not going to be your bottleneck. So if a project is late one of the options on the table is still to add manpower to "help".So nothing has changed fundamentally, only perhaps superficially.
• Menu

  altmanaltman
  > nine agents still can’t deliver a baby in one month.Very weird way to say this. Like it holds true for biological beings because pregnancy by default has a fixed timeline. But how does this apply to AI? Also what even is an "agent"? Are they distinct worker units on a program or the same worker unit split into multiple instances?Why are we assuming agent = man when its a computer program?
• Menu

  jnmandal
  Is it just me or is this article itself AI? Or is everyone just adopting the AI tone and writing style now?
• Menu

  noduerme
  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.
• ReptileMan
  Not only that but there is limited number of good prompts/design decisions per employee per day.
• tempfile
  Isn't this just blog slop? It doesn't actually present an argument, it just states its conclusion several times in different ways. Even if you agree, why would you upvote this?
• anon
  undefined
• Menu

  videotextly
  The part of Brooks that still holds for me as a solo developer is that the cost sits in coordination and understanding, not typing. AI makes producing code cheaper, but reviewing it, keeping the design coherent, and remembering why things were done still takes the same attention. I have found small, well-bounded tasks with tests work well, while open-ended changes across many files create review work that cancels the speedup. So the useful question is how much of a change I can verify quickly.
• asafel
  [flagged]
• maxkaya
  [flagged]
• aaron695
  [dead]