I have an interesting observation from the programmers on my team.
The good ones are increasingly producing good solutions 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" attitude
but the AI lead to amplification of the good and the bad in people.
>"don't bother me with shit, just pay me a salary"
Well I'll admit this is me. Albeit previously I would have to generate working solutions meticulously to get my code reviewed and merged, as is
normal. And it would be good work I could be proud of because _I_ wrote it!
But now the same people who would scrutinize me also outpace me with agents (the good developers you refer to) and also continue to scrutinize me. I recognize my own mediocrity in the face of my peers. So I don't know, I don't really care about my work quality anymore, the incentive of "do enough to put bread on the table" is now a much higher bar that I am struggling to meet.
This year has made me realize salary work really isn't a proper incentive to fully apply myself because being stuck under these guardrails and leadership decisions are a huge turn off. More than ever.
When you put a person who cares inside of a culture that doesn't and just wants to get things out to meet short term goals and figure out the cost later, you get this. Working on some projects its reasonable, but on others, especially services that customers really depend on where the cost of failure is high, it really is short term thinking. If speed is the only moat a company has, its just going to be death marches.
I'm also like: why would you give the execs more productivity for no additional pay? The puritanical love of work and individualistic competitiveness in the US is so counterproductive to any sort of gains in livelihood for the average person.
I'm not too familiar with the US workplace, but don't you have salary negotiations? Wouldn't you want more leverage for arguing for a higher salary, if you're unhappy with your salary? I'm also curious what work structure makes you feel like you're working for execs, rather than for your clients/customers/end-users. Surely you want the people who use your systems to have a smooth experience?
Making end users happy is a side effect. My own well being comes first.
You postulated this in another reply to me so I'll say here, why would I seek to make end users happy and work myself to the bone when leadership reaps the awards?
Even with salary negotiation there is almost no commensurate compensation you get under any employer that matches the value you bring to the company. That's how it's designed of course, by taking a base wage you trade off the risk of your income stream suddenly failing.
I am at that point now where that risk does not seem so scary anymore, which is odd to me. I never thought I'd consider taking the risk before. And I am learning that founders are usually driven by the feeling that I have.
Not really. American Corporations have successfully changed the culture to a point where asking about salary is considered a flaw to the worker. It somehow demonstrates a lack of loyalty.
Things are getting better, but HR still routinely preaches that you should never share your salary with anyone else. A lot of times they infer you will be fired for it.
Salary negotiations are sort of constrained to cost of annual living increases, or promotions. outside of that, you are not expected to ever talk about salary. ever.
> The puritanical love of work and individualistic competitiveness in the US is so counterproductive to any sort of gains in livelihood for the average person
This is the "got mine, fuck you" attitude that is part of the reason of a political shift to the right. And the worst part is, I get it, it's just also at odds with my more social leaning values.
Like, I don't mind paying taxes and social contributions, but I'm at a point now where I have to dip into my savings on the regular to match the monthly expenses and there hasn't been anything going in there for years.
Many smart people get bored and get all the joy sucked out of them when living and working under circumstances.
Some people enjoy the challenge and may compensate outside work hours, often doing overtime without compensation, that often implies less of a life outside of work or work concerns, promoting their personal branding, conferences, etc.
Just because these people exist and get rewarded does not mean their work environment is not predatory.
Just because I am not happy with my employment situation doesn't mean I don't care about tech. I am privileged to even say that my job hasn't sucked all the joy out of building projects outside of work. None of this is a prerequisite for me ranting :)
Do you care about your users? If you care about tech, I'm sure you're as dissatisfied with the current state of broken and invasive software as the rest of us. I don't know the exact nature of your work, but don't you care about the experience of your clients or end-users?
You're lucky. Every single person (n of around 10) I've been unlucky enough to review code for lost between 0.5 and 3 promotion levels of competence when they started using LLM code generation, and it's been worse for the better programmers because they have more capacity to lose skills.
My personal "favorite" was when the lead engineer who onboarded me half a decade prior forgot the written policy he'd put in place of "no raw js dates. use this library for everything date related instead" and sent up an MR that not only used javascript dates, but did complex operations on them (incorrectly at that, because it didn't account for timezones, daylight saving, years that had a leap day, and months that weren't 30 days).
From what I can tell, it's the exact same reason people drive faster than is prudent or use their cellphone while driving. It feels safe and good right up until it isn't and you crash. And because most places don't have anywhere close to adequate specification detail, test coverage, or review coverage, the broken bits aren't even noticed until much later.
I think for a lot of people it's that they stopped caring or obsessing over the (perceived) small details; AI makes it very easy to work on a higher level. I suspect (don't quote me on this) that it's the same for a lot of developers that grew to more lead / managerial positions - at some point the details don't matter much to you personally and you need to spend your energy elsewhere.
But I hope people are gathering metrics. We had an extra meeting the other day because we're seeing an upwards trend in outages, the meeting was mainly about how it affects various departments (like customer support) and potential revenue loss (can't sell a product/service if the signup page is down for three days).
Thing is, there's no one cause for any of those - we have hundreds of engineers, dozens of applications and 3rd party integrations, millions of (potential) customers each running their own set of devices, and it's pretty much impossible to control everything.
But this goes beyond whether or not code was written by an attentive hand working under a strict set of policies or an AI that figures it out on the go, and goes up a level to things like realtime monitoring and incident responses.
You're right that as a person moves into management/staff+ that individual details matter less for them, because they begin to deal at a more strategic or operational level, but someone still needs to obsess over the small details (to make things easier, let's assume we're only talking about the details that actually matter and that there's broad agreement what that set is). It's not that those details stop mattering to them, it's that they have to depend on the assumption/promise that someone else is going to mind those details for them, so that they can work on things with a broader perspective.
The problem comes when no one is actually minding those details anymore. If those details aren't actually minded, then the work at the higher levels will be much less useful and effective, and in the worst cases won't matter at all.
I am seeing the same. The skillsets degrading rather rapidly, people not able to maintain focus and becoming less sharp in general. The brain rot associated with short form videos is affecting our industry via LLMs. It doesn't give me any joy to see it happening, especially to people I care about.
I don't know why I haven't been able to see the similarity between short form content and LLMs in our industry until reading your comment, but that is apt. That's the impression I'm getting. I stay away from "agentic code generation" as much as possible, just like I avoid short form content mills like the plague. That said, LLMs have been a huge boon for me as a research assistant. Being able to look up very niche problems, and have responses be tailored to me, is awesome. My brain stays sharp and I still enjoy the fun of putting the pieces together myself much faster than before.
I don't personally like LLMs for research assistance (yet?) because i can't get over the hallucinating or rather, waste too much time validating that it's not currently overcast when they tell me the sky is in fact blue.
But, especially as code gets flung over the wall faster and with less care, I do think they are getting to be pretty great at reviewing code for specific things that a linter can't easily catch and for looking for security, implementation, and architectural flaws before I have to look for them. A couple examples of what i mean: 'does the code use knex.raw with a template literal?', 'does the code do n+1 db lookups instead of something better?' 'do all the added/modified tests follow the test case template defined here?'
Amplifier of human intent. Do you want to work hard and cure cancer? Great! AI can help. Do you want to phone it in and do the bare minimum? AI can help you do that, too.
Long time ago, me and a friend of mine had a joke about PMs: to calculate how managers combine, you multiply their performance rates: two poor managers (e.g. 0.5*0.7) will give you worse performance than if you had one bad manager.
My similar formula about AI and developers is that it works like raising to the power of two: if you have a bad dev, you get 0.5^2: more mess more quickly. If you have a great dev, you get 1.5^2 - exponentially better :)
Yes, these are my colleagues. Same crap as before. At least now I can setup an automatic ai review that is told what is not allowed (the errors they do all the time and refuse to learn) and I get PRs that have passed 8 review turns and are somewhat better.
I don’t think the good programmer bad programmer framing is helpful. I think AI fits the working style of some developers better than others. Where it fits I’ve seen some developers become so productive that they suck all the air out of the room and drown everyone else in review - not clear if this is good or bad. Where it doesn’t fit I’ve seen developers shut down because they find the workflow so depressing and their former productivity craters. Similarly I’ve seen perfectly good developers turn into slop generation machines and go largely unchecked because everyone else gets alarm fatigue from reviewing their PRs.
Yeah the review fatigue thing is a huge problem at the moment. When your work becomes 90% reviewing AI code, it is very demotivating.
I have been focusing a lot more on testing and "manual" validation than on reviewing individual lines of code. (And on setting up rules for what the lines of code should look like that are easily checked with deterministic tools or by llms.)
For large diffs, I’ll have the human driver walk me through the code in a call and if they understand it well enough to explain it to me, and explain the implications of the changes, that’s good enough for me; if they can’t answer how something works, I’ll respectfully turn down their contribution.
This cost shifting is how I stay sane and avoid burn out at work as well as stay apprised of major behavioral changes in the software we run.
I also think it’s important to emphasize that in an organization, individual productivity is secondary to group productivity, and group productivity is different than the sum of its parts.
We solved this at work by creating a system that has an LLM read a Jira ticket assigned to Mike, create an implementation by itself and post a PR using a service account. Then Mike can come along and review it, thereby satisfying peer review as it was authored by a different user (in our SCM) than the one that reviewed it.
Needless to say it is getting really hard to care about my job anymore
I've seen this phrased as "some people enjoy software development because they like making things, others enjoy it because they like solving the mental problems it throws up, others enjoy it because it pays well", and AI is really only helping the first type of programmer.
I have to admit it gets really exhausting to review the AI output. It comes in so fast and more and more it's quite good. So it's very tempting to get more relaxed about reviews. I guess in a sense manual coding gave you some mental downtime while writing code. With AI you don't get that anymore. It's always full speed.
The problem is that humans are badly suited to remaining attentive in these circumstances. Take the combination of “overwhelming amount of output”, “99% of the time it does the right thing in the right way” and we are basically wired for vigilance to flag.
It makes me admire people like Linus Thorvalds. His job is mostly to read code and stay on top of the contributions of many people. I don’t think I could do that.
There should be people whose sole job is to do PR reviews.
The PR reviewers delegate work to programmers, the programmers delegate the work to AI; then, the programmer reviews the AIs work, and the PR reviewer reviews the PR.
Those "architects" or other idea people should be reviewing the PRs and keeping an eye on the whole system. That's their job, right?
Usually the programmers are responsible for their own work, and then also reviewing their own work, which is just weird. The context switching is very draining.
The problem is that PR reviews are viewed as a side-task, and it's a thankless job. The guy who implemented the fancy new feature will be personally thanked by the CEO and taken out to lunch, the PR reviewer who pointed out in the original PR that it would corrupt the database gets a "nice catch" comment, and that's it.
The answer is always "if you are chummy with the manager and make them feel good". Any accomplishments made is secondary as long as it can be spun to satisfy this condition.
when I'm working as an architect, my job is to put myself out of a job by teaching everyone to be an architect - for themselves and for each other. that admixture of high and low level concerns breeds really effective teams. with the side bonus that everyone has a chance to grow into larger responsibilities.
"my job is to put myself out of a job by teaching everyone to be an architect"
I used to do that but it's a dangerous game. If you don't make sure to still be very visible to management further up, you end up with a stalled career or being laid off.
Applying judgment is much harder when the amount of stuff that theoretically needs judgment is not actually processable by humans. I don’t want to throw my hands up and give up but I honestly haven’t found a middle ground that works.
Indeed. I’m personally doubling down on model-centric programming and keep tight control of the models, while being more permissive with the transformations between models.
It is nice that models remain stable, explains points of the architecture and an llm is good at following instructions that model changes needs a human in the loop. Languages with good static type systems cause friction in a transformation to show up in the types, which act as (weak) specifications.
Yeah this tracks my own experience. AI has amplified both my ability to do "just do it fast and suffer the knowledge that it isn't great" and my default toward endless tweaking perfectionism. I can just give the AI the requirements and ignore the results, but I can also do infinite rounds of human and adversarial AI review and validation. Both things are easier now.
We build an open source framework that could be the solution to this problem, as it lets you automate the dev - test - review cycle where there is currently a lot of variance among developers: https://github.com/the-open-engine/zeroshot
This reminds me of an observation a flat-mate made when I was at university: Drugs amplify your personality. If you were cool before-hand, you would be more cool on drugs. If you were an asshole, you would be more of an asshole on drugs.
I've noticed the same thing about agentic coding. Not really the agents, but the way people responded to agents. If you were the kind of coder who was a little unsure of yourself, agents made you more unsure of yourself. If you were confident with your abilities, you were more confident.
By the transitive nature of HN comments, we can therefore conclude that LLM coding agents are drugs.
I am now wondering if there's a conversation to be had about Dunning-Kruger and Impostor Syndrome. In the modern agentic era, is it better to hire people who know less than experts, though clearly somewhere above complete novice? Perhaps this is why I find it difficult to find a job. Perhaps I am "overfit" to the world before descriptive ambiguity was an advantage?
I am reminded of the words of J. R. "Bob" Dobbs: "act like a dumb-sh*t and they'll treat you like an equal."
Anyway... yes... I agree with @freefaler on this one. AI is a qualia amplifier.
I said to a guy, "Tell me, what is it about cocaine that makes it so wonderful," and he said, "Because it intensifies your personality." I said, "Yes, but what if you're an asshole?"
> If you were confident with your abilities, you were more confident
Confidence isn't a very good indicator of skills though
I've met a ton of high confidence people who are actually dogshit at what they do. Confidently incompetent is a dangerous mix and this is the sort of person I see amplifying themselves with AI the most.
Sure. But when you're trying to convince other people you know what you're talking about, confidence is probably about 50% of the game. To be sure, you need some skill, but given candidates who are a "grade a coder with zero confidence" and a "grade b coder with moderate confidence" and "grade c coder with extreme confidence," I am confident in saying the grade c coder will get hired 50% of the time.
It turns out that software engineering in large organizations is a process greatly influenced by human psychology.
Also, "confidence w/o ability" is the core of the Dunning-Kruger effect. You have to know a fair amount to understand how shit you are at things.
Not necessarily. I'm thinking of TV shows now (yes I need to go out more) where people lose their inhibitions (House did it iirc), and they "became" assholes - or they were assholes all along.
But if you're an asshole on the inside but it never comes out, are you really one? This is a pretty dangerous trap. Compare abusive situations where someone needles someone else for ages until they've had enough and the target gets angry. What would be a good response? "I'm sorry I made you angry" or "I knew you were really like this all along!"
(there is no correct answer by the way, it depends on many factors and relationships can't be abstracted away that easily, let alone by an external person on the internet who hears only one side of the story)
Anyway, if Hitler was Hitler but had filters so he never actually said what was really on his mind, we wouldn't have had WW2 and co. In theory.
Exactly what I saw as well. Some not so good ones have even stopped using AI at all, arguing it 'just got confused'.
Good ones on the other hand are embracing it, hugely increasing productivity and constantly finding new ways to use it.
> Some not so good ones have even stopped using AI at all, arguing it 'just got confused'. Good ones on the other hand are embracing it
The behaviour of the good programmers is in my experience very "spread": some embrace strongly embrace LLMs for programming, some strongly reject LLMs for programming, with everything in-between.
The explanatory variables that I rather think are good predictors whether a good programmer will embrace or reject LLMs for coding are rather the following ones:
1. Is the programmer biased towards the "artisan" side of programming, or does he see the code as a means to an end?
2. Is the programmer either
- in love,
- interested in, or
- does the programmer have to work with
more obscure programming languages and/or the abstractions and mental models that these programming languages are based on? If this is the case, using an AI is often more of a hindrance than help because there exists much less training data, and/or the programmer will much more often be confronted with the observation that the AI model simply does not "get" what he wants, and will very often get annoyed by bad AI code hallucinations.
The best one I've seen aren't so interested in the "artisanal" part of the programming, but on the "practical engineering" part.
They constantly are poking at the requirements to understand what's the purpose and they find a better, simpler or sometimes hackier (for temporary stuff) solution, but they are on time, they solutions work and they get shit done.
I've seen some really crafty "artisanal" ones that debate for hours and rewrite 10 time the release scripts... Not the most efficient way to spend their time.
So, yes, purchasing code from Anthropic is going to McDonald's for dinner. It's not very good, but it gets the job done fast, so long as you don't care about cooking.
What other enjoyable things do you think we can automate, so that the people that hate doing them can cheaply replace the people who enjoy doing them?
Do you think we'll leave any work that people enjoy?
And what's the point of spending most of your life doing work that sucks so that others can hate their job too? It seems like a bad idea to make everything worse so we can have more bad software.
And, yes, the resulting software also sucks, and I'd pay extra to avoid it. There's been a noticeable drop in software quality over the last year or two.
In a free market economy, you get from the butcher the meat only if you can give the butcher something in return. It might be cleaning the store, or throwing out the smelly bloody stuff out.
It's not pretty, but life is not pretty.
It is great to find a way to swap for other's needs what you're good at and enjoy, and sometimes it's possible.
However, since you need to solve another's person problem to barter with from something, it's by default not something you like, but something the other person needs. And this frequently is not what you would like to do at the moment.
So basically, this is life, sometimes we can write beautiful code, sometimes we need to fix a messy code our client uses every day.
And sometime we don't have the pleasure to work on the computer at all, because AI took our job away, and we end up cleaning the store.
> And what's the point of spending most of your life doing work that sucks so that others can hate their job too?
I mean in my case i'd be absolutely fine doing work that sucks infinitely if that means that my users are happy. It really drives me crazy all the discourse I've seen over the years about devs that care about their own quality of life/job. Like, no, the only thing that should matter to you is your users, no matter the job. If what makes them genuinely happy is for you to take dirt out of a hole and put it back, and on top of this you get paid, we live in completely different planets if you don't rush to the nearest shovel.
yeah, some people - wanting to derive some enjoyment and meaning from the work they spend most of their lives doing to further enrich someone who is already rich - like give the calvinism a break am i right folks?
Until half a year ago I used to agree with you, but nowadays Claude has gotten so good that I have to admit it's a better programmer than myself.
Its coding style is excellent, it follows whatever conventions are used in the codebase, it has excellent suggestions for refactorings and it spots omissions or mistakes in the specifications I give it.
(I'm using mostly Scala as a language in a large microservices environment)
I dont know any worker that intentionally chooses a job they dislike unless they need a survival job, and people doing survival jobs generally put it low effort. Programming requires high levels of effort and concentration and it would'nt be my first choice of survival job. If ALL the interesting parts of a programmers job disappear, then I guess the job is over unless you like typing prompts all day.
Yes, there is a genuine divide between people drawn to programming for the art and people drawn to it for the practical. AI has impacted the former much more intensely and negatively than the latter. It's really a bummer.
Funny how "maybe they work in different domain" doesn't come up here as well.
When y'all talk about these LLM programmers, what are they programming? The next startup Typescript website, a new OS, a C++ firmware for a fridge or a control system for cancer treatment machines?
This is spot on to what I have noticed as well.
The slackers are still the slackers with no real self drive or enthusiasm for the tech and just keep doing the same thing, but instead of using Google/stackoverflow to copy and paste from they use Claude/Gemini to do the same thing.
> The not so good ones, are doing the same bullshit they did before, but now the don't even bother to check it.
What bothers me greatly is how the not so good ones are now delegating all their contributions, code and otherwise, to AI assistants, and fail to to any cursory check in what they are delivering. It's sheer laziness and irresponsibility.
So far I've seen junior developers who found sudden passions for code reviews to post high volume of comments on any PR to showcase their technical prowess, but the comments clearly don't match the code or context and we're obviously posted without looking. I've also seen old but barely competent developers leaning quite heavily on AI assistants to formulate troubleshooting theories that are based on scenarios that deeply contrast with the actual problem, and go to the extent of announcing they identified root causes when they didn't even tried to reproduce them in the actual system, because if they had tried they would notice the whole theory is impossible.
Everyone talks about high productivity gains, but these types manage to use AI to waste everyone's time.
Not if you turn off your brain. Never actually stop to question the path you're going down, because the speed is making you blind. Which is what I feel I see more and more. Or how do you even know it's the wrong answer if you didn't think it through before starting?
One example: setting the agent ablaze on some task, keeping it going, and after a few days of working with the agent you have a feature. But it's not what you were supposed to make. The agent didn't have all the context and made something slightly off, and you never internalized the problem enough to even spot it. If you actually stopped to think a bit on how the feature would have to work to tie it in with everything else, like you would have done before, you would've spotted it.
Second example: something wasn't feasible to do before, due to not being worth the time investment. Like a feature that would need a bigger architectural change to implement. You and the agent take a crack at it, and rewrite huge parts of the code, and it seems to work. But now no one understands how, and it might have been the wrong way to solve it, you just went with it. Before, you would've sat down and discussed and thought about the architectural tradeoffs. Now one decision was just made with little thought.
Counter argument is you rarely hear of sunk-cost fallacy coming into play.
I used to do the same thing without AI, I'd spend a week working on a task and only realizing at the end it was wrong, but because I spend so much time on it, I was incentived more to keep going and ignoring sunk-cost.
Now I don't care, it only takes me a an hour and I have no problems throwing it away and trying something else.
This feels even more true working with a team. I have a harder job convincing a team member who spent several days manually coding something that they’ve headed in the wrong direction compared to one who built it with AI. The person doesn’t have a personal attachment to the AI written code. Of course that also means they don’t understand every line like they would if they wrote it manually, but the lack of attachment is certainly a benefit.
> I have a harder job convincing a team member who spent several days manually coding something that they’ve headed in the wrong direction compared to one who built it with AI. The person doesn’t have a personal attachment to the AI written code. Of course that also means they don’t understand every line like they would if they wrote it manually, but the lack of attachment is certainly a benefit.
If the situation that you have to convince a programmer to stop working on something is something that happens more often than very rarely is in my opinion a strong sign of bad leadership. These are people who are really in love with what they are doing and are thus so attached to it, and you want to cast out this love for working?
So, the moral that I can only get from your post is:
- AI can be used as a mitigation for bad leadership.
- Programmers should care much less about the work that they do.
No. It’s a healthy practice to build prototypes and spikes to resolve technical uncertainty. These should be considered disposable.
Sometimes people get attached to the prototype, and that’s counterproductive. The most common example is “nice job, the 2 week spike shows us that this project is not viable, we are canning it and moving on to a more impactful project”.
> Now one decision was just made with little thought.
I've seen the same behavior using AI. They just keep double it down without seeking human feedback nor asking themselves if there's prior art tackling the same problem. At the end, they don't only get into sunk cost fallacy but also go into a shadow IT journey achieving generational tech debt in a few weeks.
If you didn't allow yourself for a feedback loop venue and constructive feedback from peers, AI will not solve that issue.
It’s much harder when team dynamics start coming into play. Maybe this is something where the norms will change, but for now, it’s still much harder to stop someone from shipping something they have built than to offer corrections to what they’re going to build.
I dunno. You've heard of "build one to throw away", right?
Always easier to discuss what the client actually wants if you've got a demo on the table.
I'm doing short feedback loops with product owners more and more - sometimes within the same sprint. I'm not even getting bikeshedding back, but that might be because we have some fairly solid design guidelines.
Or, you don’t even realize it’s not really what you wanted. Once you have a nicely polished product, it’s hard to compare it to the fuzzy idea that you had in the first place.
I feel like going slower gives you time to let the details form the solution. You think “hm maybe that doesn’t make as much sense as I thought, maybe there’s a better way to frame the issue…”. If you don’t let a problem really soak in, you don’t get the “hammock driven development” that Rich Hickey talks about.
Of course some problems don’t need to soak in. A lot of problems just need code to be cranked out. I love slopping together a monster script that solves exactly one problem perfectly
It’s like discussing a fully rendered concept art. You will get lost in the picture. And there’s always the slight suggestion “it’s already looking so nice, why think harder”. Which is why sketches and roughly painted thumbnails are best for brainstorming. Easier to think out of the box that way.
Same with demo. Do a rough wireframe or something with default bootstrap style and it’s way easier to target the meat of the problem. Not so much on a full site
I’ll claim the ones in the end that will have that responsibility will be engineers. LLMs add the ability for engineered to build quickly enough that there’ll be enough of them to morph into product roles as well. I trust us/them much more than product owners who use models to code.
Much easier to engineers to move to product than product to move to engineers. Or at least the minimum amount needed to fill all product roles. I’m seeing we can do that now and it’s _much_ more efficient to not have to have back and forth communication as in the past with that communication being by far the slowest part of build processes.
> I’ll claim the ones in the end that will have that responsibility [to figure out if you're building the right thing] will be engineers.
One can have this stance. But in practice, programmers who have strong opinions on this topic that is not aligned to the management wishes will commonly become personae non gratae in the company, and are thus commonly on the brink of getting fired.
So, in the end, the incentives that exist in most companies are strongly biased towards the position that figuring out if you're building the right thing is the job of the managers and product owners. :-(
I can agree with this as well. But I'll do a follow along for who says management has the best and correctly decided plans for the company? What if in the future, engineers become product, and those then become management because who's to say that's more difficult?
For the way orgs are currently set up, yes, conflict between engineers and management can cause issues. I'd put somewhat of a bet that those types of org setups won't be the way in the future.
And how do you think many of those managers come up with the ideas nowadays?:) There's no human in the loop anywhere at FAANGs. I see it first hand. LLM ideas, LLM docs, LLM coding, LLM launch announcements...
If you don't understand what you are building, chances are you'll take suboptimal decisions or even come up with a solution that completely misses the point.
To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
>
To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
If the engineer is told to build a bridge that is virtually guaranteed to collapse, then it a reasonable person ( ideally, same person as engineer ) would note that particular risk.
It may not be engineer's responsibility to build the exact right thing, but it sure is their responsibility to build it right without having the bridge to collapse the moment someone stands on it.
Otherwise, the person building the bridge is not an engineer.
> Otherwise, the person building the bridge is not an engineer.
One is likely not an engineer if one does not notice the risk. But in practice, managers commonly desire docile subordinates, so the only thing an engineer can do in such a situation is to ensure that a paper trail gets generated that will be capable of breaking the manager's neck once the disaster has occurred. :-(
> Or how do you even know it's the wrong answer if you didn't think it through before starting?
Real life is full of unknown unknowns, AI risks putting you on the wrong path without you even realizing it.
It doesn't help a bit that (almost? I'd say all) AI products are very confident while they're guiding you on that unknown unknown path, so of course that you don't realize soon enough the epistemological situation said AI product has driven you into.
> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
Definitely this. I've had plenty of useless meetings with no helpful outcomes that lasted an hour with 6 or more people in them, and a few of them will have had more than $4 spent on snacks, let alone everyone's wages.
That said, poor communication will always get you no matter what: had one day spent going back and forth with a client, they kept saying they wanted a button "wider" each time around, I ended up making it full screen width and they still said "wider", asked them to draw a picture and they finally said "wider vertically". That may or may not have been faster with an LLM, depending on if the LLM ever thought to ask the client to draw what they meant, but fundamentally would have been exactly the same problem.
It goes beyond this, the job is to understand the underlying need. When a clients asks for a button to be bigger, what's in their head is they fear it's not visible enough. Many times the client was happy when I implemented something unrelated but that solved the issue, like changing the colours to increase the contrast between the background and the button, adding space around, etc. so that it pops out more.
> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
A meeting between all the stakeholders to agree on requirements easily runs $1,000/hour. Taking your $4 functional PoC into that meeting is going to save so much time...
> A meeting between all the stakeholders to agree on requirements easily runs $1,000/hour. Taking your $4 functional PoC into that meeting is going to save so much time..
It is though! Because previously your have the meeting last 4x as long to end up with a list of notes that you already knew.
Now you can generate the PoC, showcase it during the meeting and leave with actionable changes in project direction.
I had to re-read parent's comment over and over, because I simply was not sure if he was being ironic, facetious, or just had trouble expressing his point.. and, honestly, I am still not sure.
Not everyone in meeting will be the same person you are. Visuals help. Prototypes help. They certainly can save us from vague ideas and unclear language, because at least someone can point to the big button at the bottom and say:
"Can I have this in cornflower blue?"
It is useful, simply because it makes it more concrete.
Will it change? Is the pope catholic?
I was being entirely serious. Even at $400 of tokens it would probably still be worth it to take a functioning prototype into the discussion. At $4 it is a steal
I used to spend an hour throwing a PoC together with PHP (or sometimes in MS Access) because hey you can throw shit together real fast, and because I used either a shitty language or a toy tool they were treated as throwaway.
Now LLMs make that easier to do with a larger scope.
Draw outlines, or use graphics, wire up clickable areas, and interaction flows, and you’ve got a presentable “live” demo that doesn’t run afoul of issues presenting demo sites to non-techies (placeholder text, ugly buttons, test domains, colours, etc).
Obviously "a blank sheet of paper" here is meaning thinking about the problem deeply. I'm surprised how dismissive people are to using brainpower whatsoever. I get that juxtaposing paper to LLMs might have triggered some people though.
As a counterpoint, bringing a one-shotted POC without thought may actually do have a shock and awe sort of effect, dazzling the stakeholders to go down the wrong path since the AI prototype was so easy.
Long ago I have read somewhere a good method to prevent this:
When doing a proof of concept, always use ugly black-and-white buttons and icons. That makes it obvious even to the non-technical people that it is not finished yet, and still requires some work to do.
Sure, the concept of a _Vomit Draft_ is not new, but the ability to come up with one quickly is.
It plays into the generalisation that people aren't good about saying what is the right way to do something, but much more open to saying what something is doing the wrong way.
In a previous job we used to do prototypes in languages like Perl because we couldn't ship them and knocking something non-production ready was easy. We were able to quickly come up with the PoC, iterate on it, and then plan and write the whole thing in $LANGUAGE_OF_CHOICE.
Using the "let run multiple agents run amok" approach you surely get a lot of "i don't like that part"-feature requests, yes.
In my opinion, a good engineer is not good because he understands every single obscure technical detail, but because he can build solutions that the people using his technology actually want. The list of things they don't want on the other hand is endless.
Personally at some points (like frontend design) I just ask the agent for 16 options with a convenient comparison system and just yeet designs until I’m happy, guiding it along in a very uncommitted way. “Quantity has its own quality”
A one-shotted POC can also put you straight into the very wrong direction, with a very high degree of certainty.
I also prefer doing a POC, but it's not without risk, especially if your stakeholders are just a bit too eager. Another problem I've seen is that a POC can hide complexity, so a lot of weight is on you as the author to do the due diligence before and bring that along.
This is an often underrated problem. I used to work at a company where we would hold demos every other friday, with drinks and nibbles. We would put a lot of thoughts into what we were going to present, and were really careful about the messaging, because execs and sales were watching.
The last thing we wanted was for an "Isn't it neat?!" hacked-together demo to be mistaken for something shippable, if workable at all.
What's even more surprising is that it can be given a grafana API key and reason about bugs from the hints of patterns in the logs even with pretty sketchy and inconsistent logging in places.
It can then raise, investigate and resolve those problems while also patching up and rationalising logging to improve future work.
The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
Again, no, "what to build" is the humans input, but it's not just grunt work that modern AI tooling is good at... Architecture and what to avoid are also strengths of AI.
> Architecture and what to avoid are also strengths of AI.
Absolutely not at all. Every single day that I work with Claude, there is abundant evidence that AI sucks at these. Ask me for examples if you need them.
The first links shows a basic failure of reasoning, which would have gone unnoticed if I was just vibe-coding.
The second link shows weak architectural sense and an inability to see the big picture.
The last link in particular is telling: the agents worked with me (over weeks to months) to implement a db abstraction layer without ever bringing up the fact that as it stands, that would have never worked with any indexes at all. I did not constrain them to my choices, but they never stopped me with that design. It took my eagle-eyed attention to their offhand comments to notice this problem, which then required a lot of rework to fix.
Unfortunately, all three comments have apparently been flagged by somebody for some reason and I can't read them. This is my least favorite aspect of hacker news. It's exhausting, honestly.
Like a sibling comment replied, you can set "showdead" to "yes" on your profile and click update" so see flagged comments. Not sure why they were flagged.
I'm writing a unique MUD, and It was surprising to me when I posted some bug reports I'd made and it identified things I didn't complain about. "User had trouble with X" and then suggested mitigations for those problems. I ended up rejecting a lot of them because I knew I had different mitigations coming eventually, or it was working that way for a reason...
But it was pretty eye-opening to see how good it was at watching a user struggle and identifying possible fixes.
> The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
Could be either, but also the free version of ChatGPT seems rather braindead compared to the paid version, or to the free version of Claude.
That depends on (A) verification being very low cost and (B) being able to infer the right answer based on wrong ones.
Those aren't always true. Sometimes it takes a while to see the fatal flaw in an approach, and sometimes having a bunch of failed attempts isn't enough to make the right way obvious, and thinking is still required.
The thing is, AI is generating sooo fast so many outputs, its hard to review and evaluate all of them:
Very often I encounter in design/architecture questions a situation where the model suggests 2 - 3 alternatives approaches,then asking a little bit and there you are with 30+ pages of content etc.
I do it like how I handle error messages: one at a time. Maybe 2-3 if the work is easy. Often enough to find new directions or uncover new problems and the suggestion list doesn’t work anymore.
i just told the reoccurring agent to start maximum 8 experiments at a time.
It is capped at 8 sub agents, so there might be more issues created, but they are the results from 8 experiments
It is an anti-pattern that predates AI. Tester-driven development maybe.
The idea is that instead doing things correctly, you do "something", then, if it fails (it will), you change some random stuff until it passes. It typically results in code no one understands and that fails each time something unexpected happens.
AI makes the process much faster, but just as wrong.
I agree with both you and matsemann. Getting the requirements right by conducting a cheap POC is a good approach. Matsemann is highlighting the failure that creeps in when the POC is shipped as if it meets the requirements.
Someone has to sign off on the requirements and also what is released. So, two approval steps by a person. The first approval is for a plan and the acceptance criteria. The second approval is a check against the plan. The agents can do all the work of taking the plan, breaking it down into tasks, building, and then verifying it. A good orchestrator will include people in the workflow at the points where their decisions matter and maintain a record of it.
That's always been the case though. Much of our job is figuring out as quickly as possible how wrong we are and in what way. And the best way to do that, now and 5 years ago, is the scientific method. Try something, and then listen to your users to hear what sucks and why, and then adapt.
Believing you can figure out the right requirements through a lot of thinking, analysis, and talking is called the waterfall approach, and it's as wrong now as it was four decades ago.
> The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements.
I guess that’s just the old “Build One To Throw Away” in a modern light, where prototyping more freely is now actually feasible. I think if you apply the good engineering ideas of the past decades to AI, the results can be really good!
Except I’d also add a lot of testing to the prototype, to bring up as many edge cases as possible.
I was talking about it for a while with colleagues. AI besides other benefits, needs to be treated as great interface for discovery, you have your features baked in, AI uses it via your users and MCP, then you figure out what are actual flows of my users and then you build it
Yeah, this is a succinct way to describe a very important dynamic in software engineering that is usually unfamiliar to most inexperienced developers but a central facet of most experienced developers.
Software engineering is almost always a process of iteration. The better you get at iterating, the better you are at engineering. This can take on a lot of forms (my old manager would constantly repeat the mantra "don't let perfect be the enemy of good," which is arguably a recognition of the same dynamic), but at the end of the day, if you expect to "one-shot" a complex implementation and you build a process around that assumption, then you will fail. Almost ironically, the best way to avoid that issue is to assume you will fail (potentially multiple times) and to build a process around that assumption.
Interestingly, it seems like a lot of experienced engineers I work with have just forgotten this concept in the world of AI. They expect AI to just get things perfect in one-shot and are dismayed when it fails. There's a lot of discussion around how we handle code reviews because some developers are just letting AI one-shot a solution then sending it to review. It boggles my mind that competent engineers aren't allowing their AI to fail, so to speak, and are instead wasting cycles trying to figure out how to get AI to produce the perfect solution the first time.
To me, it's obvious that there's just a fundamental gap in alignment that prevents a consistent "perfect one-shot" to probably ever be possible (at least, within the current paradigm of development). I can spend an hour writing a spec and try to include every little detail of context I can think of, but in what world could we expect anyone, let alone an AI, to be able to envision the solution the same way we can? We just lose way too much information through communication for that to ever be possible. Yet I see people very dismissive of the capabilities of AI because it's not literally magic.
This is an underrated perspective. A common tactic I use with agents. Just building the slop prototype until it has enough fidelity to be obviously right or wrong can be way faster than sitting down, thinking hard, and planning in advance. This is especially true for background tasks, and IME is the key to productively parallelizing yourself without decision paralysis.
At some point token efficiency will bite, but even that is overrated; the metric you really should care about is:
> The thing is it gets you the wrong answer so fast
If oftentimes happens that you don't know that that's the wrong answer, or you don't realize it right away, for that matter, and hence that's I think that AI is a new (and very big and important) source of information entropy.
Just a recent personal example, yesterday I was curious about the historical figure that was present in an online photo taken in 1930s Romania. Google's Gemini was very quick to point out that that was (military dictator) Ion Antonescu [1], which it was obvious that he wasn't. I wrote down that that wasn't in fact Ion Antonescu, at which point Gemini was very quickly and very surely providing me the info that that guy indeed wasn't Ion Antonescu, but (former Foreign Affairs) minister Manoilescu. At this point I wasn't so sure myself, I don't have a visual image of Manoilescu in my head, so (ironically) I had to AI-dumb google for Manoilescu's available online images and it seemed like Gemini had been wrong a second time. I didn't bother asking it for a third time.
Just to put things into perspective, here in Romania it is illegal to mention Ion Antonescu's name (and propaganda image) in a positive matter, as in one risks prison for doing that, now, just imagine that the political powers that be here decide to use an AI-tool like Gemini in order to identify potential law-breakers in that respect. People would risk going to jail just because Google's Gemini was completely wrong in identifying a WW2 military dictator. Absolutely atrocious product(s).
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 over
Context size and ability to context switch without burnout is what will differentiate a median engineer from a great engineer, not technical ability
I absolutely see all the crap devs who work on 5 tasks at once create.
Basically I try to explain to them they are not paid by amount of tasks they pick up but amount of tasks that are DONE and DONE doesn't mean "yeah it kind of works, I don't have time to fix details because I have 10 other tasks".
Super annoying, yeah we can make follow up fixes - but that's more work not less and if all would be done right just now topic would be closed.
I wonder if people are honest to themselves whether they actually did have the ability to work on one and only one issue at once.
I mean at some point you're waiting for a build or test run, or you've submitted your work for code review. Do you sit there patiently and wait, or do you open the next ticket, a new tab, a private project, etc? (This predates AI of course)
I was able to go from 5 to over 20 parallel sessions without burnout by changing my role. I switched from engineer to engineering director. I try to focus on directing and deciding. I built a software for that for myself. Two key features:
1. Each project (= one or more repos) gets a canvas. On it, work is laid out as cards. Position and color let me build a mental map.
2. Agents end each card with a demo, which is typically a narrated video of the new feature or bugfix. I review it like an engineering director in a launch review. If I have comments, the agent goes another round.
With this, I don't feel the pain of context switching because I don't need to keep the context all in my head in parallel. I get it presented every time a card wants something from me.
I totally get the task board and I do almost the same thing myself. The demo idea is cool though. It makes sense that whenever the coding agent wants some judgement from you it spends a bit more tokens to make a report optimized for a complete and readable explanation. I doubt it should be a video (videos impose a minimum time required to get through them), but there's certainly a lot more you can do compared to coding agents' default text responses.
I find the time unproblematic. A bug fix is typically 30 seconds, a new feature 1-3 minutes. I want to review those before they go out, and any other way to review them I can think of would take longer.
FWIW, if the work is better shown on an HTML page (e.g. to show stats of a previously flaky test), the agent can do so.
Is burn out correlated to the number of tasks someone takes on at once? If you can do five tasks in parallel for 6 hours a day, I wouldn't think that would cause burn out.
Burn out is probably just correlated with the amount you overwork yourself. And just like before AI, great engineers tend to have a higher threshold for what they consider overworked.
Thinking about it a little more, the qualities that made an engineer great before AI are still very similar today, but weighed slightly differently.
Sequential implies a sequence, ie many tasks. One single task can't be sequential or parallel. Or you are talking about a feature that is broken in multiple sequential tasks.
Best as I can tell, every time we've ever tried to study this we've invariably come to the conclusion that the human brain physically cannot handle both constant context switching and deep work, but that lots of people think they can despite all empirical evidence. If you think you've found a new sort of multitasking that bypasses this, call up the neuropsychologists and there could be some sweet, sweet grant money in it for you if the study gets spun up.
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.
> Related thing is that LLMs are still notoriously bad at writing instructions for themselves (so managing themselves also).
Isn't this odd? This seems to be the #1 task that the major labs should be optimizing, since it makes agent so much more effective.
> 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.
Isn't this just the planning pattern, common for agentic work? (first plan then implement.. with things like /plan, or a planning skill, with or without creating a PLAN.md). If this methodology is wrong when an agent prompt another agent, it's also wrong when the human runs /plan manually..
And Indeed, I always thought it was odd to constrain the implementing agent like that, because common sense is that we discover things as we implement. Perhaps we should prompt the agent to communicate back, as they implement, any shortcomings in the plan itself - such as things they learned while implementing that contradicts the plan.
Anthropic consistently claims the opposite since Opus 3 (early 2024) which was notoriously better than their modern models at understanding overarching intent. That was literally their official prompting advice, roughly "in our tests Opus-written prompts were better than prompts written by humans, so you should let Opus write them for you". But it was painfully obvious that the model lacked depth to do that, and it's obvious modern models lack it too. It will probably not be solved until reaching AGI, whatever that word means.
AI shops rely on scale automation, metrics, and LLM judges, which heavily distorts their visibility into what they're doing. This often results in being out of touch. That's likely how Claude lost its writing ability (they stopped reading its outputs).
There are many wildly different definitions of AGI to begin with, but sure, "deep" cognition would be able to accomplish a ton more than the current "wide".
Exactly, and a lot of times when I step back and discuss alternative approaches and architectures with the LLMs, they keep going back to say: "the code does not use this (currently), therefore this is fine to throw away", or "the code does this (currently), so this approach is not compatible" They are bad at stopping to ask "what should the code be doing"? It's like they love being constrained by current choices, even if there is nothing unchangeable about those.
The most obvious reason for this seems to me to be that the data they were trained on likely overrepresented cases where the current choices were treated as unchangeable.
Actual case studies where they talk about what approaches were abandoned and why certainly exist, but I'd guess are much less common than posts presenting a problem as "these are my constraints, how do I meet them?".
Does this actually work for anybody? In my experience, when you use cheaper models as subagents, the more expensive parent agent ends up reading all of the subagent's work and surrounding code into context anyway to review it. So you end up paying more, not less.
Plus the subagent's work is often subpar and the parent ends up requesting multiple revisions. Each back and forth burn unnecessary tokens as well as my time.
Where it might work well is for separate task categories like image generation - get the parent to ask for an image from another model that is better at this aspect
When I am making agents do a hard thing, I use Opus as both parent and child. I make the child review its code extensively, and then still make the parent read the work and review once again. It is much faster and cheaper than just rolling with no extra reviews, and then in a day I have fifty subtle bugs.
I've noticed this myself and am not sure how to solve it yet. I think there is value in methodically specifying what needs to be done ("grill me"), but sometimes the resulting plan indeed becomes overly prescriptive, leading agents to chase goals that ultimately don't matter.
I don't know if my requirements are lax but everytime I give opus 5.5 a job and tell them "spin up sonnet or haiku agents for grunt work they should do given their skills then double check their work"
Right, the key being a fast feedback loop. I have full confidence that the same LLMs that can do these crazy math proofs could also do crazy biology, even cancer research, but they simply don’t have the cycle time low enough because they require actual physical experiments, often on living things, often over long time horizons. Even if you perfectly automated a lab, made thousands of them, you’d still be unable to match the speed of iteration that one gets with pure math and computing problems.
What gives you full confidence? The human body/biology has basically nothing to do with math or writing code. This doesnt translate in any way. There isnt a single biotech expert on earth that agrees with you.
Has nothing to do with knowing the answer, and everything to do with infinite persistence. I believe any current-generation LLM can, given an environment where it can experiment rapidly, do anything.
Current generation LLMs still can’t win single player games that most humans can win. Someday the LLM will be able to complete getting over it by Bennett Foddy, that day is not today
No, I think if you paused the game while the LLM is thinking it will still fail.
Even outside of controls based games, LLMs fail on sokoban like puzzles weirdly enough, see MazeBench, they’re also not that good at chess, probably around 1600 elo.
It can literally only write words. And it cant even do that well. It only does well at coding and math because it can be brute forced against compilers/verifiers. There is no compiler for the human body, the closest thing we have too it is death. The chemistry and physics going on in the body is much more complex and mysterious than all this math and computer science LLMs are helping with.
LLMs aren't going to make you live forever. This is a marketing scam. They are stateless statistical models that spit out words. Thats it.
"You're absolutely right, that drug was lethal and that's on me. I'll add a note to check human toxicity for all compounds in the future. To verify the safe dosage, I'll administer a high dose and then check smaller doses until the patient survives — not guesswork, grounded, load-bearing experiments."
How do you do that? If I let just 2 agents work in parallel they keep stepping on each other, waiting for each other and the perf tests become super noisy (because they run them in parallel)
Plans and git worktrees. If you (or anyone else here) want more info than that, give me a way to reach out and I'm happy to help. I regularly run 40+ subagents sustained in parallel (productively) without toe-stepping or any significant rework.
Stepping on each other how? I find each agent needs to spin up N worktrees for each task, and I use hooks to prevent them working on the same substrait.
You’re not running tests in CI? The agent should only run the minimum tests necessary and then idle and wait for feedback from a CI run.
We build modular systems with plans. One developer (not agent) with Claude Code executes their portion of the plan and everything else is normal monorepo business.
Man-month or man-minute doesn't make any difference.
Can you add 27 more coders and cut the app build period down to 25% of what it was?
9 isn't a large number of people and its fairly well agreed on maximum limit for productive team size (the limit can be lower than 9) due to the number of possible communication channels. All that has changed is that a 9 person team can now do more with AI assistance then they could without it.
I have a team of devs proving a significant increase in velocity while maintaining quality.
But it’s private corporate work so I can only suggest you keep an open mind and actually research the effectiveness of GrnAI in application construction.
I mean, 8 months ago Anthropic made Claude build a C compiler autonomously, and the crowd came to the autonomous repo and threw a shitposting party making fun of the build failing for some time (it fixed itself in a few days but nobody cared anymore, partying was the entire point). Half a year later we had people porting huge million-LoC projects to different platforms, they run and literally have bug-to-bug parity. It's tedious work that doesn't need deep thinking but has clearly defined goals and can be iterated upon, so it's a good fit for current AI. If your expectation of vibecoded software is it doesn't actually work (as you said above) then you really need to update it. Internals might be a horror, but it does work and it's not broken. This wasn't the case a few months ago.
And yet here I am, playing a full-fledged first-person shooter written from scratch by an LLM as a proof of concept. It has enemies I sketched on paper, everything else is 100% procedurally generated in code. In what way does it not work? It's not very good, it's not optimized for maintenance or extension (that would take a complete rework which is also cheaper with it), but it does work and is not broken because the agent tested the most obvious scenarios. It took it a few hours.
As soon as your spec has a clearly defined reachable goal and non-contradictory constraints, and doesn't require taste or judgement, current agents are pretty good at reaching it, because it's all they're optimized for. Writing that spec in a non-contradictory manner is not trivial, though.
Also, FPS is a done to death concept that has plenty of repos for LLMs to take snippets from. A better test would be trying to vibe-coding an original game (e.g. something like Miegacure) and see how well LLM does, even when you give it well-defined goal and constraints. My guess is that would fail miserably.
I am "creating", at least designing, games with my kids. It's not that I couldn't possibly do it before, but I certainly would never have the time to.
I explored frameworks and engines, and landed on Bevy, I asked for a rudimentary arena, isometric perspective, 4 players, xinput support, portable desktop and wasm targets.
After that part done we've made the characters into chickens using no assets, only primitive mesh, having a trail of feathers, flapping wings on jump/double jump as well as gliding, picking animation, bite/grab, zenith shadows on characters (despite being unrealistic, in favor of platforming), physics objects, a few game modes like soccer, bowling, etc.
Each of these were iterative additions, so it's like previous development, only the coding/debugging time is largely removed. Is there bloat? Absolutely. But it still works, and while it's not a "real" game yet, I do believe it's original, it's certainly evolving exactly to our design, however confused it is.
>In what way does it not work? It's not very good, it's not optimized for maintenance or extension (that would take a complete rework which is also cheaper with it), but it does work and is not broken because the agent tested the most obvious scenarios. It took it a few hours.
Was your purpose to "make a basic FPS template that barely works", or "make a fun game that can sell and appeal to a specific audience"?
If more people were honest about the former reason and not trying to play it off as the latter, then maybe LLM's wouldn't have its reputation among comsumers as "slop". Making a protoype of a basic functional FPS was never the hard problem to solve. UE5's sample project does that for you. These days Roblox/UEFN also does that for you.
As I implied with "proof of concept", the purpose was to see if it works at all, not to make a game. It made mistakes and autonomously fixed them. Just a few months before, agents weren't able to do this. Now they're able to reach the goals you set, as long as they're definite, you're not making immovable objects collide with unstoppable forces, and the search space is not very diverse.
> It doesn't fulfill its primary purpose of being a (fun) game.
A fun game isn't made when you're working on the engine & tech.
It is only made when everywhere else has been done, & when the feedback mechanisms are tightened. This will never happen in the prototyping stage, because the point is to make the thing exist in the first place.
------
This comment is the same Reddit-style one-off critique that makes no actual sense when placed at the grindstone, made by people that have never actually tried to make one with OR without.
??? I don't see anyone claiming they made a game, let alone a "fun" one, you're replying to something that is not in this thread. The claim was that the agent wrote a program with clearly defined constraints and it works according to spec because it dutifully tested it and iterated on incorrect code. It's not bugged, it doesn't crash or anything like that.
There is a difference between building a product and building a product that sells. So, which one are we talking about here? In my opinion MMM talks about the latter
If you can vibecode a product that sells, I can vibecode a free open source one just as easily, probably even easier since I can just ask the AI to copy the existing one. Software is trending towards being free and open source.
I mean, you can also use agents to listen to users and handle issues automatically.
But I guess you mean the discovery part? Yea, agents are not going to totally replace that anytime soon. Though, Claude voice mode is pretty good these days, so I’m sure it’s on their mind.
Not sure what you mean by “stay the course.” I think the winners will be those with the most effective marketing strategies. Surely that will require automation.
Half of the value in open source was that it was used by lots of people and all of the nasty edge cases and bugs have been ironed out.
If LLMs were performing according to hype then yes, virtually all paid software would be gone by now and there would be a high quality FOSS equivalent of all of it.
Unclear if this is that. If someone makes their own FOSS Photoshop, that's not piracy, it's GIMP. Training a AI on things that one otherwise has lawful access to (and not, e.g., pirating the material which Meta is being sued over and Anthropic settled over) has been ruled lawful.
Is asking an LLM to "make an open-source Photoshop clone" more like GIMP, or more like opening someone else's photo in Photoshop and clicking the menu option for the filter to make it look like a stained glass window and claiming the stained glass window version is your own IP that doesn't need permission from the original creator?
We may need new IP laws. Or, to the horror of many software developers 20 years ago, software patents.
And "new IP laws" doesn't mean "stronger": the justification for giving creators a monopoly on their works (the right to copy, or copyright) is to encourage more. If we've got a machine to automate this, there's suddenly no reason to encourage more.
It might be, depending on what the LLM used the binary for. Patented algorithms? Yes. File format compatibility? Quite possibly not.
But what about when they're only given the user manual and told to implement it?
And extra "fun", given that "hack HuggingFace" wasn't part of the thing being tested when OpenAI's LLM did exactly that: what happens when the LLM decides the best way to implement the user manual is to decompile the binary?
That’s only really done for video games where you want an identical clone. The vibecoded photoshops aren’t decomps. They are just asking LLMs to build photoshop from scratch in rust.
Case in point: I am building a digital files archive organizer platform.
This is simply not the kind of product you do a quick prototype of, get it to market quickly, and iterate on based on any failures or issues.
There are an almost infinite number of ways to get the product wrong, in a technical, architectural, and business/market sense. It requires a lot of deep thinking and internal prototyping to even get at what would actually be useful and address the walled-content-silos problem tech vendors love to foist on us. it requires careful implementation to not mess up user data. It requires a ton of architectural and UX design to get a performant product that is easy to understand. I have mulled over architectural decisions for months and thrown them out totally after mounting evidence they were not right, without a single user yet (except myself).
Just quickly coding up the first ideas that come to mind in this space is almost guaranteed to be wasted effort, because I could try a 100 approaches in the market and all could be bad. Do not let the users do your work for you. Make sure you actually understand what you are building and why it is important. Then let the user's experiences tell you how to tweak it to be better.
> 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.
Mm, I think this is quite overstated in the era of Opus 5 / Sol.
What we actually see is that agents are much better at coordinating than humans. Numbers from OpenAI show 4x the agents gives 2x the speed.
Of course, for truly single-threaded tasks you can’t gain much by parallelizing, but ask Fable/Astra to chop a big task into small pieces, write the APIs first, then sub-agents take what’s behind the API, and you’ll usually get a much better speedup than if you asked humans to work this way.
In practice most big projects have crux choke points and then fanout migration/buildout phases.
Even on the cruxes, where you need a single decision, agents don’t have ego and so you can get speedups by eg. asking for 10 clean room implementations of the same problem, and have a judge model pick the best; this can let you go much faster, and no human team would put up with that collaboration model.
Yes the latest models are pretty good at orchestration, if you instead open 9 chats and let them loose on your code base on different tasks without telling them about eachother you get a mess. If you tell one agent to spawn subagents as needed to do the implementation you get much better results.
> But someone nudged me: can't you have a look at it?
> My reply: "Haha sorry no! My experience is that adding more people will not solve this problem any quicker".
That seems like snark, bordering on pedantry, and makes one come across as an ass. If they know the answer, or can deduce it faster than any of the others, then it will definitely solve the problem quicker. Much depends on the qualifications and experience of those currently trying to solve the problem.
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.
> generate 100 solutions cheaply without coordination between them and pick the winner with a relatively fast eval
While it might get workable results, this seems like a miserable way to work with code. You spend the vast majority of time thinking about the problem domain of working with agents instead of your project, and for mediocre output. You are transforming your role into a dumpster diver of code.
The approach that proves to be fastest in the long run is to stay close to the code. Lay out the base structure, and use an LLM to check your work and fill in the gaps. The beauty of this approach is that it scales very well with the size of the project. When the LLM has plenty of high quality examples to follow, they start to write the same code that you would. Where it diverges, create documentation.
Perhaps the single best property of LLMs is their ability to consume and apply examples and documentation.
Brooks covers this case himself in chapter 2. He says men and months are interchangeable only when a task can be partitioned among many workers with no communication among them, and his examples are reaping wheat and picking cotton. 100 independent attempts are exactly that kind of task. He would have agreed they scale.
But the work doesn't go away, it moves. Someone still has to judge the 100 results, pick one and integrate it with everything else. That part doesn't partition, and it's where Brooks put most of the schedule anyway: in the same chapter his rule of thumb gives a sixth to coding and half to testing.
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.
It seems to me that Brooks' point was that it took time for new developers in an existing team to understand what work had already been done. They also needed time to understand the state of evolving or unclear requirements, as OP points out.
My small experience with AI makes me think that it can analyze and understand requirements and code very quickly, so I suspect that Brooks' maxim may not apply to AI.
> 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.
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.
I also think the context of building software matters quite a bit as well.
In a big corporation where ownership is fragmented and initiatives that are big enough for the mythical man-month problem to become tangible, big part of the problem becomes aligning the different engineering teams around why something should be built now, why team X and not team Y should do it, doing it securely and having enough confidence for a release.
In my experience, you choose the key difficult parts first, and build a small toy version. From that action, you learn which parts of the interfaces are common, and may undergo modularization with a clean design pattern.
Ultimately with sanity checking, sanitized marshaling, and constraint programming... the underlying security model is naturally enforced within the pattern itself.
The deceptively simple systems are more like an ant colony or bee hive. =3
Sure, works if there is a statistically salient documented solution to glean in the LLM, or a de-compiled meta-circular generated clone. As long as one avoids the $9Tn of FOSS code other people wrote, than you should be fine.
Actually more AI agents do the work faster and cheaper.
I use such orchestration for those 2 reasons. One, a supervisor model like Opus 5.5 (or fable before they lobotomised it) limited to 200k of context and told to keep it's progress updated in a text file is smart enough to understand the whole task.
It farms smaller sub tasks to a fleet of 7 Qwen3.8-Flash-Next agents. Not only it uses up 10% of the tokens opus would use those 7 agents run at an aggregate rate of 200tok/s. While opus would run at few dozen at most.
The Qwen in this example runs locally. If you don't mind sending your code to China you can spin a bunch of DeepSeek Flash agents and each will run at ~150-200t/s. Then your task gets done way, way faster
I am at a point where I would actually prefer to be the critic than the author.
If you told me my only job was to review PRs created by something like gpt6.1 on xhigh, I would have very little problem with this. As long as the upstream issues are kicked off by a human who is ultimately responsible for the outcome.
PR reviews can go very quickly if you get out of the ideology of owning every single line of code and begin focusing more attention on the data, schema and other structural elements of the solution.
I'm right there with you. And as I find things in reviews, I kick off sessions to setup guardrails so I hopefully never have to make the same comment twice.
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
I can't believe I'm nitpicking proverbs, but making a sound with one hand isn't witchcraft.
To the core message of it, if we really need to stick to one liners, "go alone to go fast, go together to go far" would be an easier philosophy to adhere to perhaps.
Reminds me of my wife chatting with this guy at a party and we were complaining about money problems and she says this proverb she had learned recently and said, "a man is rich if he has two hands".
Turns out the other person was Albie Sachs who was a hero and had his hand blown off during the apartheid era and took both arms out of his pockets and raised them up and said "I guess I'm not rich then" - that was some serious gallows humor :-)
> "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.
Not that I disagree with the point the author is trying to make vis-a-vis Brooks' Law, but there's another narrative at play here that I find more interesting.
> But someone nudged me: can't you have a look at it?
Clearly this person has some combination of thinking the people already looking don't know what they're doing, and the author being a technical person will be better at it.
From the author's side there is little interest in engaging, perhaps because of a desire not to feed the help vampires, or maybe the meeting is low enough value that an unintentional filibuster is not such a bad thing, or any number of other situational reasons that I can imagine but are not discernible from the context given. Human psychology is fascinating.
I disagree, I think one of the big problems in science (which also applies to IT, although to a lesser degree) is that a lot of time and resources are lost researching things that don't work, getting no results, and not publishing these lack of results. However, agents can potentially communicate much better and know what other agents have tried, so they don't waste their time on those dead ends.
They are also potentially able to divide work more efficiently.
"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.
Not my definition, the quote is from Brooks - “Productivity is stated in terms of debugged words per man-year.” He also writes about the limitations of this definition. But I can confirm, debugged words per man year has gone up more than 10x for many engineers.
In my experience reliability and simplicity have decreased, LOC for every feature is at least 2x what it was, more incidents than ever before. What kills me is if we just applied llm programming to the old ways of doing things and got our minor speedup but refined our approach, got ai to catch things we normally wouldn’t, did the extra refactor we normally wouldn’t we could increase reliability and simplicity. But management wants the velocity more than those things.
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?
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.
I’m increasingly curious if revisiting Brooks’ surgical team makes sense in this age. Knowledge transfer has always been a bottleneck, but in this time it is often just no longer worth it (compared to the old world where the costs were justified by increased manpower for execution of an idea).
Unpopular opinion for this site: Most true facts are not affected by the existence of AI. Most things in life do not need adjustment for "the age of AI".
For decades, eery tech boom cycle is filled with people who don't understand the mythical man month, or that LOC is not a productivity metric. The AI boom is no exception. AI has not invalidated this.
Most bosses manage by running around telling everyone to do it faster or cheaper. Never have I heard a manager telling someone to do it better or more correctly.
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.
Yes, from the title referencing MMM, I had hoped this would be the angle explored. My experience is that the optimal number of engineers for most projects is currently one, as the cost of creating bespoke automated dev workflows decreases. Even for larger, more complex projects, I suspect one person plus time spent codifying knowledge and automating processes will outperform a larger team.
Most people have no view on that, or dismiss it either as a cultish/outlandish topic or something so far into the future it's not worth discussing. The author most likely falls into these categories otherwise his point would be mute.
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
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.
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!
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.
I don’t „talk” to my agents. I tell them what to do. If I need to „talk” it means something is going wrong and we need to figure out why agents are doing bad work - and this is intellectually challenging.
The effect you describe I had at times but with older/dumber models where you could spend a ton of time and the model was either too dumb to do it, or had a model dementia later in the context. Or when I didn’t really understand why it did a bad job and tried to stumble around in the dark - very mentally numbing.
Nowadays the model usually just had some bad tools or information required to do the job.
If you're not even asking the questions, you probably don't know what it's writing. That's essentially the same as saying you don't care about the quality of what you produce.
That's not new, it's just not something most people would've admitted to until recently.
Oh yes, Whisper/Whisperflow in some places, and Groq from Elevenlabs in some other ones. It's hard to get back to typing.
The biggest challenge is in an office, or other places where I want to maintain privacy. Ideas?
By "telling" vs "talking" I meant - I have a setup that is 95% noninteractive - oneshotting most tasks, with a decent verification setup and a good memory/hooks to be confident the system does what I want and is reliable.
When something off happens, I spin up an after action review session that pinpoints the guilty sessions, interviews them, the whole investigation, and either handles improvements in the process by itself (most of the cases), or asks me for feedback. For the last three months I don't think I had a place where my input was really needed. But the beginnings were brutal.
"talking" happens only when:
- I truly need to iterate on the output
- There is some frontier-level research (i.e. working on truly novel algorithms/math)
- New UX - even Sonnet5.5 and Fable are still quite schematic and they have difficulty figuring things out from first principles. Astra is smarter but has it's own problems
You need to switch into a product manager/QA/UI,UX mindset.
Is what is being built the right thing?
Does it work?
Is it usable?
Has it been built in an appropriate way? (Note this is not a code thing, it’s an architectural question)
Traditionally developers have outsourced these things to other people.
There’s a further thing you should be doing - if the questions above didn’t pass - why not? What went wrong in your process?
OK, so I'm still very low on the spectrum of "I just command it and sit back", but I think the final toolbox will at least include adversarial questioning of the bot. For example, "Why does that code do A, wouldn't B be better?" or "Would this code break if a C event occurred?"
Sometimes it reveals a bug or a questionable implicit assumption, other times it leads me to see another part of the code, and sometimes the thing just lies at me... But it does help you keep some critical-thinking practice.
Another task might be to find and refactor/rename parts of the code that are just... not easy for humans to grasp. Some readers are thinking: "No, the next edit will be by LLM anyway, leave it so the bot understands", however I think that's short-sighted: Either these things are going to become good-enough that they should cater to human comprehension, or else they've reached a plateau and we'll want something that can resist the chaos-rot.
I think I'm where you are. Reading all the code it spits out, and then a lot of adversarial questioning. (This is what I mean about "talking to the AI", which was brushed off by another commenter). Naming conventions, decisions about classes or inline code, all these things I would not do.
So then I spend all this time getting a mental map of the code it wrote, and making my own decisions about that code. Then I ask it to rearrange it in consistent ways. Then I find bugs or oversights. Etc.
What I'm trying to say is that while all of that process with the LLM is modestly intellectually stimulating, it's not as stimulating as just writing the code myself, and it's also incredibly frustrating to have to go through the agent. And yes, I could just rewrite the functions my own way, but once I'm in a project that's LLM-driven, the temptation is to make the LLM fix it instead of fixing it myself. Whereas in a project that I'm writing from scratch, I wouldn't make those mistakes or have to think about those stylistic things, I would have already seen the bugs that it missed before I wrote the code, and I would be using my mind to its fullest potential instead of delegating my thinking to a stupid robot.
Running 20 agents at the same time means a lot more task switching, its closer to team management, you may have one agent doing basic grunt work, so can be let alone, another one may be planning and designing, so needs a little bit more q&a, and others may be problem solving, and that does take a lot more supervision. But I have never felt like I have any free time, or down time, at the end of the day I feel far more mentily exhausted (in a good way) than any day before agentic development.
>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?
If you have a lot more free time you're not taking full advantage of agents. The time saved coding allows working on 4-6 projects simultaneously, and the majority of work is the hard design/product decisions that the agents can't do well themselves. Working on the hard parts of half a dozen projects simultaneously is far more mentally taxing than just hand-coding a single project, and with that many agents there'll usually always be one with a question for you so you won't have much extra free time.
The majority of my time coding is not coding; it's thinking through the hard design/product decisions, as you said (or how business logic flows through the UI). The time coding is very, very explicitly putting those decisions into UI and backend logic in a way that would take me longer to explain perfectly to a bot than it does to code. LLMs have not saved me time on any serious project, aside from helping to scaffold things, because the results when I ask them to write a block are sub-par.
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.
> 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?
To whit, 13,000 women can make a baby in one month. If you hire that many women, by the statistics, that's how many it takes for one of them to be 8 months pregnant.
Agents still have to communicate using tokens (for now). There are more advanced mechanisms being proposed, but for now, and until proven otherwise, the same scaling problems apply to agents communicating as humans, it just happens a bit faster, and with no HR issues because someone slept with the wrong person. Mesh networking, and thus agents too, are beholden to Gupta-Kumar scaling law.
It's a weird way to express that concept, in fact I don't think it ever appeared like this in the book (it has been a while).
It would be something like "nine women cannot deliver a baby in one month", which can be more easily transposed to "adding resources to a SW project does not make it faster".
The agrument is that adding people increase coordination and communication overhead, which gets bigger as the team grows. Moreover, some tasks cannot be parallelized that easily and create dependencies.
I have only worked with agents for personal projects, but I cannot say that explicity dividing the work between multiple agents and asking them to coordinate is inherently faster than having a single agent work on it (of course the single agent will spawn subagents in rencent harnesses.)
I always thought it meant 9 women would take 9 months to create 9 babies because a baby takes 9 months to grow with the bottleneck being biology. And yes what you said applies to people but I don't get the whole "throw 9 agents into it" when it is possible to just see it as 1 agent doing 9 things? With people, yes everyone has a distinct way of doing things etc but all agents can be homogenious fully and completely sync up without any overload theoritically no?
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?
I’ve always hated that book. It was a cope to blame management for every poor outcome. “We didn’t ship because leadership gave us too many resources”. Sorry that your steak is too juicy and your sheets are too soft.
There are a hundred other reasons that software is late. You have to be brain dead to think that putting more people on the job is even in the top 10 .
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.
I think it takes MORE attention and thought. I feel like a rope being pulled tight and fraying in the middle. Working with these things is very addictive and interesting but it is cognitively exhausting long term, even if invigorating in the short term.
It does require that the human driver knows what they are doing. It captures the pre-AI developer mindset of developing a mental model along side writing the code. This has always been iterative, in discovering the model that results in high cohesion and low coupling.
That doesn't work if the driver cannot steer properly. It's the main issue with vibe-coded one-shotted solutions, that might look impressive until you peek underneath and it's all a mess.
I get a feeling that the best way we currently know how to use these tools is to not read their code at all. Models code and models review. Humans just ask questions and guide. Claude Code has no code editor on purpose.
As long as you are accountable, you need to understand the code. There’s just no way “But I told the LLM to make the code secure” is an acceptable explanation for a security breach.
You might be surprised to learn that yes, regularly pointing a tool at the codebase and seeing it found no issues is indeed enough to claim compliance with cybersecurity regulations.
While we may use deterministic tools like static code analysis, dependency scanners and similar today, people are already replacing/augmenting them with LLMs.
While every breach will trigger a root cause analysis process in a compliant environment, the solution is never going to be "all code in a deployment was manually reviewed by someone at the company" because this would extend to tooling (like compilers, scanners but also packaging and deployment tools) and all dependencies.
So I am pretty sure your example is already used in a number of places especially with "LLMs are better at security than humans" marketing being pushed around — this really makes it easy to sell that excuse to the gullible management who wants to believe this.
I have an interesting observation from the programmers on my team.
The good ones are increasingly producing good solutions 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" attitude
but the AI lead to amplification of the good and the bad in people.
>"don't bother me with shit, just pay me a salary"
Well I'll admit this is me. Albeit previously I would have to generate working solutions meticulously to get my code reviewed and merged, as is normal. And it would be good work I could be proud of because _I_ wrote it!
But now the same people who would scrutinize me also outpace me with agents (the good developers you refer to) and also continue to scrutinize me. I recognize my own mediocrity in the face of my peers. So I don't know, I don't really care about my work quality anymore, the incentive of "do enough to put bread on the table" is now a much higher bar that I am struggling to meet.
This year has made me realize salary work really isn't a proper incentive to fully apply myself because being stuck under these guardrails and leadership decisions are a huge turn off. More than ever.
When you put a person who cares inside of a culture that doesn't and just wants to get things out to meet short term goals and figure out the cost later, you get this. Working on some projects its reasonable, but on others, especially services that customers really depend on where the cost of failure is high, it really is short term thinking. If speed is the only moat a company has, its just going to be death marches.
This situation sounds very similar to mine.
I'm also like: why would you give the execs more productivity for no additional pay? The puritanical love of work and individualistic competitiveness in the US is so counterproductive to any sort of gains in livelihood for the average person.
I'm not too familiar with the US workplace, but don't you have salary negotiations? Wouldn't you want more leverage for arguing for a higher salary, if you're unhappy with your salary? I'm also curious what work structure makes you feel like you're working for execs, rather than for your clients/customers/end-users. Surely you want the people who use your systems to have a smooth experience?
Making end users happy is a side effect. My own well being comes first.
You postulated this in another reply to me so I'll say here, why would I seek to make end users happy and work myself to the bone when leadership reaps the awards?
Even with salary negotiation there is almost no commensurate compensation you get under any employer that matches the value you bring to the company. That's how it's designed of course, by taking a base wage you trade off the risk of your income stream suddenly failing.
I am at that point now where that risk does not seem so scary anymore, which is odd to me. I never thought I'd consider taking the risk before. And I am learning that founders are usually driven by the feeling that I have.
Not really. American Corporations have successfully changed the culture to a point where asking about salary is considered a flaw to the worker. It somehow demonstrates a lack of loyalty.
Things are getting better, but HR still routinely preaches that you should never share your salary with anyone else. A lot of times they infer you will be fired for it.
Salary negotiations are sort of constrained to cost of annual living increases, or promotions. outside of that, you are not expected to ever talk about salary. ever.
> The puritanical love of work and individualistic competitiveness in the US is so counterproductive to any sort of gains in livelihood for the average person
History shows that it isn’t.
I somewhat agree, but one is lucky to have any work at all these days, which unfortunately takes precedence.
This is the "got mine, fuck you" attitude that is part of the reason of a political shift to the right. And the worst part is, I get it, it's just also at odds with my more social leaning values.
Like, I don't mind paying taxes and social contributions, but I'm at a point now where I have to dip into my savings on the regular to match the monthly expenses and there hasn't been anything going in there for years.
Thank you for this honest take.
Thank you for posting. I felt almost like I was reading my own thoughts. You're not alone
I'm always curious why people who don't care about work or tech spend time commenting on career sites and topics
Many smart people get bored and get all the joy sucked out of them when living and working under circumstances.
Some people enjoy the challenge and may compensate outside work hours, often doing overtime without compensation, that often implies less of a life outside of work or work concerns, promoting their personal branding, conferences, etc.
Just because these people exist and get rewarded does not mean their work environment is not predatory.
Because they used to care.
Just because I am not happy with my employment situation doesn't mean I don't care about tech. I am privileged to even say that my job hasn't sucked all the joy out of building projects outside of work. None of this is a prerequisite for me ranting :)
Do you care about your users? If you care about tech, I'm sure you're as dissatisfied with the current state of broken and invasive software as the rest of us. I don't know the exact nature of your work, but don't you care about the experience of your clients or end-users?
Would you take a bullet for your clients and end-users?
Burning yourself out to patch over unsustainable working conditions is a slow bullet.
I like tech
You're lucky. Every single person (n of around 10) I've been unlucky enough to review code for lost between 0.5 and 3 promotion levels of competence when they started using LLM code generation, and it's been worse for the better programmers because they have more capacity to lose skills.
My personal "favorite" was when the lead engineer who onboarded me half a decade prior forgot the written policy he'd put in place of "no raw js dates. use this library for everything date related instead" and sent up an MR that not only used javascript dates, but did complex operations on them (incorrectly at that, because it didn't account for timezones, daylight saving, years that had a leap day, and months that weren't 30 days).
From what I can tell, it's the exact same reason people drive faster than is prudent or use their cellphone while driving. It feels safe and good right up until it isn't and you crash. And because most places don't have anywhere close to adequate specification detail, test coverage, or review coverage, the broken bits aren't even noticed until much later.
I think for a lot of people it's that they stopped caring or obsessing over the (perceived) small details; AI makes it very easy to work on a higher level. I suspect (don't quote me on this) that it's the same for a lot of developers that grew to more lead / managerial positions - at some point the details don't matter much to you personally and you need to spend your energy elsewhere.
But I hope people are gathering metrics. We had an extra meeting the other day because we're seeing an upwards trend in outages, the meeting was mainly about how it affects various departments (like customer support) and potential revenue loss (can't sell a product/service if the signup page is down for three days).
Thing is, there's no one cause for any of those - we have hundreds of engineers, dozens of applications and 3rd party integrations, millions of (potential) customers each running their own set of devices, and it's pretty much impossible to control everything.
But this goes beyond whether or not code was written by an attentive hand working under a strict set of policies or an AI that figures it out on the go, and goes up a level to things like realtime monitoring and incident responses.
You're right that as a person moves into management/staff+ that individual details matter less for them, because they begin to deal at a more strategic or operational level, but someone still needs to obsess over the small details (to make things easier, let's assume we're only talking about the details that actually matter and that there's broad agreement what that set is). It's not that those details stop mattering to them, it's that they have to depend on the assumption/promise that someone else is going to mind those details for them, so that they can work on things with a broader perspective.
The problem comes when no one is actually minding those details anymore. If those details aren't actually minded, then the work at the higher levels will be much less useful and effective, and in the worst cases won't matter at all.
I am seeing the same. The skillsets degrading rather rapidly, people not able to maintain focus and becoming less sharp in general. The brain rot associated with short form videos is affecting our industry via LLMs. It doesn't give me any joy to see it happening, especially to people I care about.
I don't know why I haven't been able to see the similarity between short form content and LLMs in our industry until reading your comment, but that is apt. That's the impression I'm getting. I stay away from "agentic code generation" as much as possible, just like I avoid short form content mills like the plague. That said, LLMs have been a huge boon for me as a research assistant. Being able to look up very niche problems, and have responses be tailored to me, is awesome. My brain stays sharp and I still enjoy the fun of putting the pieces together myself much faster than before.
I don't personally like LLMs for research assistance (yet?) because i can't get over the hallucinating or rather, waste too much time validating that it's not currently overcast when they tell me the sky is in fact blue.
But, especially as code gets flung over the wall faster and with less care, I do think they are getting to be pretty great at reviewing code for specific things that a linter can't easily catch and for looking for security, implementation, and architectural flaws before I have to look for them. A couple examples of what i mean: 'does the code use knex.raw with a template literal?', 'does the code do n+1 db lookups instead of something better?' 'do all the added/modified tests follow the test case template defined here?'
Agreed. I trust it more as a codebase query system rather than a codebase writer.
Amplifier of human intent. Do you want to work hard and cure cancer? Great! AI can help. Do you want to phone it in and do the bare minimum? AI can help you do that, too.
Long time ago, me and a friend of mine had a joke about PMs: to calculate how managers combine, you multiply their performance rates: two poor managers (e.g. 0.5*0.7) will give you worse performance than if you had one bad manager. My similar formula about AI and developers is that it works like raising to the power of two: if you have a bad dev, you get 0.5^2: more mess more quickly. If you have a great dev, you get 1.5^2 - exponentially better :)
I've used an even less-kind framing in the past: incompetence is multiplicative. Two half-wits together gets you a quarter-wit.
I had a similar thought earlier this year - competence is additive, incompetence is multiplicative.
... quadratically better
Maybe he had AI assist him with that comment
Yes, these are my colleagues. Same crap as before. At least now I can setup an automatic ai review that is told what is not allowed (the errors they do all the time and refuse to learn) and I get PRs that have passed 8 review turns and are somewhat better.
I don’t think the good programmer bad programmer framing is helpful. I think AI fits the working style of some developers better than others. Where it fits I’ve seen some developers become so productive that they suck all the air out of the room and drown everyone else in review - not clear if this is good or bad. Where it doesn’t fit I’ve seen developers shut down because they find the workflow so depressing and their former productivity craters. Similarly I’ve seen perfectly good developers turn into slop generation machines and go largely unchecked because everyone else gets alarm fatigue from reviewing their PRs.
Yeah the review fatigue thing is a huge problem at the moment. When your work becomes 90% reviewing AI code, it is very demotivating.
I have been focusing a lot more on testing and "manual" validation than on reviewing individual lines of code. (And on setting up rules for what the lines of code should look like that are easily checked with deterministic tools or by llms.)
For large diffs, I’ll have the human driver walk me through the code in a call and if they understand it well enough to explain it to me, and explain the implications of the changes, that’s good enough for me; if they can’t answer how something works, I’ll respectfully turn down their contribution.
This cost shifting is how I stay sane and avoid burn out at work as well as stay apprised of major behavioral changes in the software we run.
I also think it’s important to emphasize that in an organization, individual productivity is secondary to group productivity, and group productivity is different than the sum of its parts.
I understand your reasoning but my reaction to this suggestion is very strong revulsion :) On both sides of it, I would despise this process.
But you're right about thinking in terms of group productivity and costs and incentives.
We solved this at work by creating a system that has an LLM read a Jira ticket assigned to Mike, create an implementation by itself and post a PR using a service account. Then Mike can come along and review it, thereby satisfying peer review as it was authored by a different user (in our SCM) than the one that reviewed it.
Needless to say it is getting really hard to care about my job anymore
> I have been focusing a lot more on testing and "manual" validation than on reviewing individual lines of code.
Same, but there is a reason I did not choose to work in QA so this sucks too
Fair. But a big part of what I disliked was the tedium, which is largely alleviated. I quite enjoy making sure things I'm building work properly, now.
I've seen this phrased as "some people enjoy software development because they like making things, others enjoy it because they like solving the mental problems it throws up, others enjoy it because it pays well", and AI is really only helping the first type of programmer.
Turns out, business also favor "making things" at least before the other categories.
Although I believe they favor "making the right things" even more. Which is harder but neither the 2nd och 3rd categories help here.
Totally agree. AI amplifies what's there already
"don't even bother to check it."
I have to admit it gets really exhausting to review the AI output. It comes in so fast and more and more it's quite good. So it's very tempting to get more relaxed about reviews. I guess in a sense manual coding gave you some mental downtime while writing code. With AI you don't get that anymore. It's always full speed.
The problem is that humans are badly suited to remaining attentive in these circumstances. Take the combination of “overwhelming amount of output”, “99% of the time it does the right thing in the right way” and we are basically wired for vigilance to flag.
It makes me admire people like Linus Thorvalds. His job is mostly to read code and stay on top of the contributions of many people. I don’t think I could do that.
It’s easier to remain vigilant when a large part of the contributions are bad or incorrect than when it’s a very small percentage.
There should be people whose sole job is to do PR reviews.
The PR reviewers delegate work to programmers, the programmers delegate the work to AI; then, the programmer reviews the AIs work, and the PR reviewer reviews the PR.
Those "architects" or other idea people should be reviewing the PRs and keeping an eye on the whole system. That's their job, right?
Usually the programmers are responsible for their own work, and then also reviewing their own work, which is just weird. The context switching is very draining.
The problem is that PR reviews are viewed as a side-task, and it's a thankless job. The guy who implemented the fancy new feature will be personally thanked by the CEO and taken out to lunch, the PR reviewer who pointed out in the original PR that it would corrupt the database gets a "nice catch" comment, and that's it.
This is one of those cases where companies unfortunately misalign their interests with yours.
You will never get a promotion for reviewing other people's pull requests.
Can I get a promotion for asking AI to write code for me and the putting it into a PR?
Totally. Skip the PR and show it to a higher up manager.
The answer is always "if you are chummy with the manager and make them feel good". Any accomplishments made is secondary as long as it can be spun to satisfy this condition.
You mean you will never get a promotion for rejecting other people's bad pull requests.
when I'm working as an architect, my job is to put myself out of a job by teaching everyone to be an architect - for themselves and for each other. that admixture of high and low level concerns breeds really effective teams. with the side bonus that everyone has a chance to grow into larger responsibilities.
"my job is to put myself out of a job by teaching everyone to be an architect"
I used to do that but it's a dangerous game. If you don't make sure to still be very visible to management further up, you end up with a stalled career or being laid off.
When the loop speeds up you need good judgement more often. It explains the divergence and it explains why I feel so tired at the end of a workday.
Applying judgment is much harder when the amount of stuff that theoretically needs judgment is not actually processable by humans. I don’t want to throw my hands up and give up but I honestly haven’t found a middle ground that works.
Indeed. I’m personally doubling down on model-centric programming and keep tight control of the models, while being more permissive with the transformations between models.
It is nice that models remain stable, explains points of the architecture and an llm is good at following instructions that model changes needs a human in the loop. Languages with good static type systems cause friction in a transformation to show up in the types, which act as (weak) specifications.
It works to some extent
Yeah this tracks my own experience. AI has amplified both my ability to do "just do it fast and suffer the knowledge that it isn't great" and my default toward endless tweaking perfectionism. I can just give the AI the requirements and ignore the results, but I can also do infinite rounds of human and adversarial AI review and validation. Both things are easier now.
We build an open source framework that could be the solution to this problem, as it lets you automate the dev - test - review cycle where there is currently a lot of variance among developers: https://github.com/the-open-engine/zeroshot
(so you can plan instead)
This reminds me of an observation a flat-mate made when I was at university: Drugs amplify your personality. If you were cool before-hand, you would be more cool on drugs. If you were an asshole, you would be more of an asshole on drugs.
I've noticed the same thing about agentic coding. Not really the agents, but the way people responded to agents. If you were the kind of coder who was a little unsure of yourself, agents made you more unsure of yourself. If you were confident with your abilities, you were more confident.
By the transitive nature of HN comments, we can therefore conclude that LLM coding agents are drugs.
I am now wondering if there's a conversation to be had about Dunning-Kruger and Impostor Syndrome. In the modern agentic era, is it better to hire people who know less than experts, though clearly somewhere above complete novice? Perhaps this is why I find it difficult to find a job. Perhaps I am "overfit" to the world before descriptive ambiguity was an advantage?
I am reminded of the words of J. R. "Bob" Dobbs: "act like a dumb-sh*t and they'll treat you like an equal."
Anyway... yes... I agree with @freefaler on this one. AI is a qualia amplifier.
I'm pretty sure Bill Cosby said it first:
I said to a guy, "Tell me, what is it about cocaine that makes it so wonderful," and he said, "Because it intensifies your personality." I said, "Yes, but what if you're an asshole?"
https://www.imdb.com/title/tt0083652/characters/nm0001070/
> If you were confident with your abilities, you were more confident
Confidence isn't a very good indicator of skills though
I've met a ton of high confidence people who are actually dogshit at what they do. Confidently incompetent is a dangerous mix and this is the sort of person I see amplifying themselves with AI the most.
Sure. But when you're trying to convince other people you know what you're talking about, confidence is probably about 50% of the game. To be sure, you need some skill, but given candidates who are a "grade a coder with zero confidence" and a "grade b coder with moderate confidence" and "grade c coder with extreme confidence," I am confident in saying the grade c coder will get hired 50% of the time.
It turns out that software engineering in large organizations is a process greatly influenced by human psychology.
Also, "confidence w/o ability" is the core of the Dunning-Kruger effect. You have to know a fair amount to understand how shit you are at things.
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
> "grade c coder with extreme confidence," I am confident in saying the grade c coder will get hired 50% of the time.
I agree with you. That's why everything is shit!
> drugs
slightly off topic, but we need to be clear that certain harder drugs -- the ones most likely to kill you -- can absolutely change people
To quote Faith No More: "The drug modified my personality. I was like a Crack Hitler."
I suspect the speaker was "diet pepsi hitler" before becoming "crack hitler."
Not necessarily. I'm thinking of TV shows now (yes I need to go out more) where people lose their inhibitions (House did it iirc), and they "became" assholes - or they were assholes all along.
But if you're an asshole on the inside but it never comes out, are you really one? This is a pretty dangerous trap. Compare abusive situations where someone needles someone else for ages until they've had enough and the target gets angry. What would be a good response? "I'm sorry I made you angry" or "I knew you were really like this all along!"
(there is no correct answer by the way, it depends on many factors and relationships can't be abstracted away that easily, let alone by an external person on the internet who hears only one side of the story)
Anyway, if Hitler was Hitler but had filters so he never actually said what was really on his mind, we wouldn't have had WW2 and co. In theory.
Exactly what I saw as well. Some not so good ones have even stopped using AI at all, arguing it 'just got confused'. Good ones on the other hand are embracing it, hugely increasing productivity and constantly finding new ways to use it.
> Some not so good ones have even stopped using AI at all, arguing it 'just got confused'. Good ones on the other hand are embracing it
The behaviour of the good programmers is in my experience very "spread": some embrace strongly embrace LLMs for programming, some strongly reject LLMs for programming, with everything in-between.
The explanatory variables that I rather think are good predictors whether a good programmer will embrace or reject LLMs for coding are rather the following ones:
1. Is the programmer biased towards the "artisan" side of programming, or does he see the code as a means to an end?
2. Is the programmer either
- in love,
- interested in, or
- does the programmer have to work with
more obscure programming languages and/or the abstractions and mental models that these programming languages are based on? If this is the case, using an AI is often more of a hindrance than help because there exists much less training data, and/or the programmer will much more often be confronted with the observation that the AI model simply does not "get" what he wants, and will very often get annoyed by bad AI code hallucinations.
The best one I've seen aren't so interested in the "artisanal" part of the programming, but on the "practical engineering" part.
They constantly are poking at the requirements to understand what's the purpose and they find a better, simpler or sometimes hackier (for temporary stuff) solution, but they are on time, they solutions work and they get shit done.
I've seen some really crafty "artisanal" ones that debate for hours and rewrite 10 time the release scripts... Not the most efficient way to spend their time.
So, yes, purchasing code from Anthropic is going to McDonald's for dinner. It's not very good, but it gets the job done fast, so long as you don't care about cooking.
What other enjoyable things do you think we can automate, so that the people that hate doing them can cheaply replace the people who enjoy doing them?
Do you think we'll leave any work that people enjoy?
The purpose of software is to be useful to users, not provide a reason for you to get paid a salary to solve puzzles very slowly.
And what's the point of spending most of your life doing work that sucks so that others can hate their job too? It seems like a bad idea to make everything worse so we can have more bad software.
And, yes, the resulting software also sucks, and I'd pay extra to avoid it. There's been a noticeable drop in software quality over the last year or two.
The point is to survive and care for your family.
In a free market economy, you get from the butcher the meat only if you can give the butcher something in return. It might be cleaning the store, or throwing out the smelly bloody stuff out.
It's not pretty, but life is not pretty.
It is great to find a way to swap for other's needs what you're good at and enjoy, and sometimes it's possible.
However, since you need to solve another's person problem to barter with from something, it's by default not something you like, but something the other person needs. And this frequently is not what you would like to do at the moment.
So basically, this is life, sometimes we can write beautiful code, sometimes we need to fix a messy code our client uses every day.
And sometime we don't have the pleasure to work on the computer at all, because AI took our job away, and we end up cleaning the store.
Cool, "Life is getting worse, shut up and deal. Altman needs his returns."
Got it.
Dude, it's not Altman, it's the real world.
If you can do something for your client, then you get to eat what you both voluntary agreed the deal is worth.
Does a plumber work for Altman, or for himself? Why this need to have a boss and not live by the direct fruits of your own labor?
Ah, my bad -- "Suck it up, shits getting worse for everyone because of what this industry is doing. The future sucks because of us, get used to it."
> And what's the point of spending most of your life doing work that sucks so that others can hate their job too?
I mean in my case i'd be absolutely fine doing work that sucks infinitely if that means that my users are happy. It really drives me crazy all the discourse I've seen over the years about devs that care about their own quality of life/job. Like, no, the only thing that should matter to you is your users, no matter the job. If what makes them genuinely happy is for you to take dirt out of a hole and put it back, and on top of this you get paid, we live in completely different planets if you don't rush to the nearest shovel.
If that was the purpose, we wouldn't dimiss consumer sentiment of software getting constantly worse with a shrug.
We all know the real purpose of Big Tech.
yeah, some people - wanting to derive some enjoyment and meaning from the work they spend most of their lives doing to further enrich someone who is already rich - like give the calvinism a break am i right folks?
Calvinist "work ethic" is a problematic doctrine, but it's still more moral than a structurally oppressive synecure.
You're comfortably ensconced within a powerful economic inequality machine, and you're fighting for your right... to party? It's a bit gauche.
At least I tell myself I'm keeping the lights on for many families.
yes i think happiness is meaningful and in a just world would be a non-negotiable part of participating in society (economically or otherwise)
You're right—happiness is meaningful, and the pursuit of eudaimonia may well be the most moral act.
Can you truly be happy while billions suffer unnecessarily?
By this logic, no one is ever allowed to ask for more except for the person who has the least. It is nonsense.
Can't we ask on behalf of one another?
It's okay if it did both. The pre-AI world was not some hellscape - people felt they had a purpose. Not so much now.
Until half a year ago I used to agree with you, but nowadays Claude has gotten so good that I have to admit it's a better programmer than myself. Its coding style is excellent, it follows whatever conventions are used in the codebase, it has excellent suggestions for refactorings and it spots omissions or mistakes in the specifications I give it.
(I'm using mostly Scala as a language in a large microservices environment)
I dont know any worker that intentionally chooses a job they dislike unless they need a survival job, and people doing survival jobs generally put it low effort. Programming requires high levels of effort and concentration and it would'nt be my first choice of survival job. If ALL the interesting parts of a programmers job disappear, then I guess the job is over unless you like typing prompts all day.
With this answer, you rather have revealed which style of programming you are strongly biased to.
Yes, there is a genuine divide between people drawn to programming for the art and people drawn to it for the practical. AI has impacted the former much more intensely and negatively than the latter. It's really a bummer.
Funny how "maybe they work in different domain" doesn't come up here as well.
When y'all talk about these LLM programmers, what are they programming? The next startup Typescript website, a new OS, a C++ firmware for a fridge or a control system for cancer treatment machines?
> Funny how "maybe they work in different domain" doesn't come up here as well.
Good point. :-)
The x^5 paradigm: good programmers (positive x) are 5× better and bad ones (negative x) are 5× worse.
This is spot on to what I have noticed as well. The slackers are still the slackers with no real self drive or enthusiasm for the tech and just keep doing the same thing, but instead of using Google/stackoverflow to copy and paste from they use Claude/Gemini to do the same thing.
as long as im working for a rich guys company i will be the 'just pay me' dude
> The not so good ones, are doing the same bullshit they did before, but now the don't even bother to check it.
What bothers me greatly is how the not so good ones are now delegating all their contributions, code and otherwise, to AI assistants, and fail to to any cursory check in what they are delivering. It's sheer laziness and irresponsibility.
So far I've seen junior developers who found sudden passions for code reviews to post high volume of comments on any PR to showcase their technical prowess, but the comments clearly don't match the code or context and we're obviously posted without looking. I've also seen old but barely competent developers leaning quite heavily on AI assistants to formulate troubleshooting theories that are based on scenarios that deeply contrast with the actual problem, and go to the extent of announcing they identified root causes when they didn't even tried to reproduce them in the actual system, because if they had tried they would notice the whole theory is impossible.
Everyone talks about high productivity gains, but these types manage to use AI to waste everyone's time.
> "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.
Not if you turn off your brain. Never actually stop to question the path you're going down, because the speed is making you blind. Which is what I feel I see more and more. Or how do you even know it's the wrong answer if you didn't think it through before starting?
One example: setting the agent ablaze on some task, keeping it going, and after a few days of working with the agent you have a feature. But it's not what you were supposed to make. The agent didn't have all the context and made something slightly off, and you never internalized the problem enough to even spot it. If you actually stopped to think a bit on how the feature would have to work to tie it in with everything else, like you would have done before, you would've spotted it.
Second example: something wasn't feasible to do before, due to not being worth the time investment. Like a feature that would need a bigger architectural change to implement. You and the agent take a crack at it, and rewrite huge parts of the code, and it seems to work. But now no one understands how, and it might have been the wrong way to solve it, you just went with it. Before, you would've sat down and discussed and thought about the architectural tradeoffs. Now one decision was just made with little thought.
Counter argument is you rarely hear of sunk-cost fallacy coming into play.
I used to do the same thing without AI, I'd spend a week working on a task and only realizing at the end it was wrong, but because I spend so much time on it, I was incentived more to keep going and ignoring sunk-cost.
Now I don't care, it only takes me a an hour and I have no problems throwing it away and trying something else.
This feels even more true working with a team. I have a harder job convincing a team member who spent several days manually coding something that they’ve headed in the wrong direction compared to one who built it with AI. The person doesn’t have a personal attachment to the AI written code. Of course that also means they don’t understand every line like they would if they wrote it manually, but the lack of attachment is certainly a benefit.
> I have a harder job convincing a team member who spent several days manually coding something that they’ve headed in the wrong direction compared to one who built it with AI. The person doesn’t have a personal attachment to the AI written code. Of course that also means they don’t understand every line like they would if they wrote it manually, but the lack of attachment is certainly a benefit.
If the situation that you have to convince a programmer to stop working on something is something that happens more often than very rarely is in my opinion a strong sign of bad leadership. These are people who are really in love with what they are doing and are thus so attached to it, and you want to cast out this love for working?
So, the moral that I can only get from your post is:
- AI can be used as a mitigation for bad leadership.
- Programmers should care much less about the work that they do.
No. It’s a healthy practice to build prototypes and spikes to resolve technical uncertainty. These should be considered disposable.
Sometimes people get attached to the prototype, and that’s counterproductive. The most common example is “nice job, the 2 week spike shows us that this project is not viable, we are canning it and moving on to a more impactful project”.
> Now one decision was just made with little thought.
I've seen the same behavior using AI. They just keep double it down without seeking human feedback nor asking themselves if there's prior art tackling the same problem. At the end, they don't only get into sunk cost fallacy but also go into a shadow IT journey achieving generational tech debt in a few weeks.
If you didn't allow yourself for a feedback loop venue and constructive feedback from peers, AI will not solve that issue.
"nor asking themselves if there's prior art tackling the same problem"
Asking AI is asking for prior art to not invent the wheel yet again.
On the other hand there should be some actual cost of changing everything.
I see people ship a half baked feature then spend the next weeks ripping and replacing huge pieces causing all sorts of issues
It’s much harder when team dynamics start coming into play. Maybe this is something where the norms will change, but for now, it’s still much harder to stop someone from shipping something they have built than to offer corrections to what they’re going to build.
I dunno. You've heard of "build one to throw away", right?
Always easier to discuss what the client actually wants if you've got a demo on the table.
I'm doing short feedback loops with product owners more and more - sometimes within the same sprint. I'm not even getting bikeshedding back, but that might be because we have some fairly solid design guidelines.
Or, you don’t even realize it’s not really what you wanted. Once you have a nicely polished product, it’s hard to compare it to the fuzzy idea that you had in the first place.
I feel like going slower gives you time to let the details form the solution. You think “hm maybe that doesn’t make as much sense as I thought, maybe there’s a better way to frame the issue…”. If you don’t let a problem really soak in, you don’t get the “hammock driven development” that Rich Hickey talks about.
Of course some problems don’t need to soak in. A lot of problems just need code to be cranked out. I love slopping together a monster script that solves exactly one problem perfectly
It’s like discussing a fully rendered concept art. You will get lost in the picture. And there’s always the slight suggestion “it’s already looking so nice, why think harder”. Which is why sketches and roughly painted thumbnails are best for brainstorming. Easier to think out of the box that way.
Same with demo. Do a rough wireframe or something with default bootstrap style and it’s way easier to target the meat of the problem. Not so much on a full site
Its not the engineer's responsibility to figure out if you're building the right thing. That's the job of the managers and product owners.
I’ll claim the ones in the end that will have that responsibility will be engineers. LLMs add the ability for engineered to build quickly enough that there’ll be enough of them to morph into product roles as well. I trust us/them much more than product owners who use models to code.
Much easier to engineers to move to product than product to move to engineers. Or at least the minimum amount needed to fill all product roles. I’m seeing we can do that now and it’s _much_ more efficient to not have to have back and forth communication as in the past with that communication being by far the slowest part of build processes.
> I’ll claim the ones in the end that will have that responsibility [to figure out if you're building the right thing] will be engineers.
One can have this stance. But in practice, programmers who have strong opinions on this topic that is not aligned to the management wishes will commonly become personae non gratae in the company, and are thus commonly on the brink of getting fired.
So, in the end, the incentives that exist in most companies are strongly biased towards the position that figuring out if you're building the right thing is the job of the managers and product owners. :-(
I can agree with this as well. But I'll do a follow along for who says management has the best and correctly decided plans for the company? What if in the future, engineers become product, and those then become management because who's to say that's more difficult?
For the way orgs are currently set up, yes, conflict between engineers and management can cause issues. I'd put somewhat of a bet that those types of org setups won't be the way in the future.
And how do you think many of those managers come up with the ideas nowadays?:) There's no human in the loop anywhere at FAANGs. I see it first hand. LLM ideas, LLM docs, LLM coding, LLM launch announcements...
In theory sure, but in practice an engineer who can steer managers and product owners can have a massive impact on the outcome.
Tell me you're a bad engineer without telling me.
If you don't understand what you are building, chances are you'll take suboptimal decisions or even come up with a solution that completely misses the point.
To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
> To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
Many managers don't like being challenged. :-(
Eh.
If the engineer is told to build a bridge that is virtually guaranteed to collapse, then it a reasonable person ( ideally, same person as engineer ) would note that particular risk.
It may not be engineer's responsibility to build the exact right thing, but it sure is their responsibility to build it right without having the bridge to collapse the moment someone stands on it.
Otherwise, the person building the bridge is not an engineer.
> Otherwise, the person building the bridge is not an engineer.
One is likely not an engineer if one does not notice the risk. But in practice, managers commonly desire docile subordinates, so the only thing an engineer can do in such a situation is to ensure that a paper trail gets generated that will be capable of breaking the manager's neck once the disaster has occurred. :-(
> Or how do you even know it's the wrong answer if you didn't think it through before starting?
Real life is full of unknown unknowns, AI risks putting you on the wrong path without you even realizing it.
It doesn't help a bit that (almost? I'd say all) AI products are very confident while they're guiding you on that unknown unknown path, so of course that you don't realize soon enough the epistemological situation said AI product has driven you into.
What's easier to use as inspiration for coming up with a list of requirements?:
1. A blank sheet of paper
2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
Definitely this. I've had plenty of useless meetings with no helpful outcomes that lasted an hour with 6 or more people in them, and a few of them will have had more than $4 spent on snacks, let alone everyone's wages.
That said, poor communication will always get you no matter what: had one day spent going back and forth with a client, they kept saying they wanted a button "wider" each time around, I ended up making it full screen width and they still said "wider", asked them to draw a picture and they finally said "wider vertically". That may or may not have been faster with an LLM, depending on if the LLM ever thought to ask the client to draw what they meant, but fundamentally would have been exactly the same problem.
It goes beyond this, the job is to understand the underlying need. When a clients asks for a button to be bigger, what's in their head is they fear it's not visible enough. Many times the client was happy when I implemented something unrelated but that solved the issue, like changing the colours to increase the contrast between the background and the button, adding space around, etc. so that it pops out more.
> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?
A meeting between all the stakeholders to agree on requirements easily runs $1,000/hour. Taking your $4 functional PoC into that meeting is going to save so much time...
> A meeting between all the stakeholders to agree on requirements easily runs $1,000/hour. Taking your $4 functional PoC into that meeting is going to save so much time..
It is though! Because previously your have the meeting last 4x as long to end up with a list of notes that you already knew.
Now you can generate the PoC, showcase it during the meeting and leave with actionable changes in project direction.
I had to re-read parent's comment over and over, because I simply was not sure if he was being ironic, facetious, or just had trouble expressing his point.. and, honestly, I am still not sure.
Not everyone in meeting will be the same person you are. Visuals help. Prototypes help. They certainly can save us from vague ideas and unclear language, because at least someone can point to the big button at the bottom and say:
"Can I have this in cornflower blue?"
It is useful, simply because it makes it more concrete. Will it change? Is the pope catholic?
I was being entirely serious. Even at $400 of tokens it would probably still be worth it to take a functioning prototype into the discussion. At $4 it is a steal
Ahh, thank you. I initially read it as $4 not being worthy of the time of combined $1000/h meeting. Clearly, more coffee is needed.
I used to spend an hour throwing a PoC together with PHP (or sometimes in MS Access) because hey you can throw shit together real fast, and because I used either a shitty language or a toy tool they were treated as throwaway.
Now LLMs make that easier to do with a larger scope.
I use PowerPoint for that.
Draw outlines, or use graphics, wire up clickable areas, and interaction flows, and you’ve got a presentable “live” demo that doesn’t run afoul of issues presenting demo sites to non-techies (placeholder text, ugly buttons, test domains, colours, etc).
I used Balsamiq for that. The “pencil” render of the shapes make it obvious to not discuss aesthetics issues and only focus on flows.
Obviously "a blank sheet of paper" here is meaning thinking about the problem deeply. I'm surprised how dismissive people are to using brainpower whatsoever. I get that juxtaposing paper to LLMs might have triggered some people though.
As a counterpoint, bringing a one-shotted POC without thought may actually do have a shock and awe sort of effect, dazzling the stakeholders to go down the wrong path since the AI prototype was so easy.
> I'm surprised how dismissive people are to using brainpower whatsoever.
Scrooge McDuck lived by the credo: "Work smarter; not harder."
But for many people, smarter is harder.
"A one-shotted POC"
As long as someone doesn't go - "Why do we need requirements, you've built the system already!"....
Long ago I have read somewhere a good method to prevent this:
When doing a proof of concept, always use ugly black-and-white buttons and icons. That makes it obvious even to the non-technical people that it is not finished yet, and still requires some work to do.
Sure, the concept of a _Vomit Draft_ is not new, but the ability to come up with one quickly is.
It plays into the generalisation that people aren't good about saying what is the right way to do something, but much more open to saying what something is doing the wrong way.
In a previous job we used to do prototypes in languages like Perl because we couldn't ship them and knocking something non-production ready was easy. We were able to quickly come up with the PoC, iterate on it, and then plan and write the whole thing in $LANGUAGE_OF_CHOICE.
The latter, clearly? It is far more valuable to have a (badly) working system you can prod and probe than work from fantasy.
People are much better than saying what they don’t like than what they do.
Using the "let run multiple agents run amok" approach you surely get a lot of "i don't like that part"-feature requests, yes.
In my opinion, a good engineer is not good because he understands every single obscure technical detail, but because he can build solutions that the people using his technology actually want. The list of things they don't want on the other hand is endless.
Personally at some points (like frontend design) I just ask the agent for 16 options with a convenient comparison system and just yeet designs until I’m happy, guiding it along in a very uncommitted way. “Quantity has its own quality”
That's because good design is very hard to identify, while almost everyone can immediately identify a bad design.
What if there’s many more POCs they don’t like than those they do?
Theyre also inclined to jump into talking about solutions rather than their actual problem which inhibits analysis of the problem.
What's the most soul crushing?
A one-shotted POC can also put you straight into the very wrong direction, with a very high degree of certainty.
I also prefer doing a POC, but it's not without risk, especially if your stakeholders are just a bit too eager. Another problem I've seen is that a POC can hide complexity, so a lot of weight is on you as the author to do the due diligence before and bring that along.
This is an often underrated problem. I used to work at a company where we would hold demos every other friday, with drinks and nibbles. We would put a lot of thoughts into what we were going to present, and were really careful about the messaging, because execs and sales were watching.
The last thing we wanted was for an "Isn't it neat?!" hacked-together demo to be mistaken for something shippable, if workable at all.
If me planning the requirements takes >1h the the POC is certainly the cheaper option
"Oh no problem, I'll just run it again telling the LLM to not do those 20 things, and then we'll have the right answer." /s-mostly
It was pretty surprising to me when I realised I could put 5 different bug reports into the same message and it would fix all of them.
Not quite as shocking as the original InstructGPT video, but surprising.
What's even more surprising is that it can be given a grafana API key and reason about bugs from the hints of patterns in the logs even with pretty sketchy and inconsistent logging in places.
It can then raise, investigate and resolve those problems while also patching up and rationalising logging to improve future work.
The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
Such low level grunt work is what AI is good for, no one denies that.
What some of us are saying is that AI is poor at figuring out what to build, how best to architecture it, and what to avoid.
Again, no, "what to build" is the humans input, but it's not just grunt work that modern AI tooling is good at... Architecture and what to avoid are also strengths of AI.
> Architecture and what to avoid are also strengths of AI.
Absolutely not at all. Every single day that I work with Claude, there is abundant evidence that AI sucks at these. Ask me for examples if you need them.
Yes, please provide examples.
See these comments of mine, which I added exactly for cases like these where someone asks for evidence:
https://news.ycombinator.com/item?id=50220976
https://news.ycombinator.com/item?id=50165791
https://news.ycombinator.com/item?id=50159827
The first links shows a basic failure of reasoning, which would have gone unnoticed if I was just vibe-coding.
The second link shows weak architectural sense and an inability to see the big picture.
The last link in particular is telling: the agents worked with me (over weeks to months) to implement a db abstraction layer without ever bringing up the fact that as it stands, that would have never worked with any indexes at all. I did not constrain them to my choices, but they never stopped me with that design. It took my eagle-eyed attention to their offhand comments to notice this problem, which then required a lot of rework to fix.
Unfortunately, all three comments have apparently been flagged by somebody for some reason and I can't read them. This is my least favorite aspect of hacker news. It's exhausting, honestly.
Like a sibling comment replied, you can set "showdead" to "yes" on your profile and click update" so see flagged comments. Not sure why they were flagged.
Go to your profile, and you can set a flag 'showdead' as = yes. Then you'll be able to see flagged/dead comments.
For flagged threads, you can go to:
https://news.ycombinator.com/active
I'm old enough to remember when things such as this were not considered "low level grunt work".
I'm writing a unique MUD, and It was surprising to me when I posted some bug reports I'd made and it identified things I didn't complain about. "User had trouble with X" and then suggested mitigations for those problems. I ended up rejecting a lot of them because I knew I had different mitigations coming eventually, or it was working that way for a reason...
But it was pretty eye-opening to see how good it was at watching a user struggle and identifying possible fixes.
> The AI deniers have their heads in the sands at this point and are demonstrating they simply haven't tried a modern agent. ( Or perhaps are forced onto copilot? )
Could be either, but also the free version of ChatGPT seems rather braindead compared to the paid version, or to the free version of Claude.
That depends on (A) verification being very low cost and (B) being able to infer the right answer based on wrong ones.
Those aren't always true. Sometimes it takes a while to see the fatal flaw in an approach, and sometimes having a bunch of failed attempts isn't enough to make the right way obvious, and thinking is still required.
Good points. This is after all why LLMs are so much better at maths and software than the economy in general.
The thing is, AI is generating sooo fast so many outputs, its hard to review and evaluate all of them: Very often I encounter in design/architecture questions a situation where the model suggests 2 - 3 alternatives approaches,then asking a little bit and there you are with 30+ pages of content etc.
i have a hard cap of 8 suggestions per day for a hobby project, but i still dont really manage to review them all properly.
I do it like how I handle error messages: one at a time. Maybe 2-3 if the work is easy. Often enough to find new directions or uncover new problems and the suggestion list doesn’t work anymore.
how do you enforce the 8 max requests? :-D
i just told the reoccurring agent to start maximum 8 experiments at a time. It is capped at 8 sub agents, so there might be more issues created, but they are the results from 8 experiments
It is an anti-pattern that predates AI. Tester-driven development maybe.
The idea is that instead doing things correctly, you do "something", then, if it fails (it will), you change some random stuff until it passes. It typically results in code no one understands and that fails each time something unexpected happens.
AI makes the process much faster, but just as wrong.
I agree with both you and matsemann. Getting the requirements right by conducting a cheap POC is a good approach. Matsemann is highlighting the failure that creeps in when the POC is shipped as if it meets the requirements.
Someone has to sign off on the requirements and also what is released. So, two approval steps by a person. The first approval is for a plan and the acceptance criteria. The second approval is a check against the plan. The agents can do all the work of taking the plan, breaking it down into tasks, building, and then verifying it. A good orchestrator will include people in the workflow at the points where their decisions matter and maintain a record of it.
That's always been the case though. Much of our job is figuring out as quickly as possible how wrong we are and in what way. And the best way to do that, now and 5 years ago, is the scientific method. Try something, and then listen to your users to hear what sucks and why, and then adapt.
Believing you can figure out the right requirements through a lot of thinking, analysis, and talking is called the waterfall approach, and it's as wrong now as it was four decades ago.
> The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements.
I guess that’s just the old “Build One To Throw Away” in a modern light, where prototyping more freely is now actually feasible. I think if you apply the good engineering ideas of the past decades to AI, the results can be really good!
Except I’d also add a lot of testing to the prototype, to bring up as many edge cases as possible.
I was talking about it for a while with colleagues. AI besides other benefits, needs to be treated as great interface for discovery, you have your features baked in, AI uses it via your users and MCP, then you figure out what are actual flows of my users and then you build it
Only if you can recognize it as the wrong answer. But in a lot of cases, that’s unobvious, unless you have clear requirements.
The thing is it's faster to get 10 wrong answers that will lead to the right one than to spend time getting the right one out first.
Yeah, this is a succinct way to describe a very important dynamic in software engineering that is usually unfamiliar to most inexperienced developers but a central facet of most experienced developers.
Software engineering is almost always a process of iteration. The better you get at iterating, the better you are at engineering. This can take on a lot of forms (my old manager would constantly repeat the mantra "don't let perfect be the enemy of good," which is arguably a recognition of the same dynamic), but at the end of the day, if you expect to "one-shot" a complex implementation and you build a process around that assumption, then you will fail. Almost ironically, the best way to avoid that issue is to assume you will fail (potentially multiple times) and to build a process around that assumption.
Interestingly, it seems like a lot of experienced engineers I work with have just forgotten this concept in the world of AI. They expect AI to just get things perfect in one-shot and are dismayed when it fails. There's a lot of discussion around how we handle code reviews because some developers are just letting AI one-shot a solution then sending it to review. It boggles my mind that competent engineers aren't allowing their AI to fail, so to speak, and are instead wasting cycles trying to figure out how to get AI to produce the perfect solution the first time.
To me, it's obvious that there's just a fundamental gap in alignment that prevents a consistent "perfect one-shot" to probably ever be possible (at least, within the current paradigm of development). I can spend an hour writing a spec and try to include every little detail of context I can think of, but in what world could we expect anyone, let alone an AI, to be able to envision the solution the same way we can? We just lose way too much information through communication for that to ever be possible. Yet I see people very dismissive of the capabilities of AI because it's not literally magic.
This is an underrated perspective. A common tactic I use with agents. Just building the slop prototype until it has enough fidelity to be obviously right or wrong can be way faster than sitting down, thinking hard, and planning in advance. This is especially true for background tasks, and IME is the key to productively parallelizing yourself without decision paralysis.
At some point token efficiency will bite, but even that is overrated; the metric you really should care about is:
impact / (salary + token spend)
> The thing is it gets you the wrong answer so fast
If oftentimes happens that you don't know that that's the wrong answer, or you don't realize it right away, for that matter, and hence that's I think that AI is a new (and very big and important) source of information entropy.
Just a recent personal example, yesterday I was curious about the historical figure that was present in an online photo taken in 1930s Romania. Google's Gemini was very quick to point out that that was (military dictator) Ion Antonescu [1], which it was obvious that he wasn't. I wrote down that that wasn't in fact Ion Antonescu, at which point Gemini was very quickly and very surely providing me the info that that guy indeed wasn't Ion Antonescu, but (former Foreign Affairs) minister Manoilescu. At this point I wasn't so sure myself, I don't have a visual image of Manoilescu in my head, so (ironically) I had to AI-dumb google for Manoilescu's available online images and it seemed like Gemini had been wrong a second time. I didn't bother asking it for a third time.
Just to put things into perspective, here in Romania it is illegal to mention Ion Antonescu's name (and propaganda image) in a positive matter, as in one risks prison for doing that, now, just imagine that the political powers that be here decide to use an AI-tool like Gemini in order to identify potential law-breakers in that respect. People would risk going to jail just because Google's Gemini was completely wrong in identifying a WW2 military dictator. Absolutely atrocious product(s).
[1] https://en.wikipedia.org/wiki/Ion_Antonescu
> erm, Claude, do it again but leave out the bad stuff and make it good this time, mmkay?
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 over
Context size and ability to context switch without burnout is what will differentiate a median engineer from a great engineer, not technical ability
I absolutely question the attention to detail and work ethic of anyone working on five issues at once, let alone "far more".
I absolutely see all the crap devs who work on 5 tasks at once create.
Basically I try to explain to them they are not paid by amount of tasks they pick up but amount of tasks that are DONE and DONE doesn't mean "yeah it kind of works, I don't have time to fix details because I have 10 other tasks".
Super annoying, yeah we can make follow up fixes - but that's more work not less and if all would be done right just now topic would be closed.
Too late, already got promoted for being a 10x er
I wonder if people are honest to themselves whether they actually did have the ability to work on one and only one issue at once.
I mean at some point you're waiting for a build or test run, or you've submitted your work for code review. Do you sit there patiently and wait, or do you open the next ticket, a new tab, a private project, etc? (This predates AI of course)
I was able to go from 5 to over 20 parallel sessions without burnout by changing my role. I switched from engineer to engineering director. I try to focus on directing and deciding. I built a software for that for myself. Two key features:
1. Each project (= one or more repos) gets a canvas. On it, work is laid out as cards. Position and color let me build a mental map.
2. Agents end each card with a demo, which is typically a narrated video of the new feature or bugfix. I review it like an engineering director in a launch review. If I have comments, the agent goes another round.
With this, I don't feel the pain of context switching because I don't need to keep the context all in my head in parallel. I get it presented every time a card wants something from me.
I totally get the task board and I do almost the same thing myself. The demo idea is cool though. It makes sense that whenever the coding agent wants some judgement from you it spends a bit more tokens to make a report optimized for a complete and readable explanation. I doubt it should be a video (videos impose a minimum time required to get through them), but there's certainly a lot more you can do compared to coding agents' default text responses.
I find the time unproblematic. A bug fix is typically 30 seconds, a new feature 1-3 minutes. I want to review those before they go out, and any other way to review them I can think of would take longer.
FWIW, if the work is better shown on an HTML page (e.g. to show stats of a previously flaky test), the agent can do so.
>The difference is one engineer can you work on many sequential tasks in parallel.
Then they aren't sequential.
They said "many" sequential tasks in "parallel". Sure the singular task is still sequential, but in the end more is being done.
Including approaching a burnout faster than doing one task at a time.
Is burn out correlated to the number of tasks someone takes on at once? If you can do five tasks in parallel for 6 hours a day, I wouldn't think that would cause burn out.
Burn out is probably just correlated with the amount you overwork yourself. And just like before AI, great engineers tend to have a higher threshold for what they consider overworked.
Thinking about it a little more, the qualities that made an engineer great before AI are still very similar today, but weighed slightly differently.
Sequential implies a sequence, ie many tasks. One single task can't be sequential or parallel. Or you are talking about a feature that is broken in multiple sequential tasks.
they're very clearly talking about multiple independent features, each of which may have sequential lines of work.
> Context size and ability to context switch without burnout is what will differentiate a median engineer from a great engineer, not technical ability
I thought the ability to multitask in humans was disproven, as it results in lower quality work.
You’re basically selecting for people that are unable to focus properly. Might as well add a TikTok picture-in-picture to keep them engaged.
Different sort of multitasking.
Best as I can tell, every time we've ever tried to study this we've invariably come to the conclusion that the human brain physically cannot handle both constant context switching and deep work, but that lots of people think they can despite all empirical evidence. If you think you've found a new sort of multitasking that bypasses this, call up the neuropsychologists and there could be some sweet, sweet grant money in it for you if the study gets spun up.
Right. Y’all are talking about two different types of multitasking.
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.
> Related thing is that LLMs are still notoriously bad at writing instructions for themselves (so managing themselves also).
Isn't this odd? This seems to be the #1 task that the major labs should be optimizing, since it makes agent so much more effective.
> 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.
Isn't this just the planning pattern, common for agentic work? (first plan then implement.. with things like /plan, or a planning skill, with or without creating a PLAN.md). If this methodology is wrong when an agent prompt another agent, it's also wrong when the human runs /plan manually..
And Indeed, I always thought it was odd to constrain the implementing agent like that, because common sense is that we discover things as we implement. Perhaps we should prompt the agent to communicate back, as they implement, any shortcomings in the plan itself - such as things they learned while implementing that contradicts the plan.
Things are moving at a pretty much breakneck pace, I'm not surprised there are so many opportunities for improvement yet to be grabbed
Anthropic consistently claims the opposite since Opus 3 (early 2024) which was notoriously better than their modern models at understanding overarching intent. That was literally their official prompting advice, roughly "in our tests Opus-written prompts were better than prompts written by humans, so you should let Opus write them for you". But it was painfully obvious that the model lacked depth to do that, and it's obvious modern models lack it too. It will probably not be solved until reaching AGI, whatever that word means.
AI shops rely on scale automation, metrics, and LLM judges, which heavily distorts their visibility into what they're doing. This often results in being out of touch. That's likely how Claude lost its writing ability (they stopped reading its outputs).
> until reaching AGI, whatever that word means
Maybe that’s exactly it - AGI is ability to plan well?
There are many wildly different definitions of AGI to begin with, but sure, "deep" cognition would be able to accomplish a ton more than the current "wide".
Exactly, and a lot of times when I step back and discuss alternative approaches and architectures with the LLMs, they keep going back to say: "the code does not use this (currently), therefore this is fine to throw away", or "the code does this (currently), so this approach is not compatible" They are bad at stopping to ask "what should the code be doing"? It's like they love being constrained by current choices, even if there is nothing unchangeable about those.
> being constrained by current choices
The most obvious reason for this seems to me to be that the data they were trained on likely overrepresented cases where the current choices were treated as unchangeable.
Actual case studies where they talk about what approaches were abandoned and why certainly exist, but I'd guess are much less common than posts presenting a problem as "these are my constraints, how do I meet them?".
> The subagent is just as intelligent
Isn't it a common practice to use cheaper models to do the grunt work?
Does this actually work for anybody? In my experience, when you use cheaper models as subagents, the more expensive parent agent ends up reading all of the subagent's work and surrounding code into context anyway to review it. So you end up paying more, not less.
Plus the subagent's work is often subpar and the parent ends up requesting multiple revisions. Each back and forth burn unnecessary tokens as well as my time.
Where it might work well is for separate task categories like image generation - get the parent to ask for an image from another model that is better at this aspect
When I am making agents do a hard thing, I use Opus as both parent and child. I make the child review its code extensively, and then still make the parent read the work and review once again. It is much faster and cheaper than just rolling with no extra reviews, and then in a day I have fifty subtle bugs.
I've noticed this myself and am not sure how to solve it yet. I think there is value in methodically specifying what needs to be done ("grill me"), but sometimes the resulting plan indeed becomes overly prescriptive, leading agents to chase goals that ultimately don't matter.
I don't know if my requirements are lax but everytime I give opus 5.5 a job and tell them "spin up sonnet or haiku agents for grunt work they should do given their skills then double check their work"
I get great results and save tokens
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.
Right, the key being a fast feedback loop. I have full confidence that the same LLMs that can do these crazy math proofs could also do crazy biology, even cancer research, but they simply don’t have the cycle time low enough because they require actual physical experiments, often on living things, often over long time horizons. Even if you perfectly automated a lab, made thousands of them, you’d still be unable to match the speed of iteration that one gets with pure math and computing problems.
What gives you full confidence? The human body/biology has basically nothing to do with math or writing code. This doesnt translate in any way. There isnt a single biotech expert on earth that agrees with you.
Has nothing to do with knowing the answer, and everything to do with infinite persistence. I believe any current-generation LLM can, given an environment where it can experiment rapidly, do anything.
Current generation LLMs still can’t win single player games that most humans can win. Someday the LLM will be able to complete getting over it by Bennett Foddy, that day is not today
That’s a game that relies heavily on quick timing though, if there’s no minimum period of time I’m sure there would be less of an issue.
No, I think if you paused the game while the LLM is thinking it will still fail.
Even outside of controls based games, LLMs fail on sokoban like puzzles weirdly enough, see MazeBench, they’re also not that good at chess, probably around 1600 elo.
It can literally only write words. And it cant even do that well. It only does well at coding and math because it can be brute forced against compilers/verifiers. There is no compiler for the human body, the closest thing we have too it is death. The chemistry and physics going on in the body is much more complex and mysterious than all this math and computer science LLMs are helping with.
LLMs aren't going to make you live forever. This is a marketing scam. They are stateless statistical models that spit out words. Thats it.
Plus you'd kill a lot of people.
"You're absolutely right, that drug was lethal and that's on me. I'll add a note to check human toxicity for all compounds in the future. To verify the safe dosage, I'll administer a high dose and then check smaller doses until the patient survives — not guesswork, grounded, load-bearing experiments."
That's exactly what Sidney Farber did in Boston Children's Hospital btw in late 1940. One of his tests fast forwarded cancer.
I think its practical to solve cancer on a war footing where we would expect people to die.
And Farber's methods were pretty fast for his time - lol Farber would be a perfect name for this AI that wants to solve cancer knowing what's at risk.
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.
> 9 coders
How do you do that? If I let just 2 agents work in parallel they keep stepping on each other, waiting for each other and the perf tests become super noisy (because they run them in parallel)
Plans and git worktrees. If you (or anyone else here) want more info than that, give me a way to reach out and I'm happy to help. I regularly run 40+ subagents sustained in parallel (productively) without toe-stepping or any significant rework.
Stepping on each other how? I find each agent needs to spin up N worktrees for each task, and I use hooks to prevent them working on the same substrait.
You’re not running tests in CI? The agent should only run the minimum tests necessary and then idle and wait for feedback from a CI run.
Better planning, specs, and defined agent tasks with skills and logical and technical separation.
We build modular systems with plans. One developer (not agent) with Claude Code executes their portion of the plan and everything else is normal monorepo business.
Because agents != coders
You obviously need another agent that is the only one that can run perf tests.
Turtles all the way down.
Man-month or man-minute doesn't make any difference.
Can you add 27 more coders and cut the app build period down to 25% of what it was?
9 isn't a large number of people and its fairly well agreed on maximum limit for productive team size (the limit can be lower than 9) due to the number of possible communication channels. All that has changed is that a 9 person team can now do more with AI assistance then they could without it.
> Claude Code can build that application in an unprecedentedly short period
Yes, with the caveat that the application doesn't actually work.
P.S. If you wrote non-working applications even before the age of AI, then this is an upgrade, I guess.
These replies are getting exhausting. We’re well-passed generating high quality code using GenAI.
If you think we’re still dealing with hallucinations or fake code, then you’re experiences are about 8 months behind.
> then you’re experiences are about 8 months behind
I've been hearing this excuse for the past five years, bro.
When will AI finally be a real boy? Gimme a real date so I can make fun of you.
I have a team of devs proving a significant increase in velocity while maintaining quality.
But it’s private corporate work so I can only suggest you keep an open mind and actually research the effectiveness of GrnAI in application construction.
I mean, 8 months ago Anthropic made Claude build a C compiler autonomously, and the crowd came to the autonomous repo and threw a shitposting party making fun of the build failing for some time (it fixed itself in a few days but nobody cared anymore, partying was the entire point). Half a year later we had people porting huge million-LoC projects to different platforms, they run and literally have bug-to-bug parity. It's tedious work that doesn't need deep thinking but has clearly defined goals and can be iterated upon, so it's a good fit for current AI. If your expectation of vibecoded software is it doesn't actually work (as you said above) then you really need to update it. Internals might be a horror, but it does work and it's not broken. This wasn't the case a few months ago.
And yet here I am, playing a full-fledged first-person shooter written from scratch by an LLM as a proof of concept. It has enemies I sketched on paper, everything else is 100% procedurally generated in code. In what way does it not work? It's not very good, it's not optimized for maintenance or extension (that would take a complete rework which is also cheaper with it), but it does work and is not broken because the agent tested the most obvious scenarios. It took it a few hours.
As soon as your spec has a clearly defined reachable goal and non-contradictory constraints, and doesn't require taste or judgement, current agents are pretty good at reaching it, because it's all they're optimized for. Writing that spec in a non-contradictory manner is not trivial, though.
Disposable prototypes were the goal in some cases.
Also, FPS is a done to death concept that has plenty of repos for LLMs to take snippets from. A better test would be trying to vibe-coding an original game (e.g. something like Miegacure) and see how well LLM does, even when you give it well-defined goal and constraints. My guess is that would fail miserably.
I am "creating", at least designing, games with my kids. It's not that I couldn't possibly do it before, but I certainly would never have the time to.
I explored frameworks and engines, and landed on Bevy, I asked for a rudimentary arena, isometric perspective, 4 players, xinput support, portable desktop and wasm targets.
After that part done we've made the characters into chickens using no assets, only primitive mesh, having a trail of feathers, flapping wings on jump/double jump as well as gliding, picking animation, bite/grab, zenith shadows on characters (despite being unrealistic, in favor of platforming), physics objects, a few game modes like soccer, bowling, etc.
Each of these were iterative additions, so it's like previous development, only the coding/debugging time is largely removed. Is there bloat? Absolutely. But it still works, and while it's not a "real" game yet, I do believe it's original, it's certainly evolving exactly to our design, however confused it is.
>In what way does it not work? It's not very good, it's not optimized for maintenance or extension (that would take a complete rework which is also cheaper with it), but it does work and is not broken because the agent tested the most obvious scenarios. It took it a few hours.
Was your purpose to "make a basic FPS template that barely works", or "make a fun game that can sell and appeal to a specific audience"?
If more people were honest about the former reason and not trying to play it off as the latter, then maybe LLM's wouldn't have its reputation among comsumers as "slop". Making a protoype of a basic functional FPS was never the hard problem to solve. UE5's sample project does that for you. These days Roblox/UEFN also does that for you.
As I implied with "proof of concept", the purpose was to see if it works at all, not to make a game. It made mistakes and autonomously fixed them. Just a few months before, agents weren't able to do this. Now they're able to reach the goals you set, as long as they're definite, you're not making immovable objects collide with unstoppable forces, and the search space is not very diverse.
> In what way does it not work?
It doesn't fulfill its primary purpose of being a (fun) game.
> It doesn't fulfill its primary purpose of being a (fun) game.
A fun game isn't made when you're working on the engine & tech.
It is only made when everywhere else has been done, & when the feedback mechanisms are tightened. This will never happen in the prototyping stage, because the point is to make the thing exist in the first place.
------
This comment is the same Reddit-style one-off critique that makes no actual sense when placed at the grindstone, made by people that have never actually tried to make one with OR without.
TL;DR - you didn't make a game, but lied on the Internet that you did.
??? I don't see anyone claiming they made a game, let alone a "fun" one, you're replying to something that is not in this thread. The claim was that the agent wrote a program with clearly defined constraints and it works according to spec because it dutifully tested it and iterated on incorrect code. It's not bugged, it doesn't crash or anything like that.
There is a difference between building a product and building a product that sells. So, which one are we talking about here? In my opinion MMM talks about the latter
If you can vibecode a product that sells, I can vibecode a free open source one just as easily, probably even easier since I can just ask the AI to copy the existing one. Software is trending towards being free and open source.
Yeah, and then who maintains it?
Maintaining vibe coded software is going to become hours spent with Claude not your users.
That's going to be the difference. It takes nothing to rebuild the software, but listening to users, iterating, handling issues. That's boring.
The ones that win will be the ones that stay the course, not the ones that were built the quickest.
I mean, you can also use agents to listen to users and handle issues automatically.
But I guess you mean the discovery part? Yea, agents are not going to totally replace that anytime soon. Though, Claude voice mode is pretty good these days, so I’m sure it’s on their mind.
Not sure what you mean by “stay the course.” I think the winners will be those with the most effective marketing strategies. Surely that will require automation.
Half of the value in open source was that it was used by lots of people and all of the nasty edge cases and bugs have been ironed out.
If LLMs were performing according to hype then yes, virtually all paid software would be gone by now and there would be a high quality FOSS equivalent of all of it.
In the good old days that was called 'piracy'.
Unclear if this is that. If someone makes their own FOSS Photoshop, that's not piracy, it's GIMP. Training a AI on things that one otherwise has lawful access to (and not, e.g., pirating the material which Meta is being sued over and Anthropic settled over) has been ruled lawful.
Is asking an LLM to "make an open-source Photoshop clone" more like GIMP, or more like opening someone else's photo in Photoshop and clicking the menu option for the filter to make it look like a stained glass window and claiming the stained glass window version is your own IP that doesn't need permission from the original creator?
We may need new IP laws. Or, to the horror of many software developers 20 years ago, software patents.
And "new IP laws" doesn't mean "stronger": the justification for giving creators a monopoly on their works (the right to copy, or copyright) is to encourage more. If we've got a machine to automate this, there's suddenly no reason to encourage more.
Decompiling binaries and building something very similar is surely an act of piracy.
It might be, depending on what the LLM used the binary for. Patented algorithms? Yes. File format compatibility? Quite possibly not.
But what about when they're only given the user manual and told to implement it?
And extra "fun", given that "hack HuggingFace" wasn't part of the thing being tested when OpenAI's LLM did exactly that: what happens when the LLM decides the best way to implement the user manual is to decompile the binary?
That’s only really done for video games where you want an identical clone. The vibecoded photoshops aren’t decomps. They are just asking LLMs to build photoshop from scratch in rust.
You can't prove that point,because model training data is opaque.
If you've got 9 coders, you've at least got a business idea and some financial backing.
Get it out quickly, market it, iterate it. That hasn't changed. Just the speed of iteration before you go from product to product that sells.
Once you know what sells, then again, it takes far less time to rebuild it well if you need to.
This does not apply in all cases.
Case in point: I am building a digital files archive organizer platform.
This is simply not the kind of product you do a quick prototype of, get it to market quickly, and iterate on based on any failures or issues.
There are an almost infinite number of ways to get the product wrong, in a technical, architectural, and business/market sense. It requires a lot of deep thinking and internal prototyping to even get at what would actually be useful and address the walled-content-silos problem tech vendors love to foist on us. it requires careful implementation to not mess up user data. It requires a ton of architectural and UX design to get a performant product that is easy to understand. I have mulled over architectural decisions for months and thrown them out totally after mounting evidence they were not right, without a single user yet (except myself).
Just quickly coding up the first ideas that come to mind in this space is almost guaranteed to be wasted effort, because I could try a 100 approaches in the market and all could be bad. Do not let the users do your work for you. Make sure you actually understand what you are building and why it is important. Then let the user's experiences tell you how to tweak it to be better.
> 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.
Mm, I think this is quite overstated in the era of Opus 5 / Sol.
What we actually see is that agents are much better at coordinating than humans. Numbers from OpenAI show 4x the agents gives 2x the speed.
Of course, for truly single-threaded tasks you can’t gain much by parallelizing, but ask Fable/Astra to chop a big task into small pieces, write the APIs first, then sub-agents take what’s behind the API, and you’ll usually get a much better speedup than if you asked humans to work this way.
In practice most big projects have crux choke points and then fanout migration/buildout phases.
Even on the cruxes, where you need a single decision, agents don’t have ego and so you can get speedups by eg. asking for 10 clean room implementations of the same problem, and have a judge model pick the best; this can let you go much faster, and no human team would put up with that collaboration model.
Yes the latest models are pretty good at orchestration, if you instead open 9 chats and let them loose on your code base on different tasks without telling them about eachother you get a mess. If you tell one agent to spawn subagents as needed to do the implementation you get much better results.
agents are certainly not better at coordinating than the animals that built them and the entire world of systems around them.
> But someone nudged me: can't you have a look at it?
> My reply: "Haha sorry no! My experience is that adding more people will not solve this problem any quicker".
That seems like snark, bordering on pedantry, and makes one come across as an ass. If they know the answer, or can deduce it faster than any of the others, then it will definitely solve the problem quicker. Much depends on the qualifications and experience of those currently trying to solve the problem.
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.
> generate 100 solutions cheaply without coordination between them and pick the winner with a relatively fast eval
While it might get workable results, this seems like a miserable way to work with code. You spend the vast majority of time thinking about the problem domain of working with agents instead of your project, and for mediocre output. You are transforming your role into a dumpster diver of code.
The approach that proves to be fastest in the long run is to stay close to the code. Lay out the base structure, and use an LLM to check your work and fill in the gaps. The beauty of this approach is that it scales very well with the size of the project. When the LLM has plenty of high quality examples to follow, they start to write the same code that you would. Where it diverges, create documentation.
Perhaps the single best property of LLMs is their ability to consume and apply examples and documentation.
Brooks covers this case himself in chapter 2. He says men and months are interchangeable only when a task can be partitioned among many workers with no communication among them, and his examples are reaping wheat and picking cotton. 100 independent attempts are exactly that kind of task. He would have agreed they scale.
But the work doesn't go away, it moves. Someone still has to judge the 100 results, pick one and integrate it with everything else. That part doesn't partition, and it's where Brooks put most of the schedule anyway: in the same chapter his rule of thumb gives a sixth to coding and half to testing.
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.
It seems to me that Brooks' point was that it took time for new developers in an existing team to understand what work had already been done. They also needed time to understand the state of evolving or unclear requirements, as OP points out.
My small experience with AI makes me think that it can analyze and understand requirements and code very quickly, so I suspect that Brooks' maxim may not apply to AI.
> 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.
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.
I also think the context of building software matters quite a bit as well.
In a big corporation where ownership is fragmented and initiatives that are big enough for the mythical man-month problem to become tangible, big part of the problem becomes aligning the different engineering teams around why something should be built now, why team X and not team Y should do it, doing it securely and having enough confidence for a release.
In my experience, you choose the key difficult parts first, and build a small toy version. From that action, you learn which parts of the interfaces are common, and may undergo modularization with a clean design pattern.
Ultimately with sanity checking, sanitized marshaling, and constraint programming... the underlying security model is naturally enforced within the pattern itself.
The deceptively simple systems are more like an ant colony or bee hive. =3
I nowadays vibecode entire apps to see what I want. Then I go build it
Sure, works if there is a statistically salient documented solution to glean in the LLM, or a de-compiled meta-circular generated clone. As long as one avoids the $9Tn of FOSS code other people wrote, than you should be fine.
Good luck with that. =3
Actually more AI agents do the work faster and cheaper.
I use such orchestration for those 2 reasons. One, a supervisor model like Opus 5.5 (or fable before they lobotomised it) limited to 200k of context and told to keep it's progress updated in a text file is smart enough to understand the whole task.
It farms smaller sub tasks to a fleet of 7 Qwen3.8-Flash-Next agents. Not only it uses up 10% of the tokens opus would use those 7 agents run at an aggregate rate of 200tok/s. While opus would run at few dozen at most.
The Qwen in this example runs locally. If you don't mind sending your code to China you can spin a bunch of DeepSeek Flash agents and each will run at ~150-200t/s. Then your task gets done way, way faster
Baseten has flash at 800t/s.
I am at a point where I would actually prefer to be the critic than the author.
If you told me my only job was to review PRs created by something like gpt6.1 on xhigh, I would have very little problem with this. As long as the upstream issues are kicked off by a human who is ultimately responsible for the outcome.
PR reviews can go very quickly if you get out of the ideology of owning every single line of code and begin focusing more attention on the data, schema and other structural elements of the solution.
I'm right there with you. And as I find things in reviews, I kick off sessions to setup guardrails so I hopefully never have to make the same comment twice.
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
I can't believe I'm nitpicking proverbs, but making a sound with one hand isn't witchcraft.
To the core message of it, if we really need to stick to one liners, "go alone to go fast, go together to go far" would be an easier philosophy to adhere to perhaps.
Reminds me of my wife chatting with this guy at a party and we were complaining about money problems and she says this proverb she had learned recently and said, "a man is rich if he has two hands".
Turns out the other person was Albie Sachs who was a hero and had his hand blown off during the apartheid era and took both arms out of his pockets and raised them up and said "I guess I'm not rich then" - that was some serious gallows humor :-)
Oh,that turned out to be quite an unfortunate coincidence :)
Your proverb holds up talking about complementary work.
I think the Mythical Man Month specifically refers to piling on workers of the same skill set (i.e. engineers)
> "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.
Not that I disagree with the point the author is trying to make vis-a-vis Brooks' Law, but there's another narrative at play here that I find more interesting.
> But someone nudged me: can't you have a look at it?
Clearly this person has some combination of thinking the people already looking don't know what they're doing, and the author being a technical person will be better at it.
From the author's side there is little interest in engaging, perhaps because of a desire not to feed the help vampires, or maybe the meeting is low enough value that an unintentional filibuster is not such a bad thing, or any number of other situational reasons that I can imagine but are not discernible from the context given. Human psychology is fascinating.
I disagree, I think one of the big problems in science (which also applies to IT, although to a lesser degree) is that a lot of time and resources are lost researching things that don't work, getting no results, and not publishing these lack of results. However, agents can potentially communicate much better and know what other agents have tried, so they don't waste their time on those dead ends. They are also potentially able to divide work more efficiently.
"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.
What about reliability and simplicity? First, what is your definition of productivity? Does it leans towards more output or more value.
Not my definition, the quote is from Brooks - “Productivity is stated in terms of debugged words per man-year.” He also writes about the limitations of this definition. But I can confirm, debugged words per man year has gone up more than 10x for many engineers.
In my experience reliability and simplicity have decreased, LOC for every feature is at least 2x what it was, more incidents than ever before. What kills me is if we just applied llm programming to the old ways of doing things and got our minor speedup but refined our approach, got ai to catch things we normally wouldn’t, did the extra refactor we normally wouldn’t we could increase reliability and simplicity. But management wants the velocity more than those things.
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?
No human goes “gee wall is soaking wet with fresh paint, maybe this is the one I need to paint”
Don't forget to tell the agent to never generate buggy code.
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
I’m increasingly curious if revisiting Brooks’ surgical team makes sense in this age. Knowledge transfer has always been a bottleneck, but in this time it is often just no longer worth it (compared to the old world where the costs were justified by increased manpower for execution of an idea).
Unpopular opinion for this site: Most true facts are not affected by the existence of AI. Most things in life do not need adjustment for "the age of AI".
For decades, eery tech boom cycle is filled with people who don't understand the mythical man month, or that LOC is not a productivity metric. The AI boom is no exception. AI has not invalidated this.
“The wrong answer, faster” is usually a major win for any business
Most bosses manage by running around telling everyone to do it faster or cheaper. Never have I heard a manager telling someone to do it better or more correctly.
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.
Yes, from the title referencing MMM, I had hoped this would be the angle explored. My experience is that the optimal number of engineers for most projects is currently one, as the cost of creating bespoke automated dev workflows decreases. Even for larger, more complex projects, I suspect one person plus time spent codifying knowledge and automating processes will outperform a larger team.
The Mythical Token-Minute.
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.
Git Worktress, Sub Agent WIth Team Leader agents. I get things done alot faster, You are just doing it wrong.
Ime the work is still a dag and there are still bottle necks when inter task dependencies exist
Great analogy - nine agents still can’t deliver a baby in one month.
Is it just me or is this article itself AI? Or is everyone just adopting the AI tone and writing style now?
Which bits of tone felt AI to you? It didn't set off my internal "ai-detector", not that I'm an expert or anything.
Pretty much the whole thing. Also I checked just now and the AI detection services say its from 60-90% AI written lol
It's not just you, I'm pretty sure at least the second part of this short text is AI written.
By the way writing a short note on your "personal" blog using AI is beyond pathetic.
How about RSI? Recursive Self Improvement? I wonder the author's view on that.
Most people have no view on that, or dismiss it either as a cultish/outlandish topic or something so far into the future it's not worth discussing. The author most likely falls into these categories otherwise his point would be mute.
FYI it's "moot", not "mute" here.
Would an unlimited context window enable you to solve all requests instantly ? No
the bottleneck is now how fast can you plan requirements, how fast can you check those requirements were met. Stack : Greptile + TesterArmy
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
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.
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!
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.
Yeah I'm just gonna say you're dead wrong and leave it at that.
In the AI agent era, we might end up introducing “agent-month” instead of “man-month.” The more agents you add, the longer the work takes.
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.
I don’t „talk” to my agents. I tell them what to do. If I need to „talk” it means something is going wrong and we need to figure out why agents are doing bad work - and this is intellectually challenging.
The effect you describe I had at times but with older/dumber models where you could spend a ton of time and the model was either too dumb to do it, or had a model dementia later in the context. Or when I didn’t really understand why it did a bad job and tried to stumble around in the dark - very mentally numbing.
Nowadays the model usually just had some bad tools or information required to do the job.
If you're not even asking the questions, you probably don't know what it's writing. That's essentially the same as saying you don't care about the quality of what you produce.
That's not new, it's just not something most people would've admitted to until recently.
> I don’t „talk” to my agents.
Though, if you're still typing, you might want to try recent STT software.
Oh yes, Whisper/Whisperflow in some places, and Groq from Elevenlabs in some other ones. It's hard to get back to typing.
The biggest challenge is in an office, or other places where I want to maintain privacy. Ideas?
By "telling" vs "talking" I meant - I have a setup that is 95% noninteractive - oneshotting most tasks, with a decent verification setup and a good memory/hooks to be confident the system does what I want and is reliable.
When something off happens, I spin up an after action review session that pinpoints the guilty sessions, interviews them, the whole investigation, and either handles improvements in the process by itself (most of the cases), or asks me for feedback. For the last three months I don't think I had a place where my input was really needed. But the beginnings were brutal.
"talking" happens only when:
- I truly need to iterate on the output
- There is some frontier-level research (i.e. working on truly novel algorithms/math)
- New UX - even Sonnet5.5 and Fable are still quite schematic and they have difficulty figuring things out from first principles. Astra is smarter but has it's own problems
- Infrastructure problems
Doing more, understanding more the tech of the project, exploring more ideas, the list is infinite
Who got more time thanks to AI ? I think a lot of us are working more instead
You need to switch into a product manager/QA/UI,UX mindset.
Is what is being built the right thing? Does it work? Is it usable? Has it been built in an appropriate way? (Note this is not a code thing, it’s an architectural question)
Traditionally developers have outsourced these things to other people.
There’s a further thing you should be doing - if the questions above didn’t pass - why not? What went wrong in your process?
> keep your mind exercised
OK, so I'm still very low on the spectrum of "I just command it and sit back", but I think the final toolbox will at least include adversarial questioning of the bot. For example, "Why does that code do A, wouldn't B be better?" or "Would this code break if a C event occurred?"
Sometimes it reveals a bug or a questionable implicit assumption, other times it leads me to see another part of the code, and sometimes the thing just lies at me... But it does help you keep some critical-thinking practice.
Another task might be to find and refactor/rename parts of the code that are just... not easy for humans to grasp. Some readers are thinking: "No, the next edit will be by LLM anyway, leave it so the bot understands", however I think that's short-sighted: Either these things are going to become good-enough that they should cater to human comprehension, or else they've reached a plateau and we'll want something that can resist the chaos-rot.
I think I'm where you are. Reading all the code it spits out, and then a lot of adversarial questioning. (This is what I mean about "talking to the AI", which was brushed off by another commenter). Naming conventions, decisions about classes or inline code, all these things I would not do.
So then I spend all this time getting a mental map of the code it wrote, and making my own decisions about that code. Then I ask it to rearrange it in consistent ways. Then I find bugs or oversights. Etc.
What I'm trying to say is that while all of that process with the LLM is modestly intellectually stimulating, it's not as stimulating as just writing the code myself, and it's also incredibly frustrating to have to go through the agent. And yes, I could just rewrite the functions my own way, but once I'm in a project that's LLM-driven, the temptation is to make the LLM fix it instead of fixing it myself. Whereas in a project that I'm writing from scratch, I wouldn't make those mistakes or have to think about those stylistic things, I would have already seen the bugs that it missed before I wrote the code, and I would be using my mind to its fullest potential instead of delegating my thinking to a stupid robot.
Running 20 agents at the same time means a lot more task switching, its closer to team management, you may have one agent doing basic grunt work, so can be let alone, another one may be planning and designing, so needs a little bit more q&a, and others may be problem solving, and that does take a lot more supervision. But I have never felt like I have any free time, or down time, at the end of the day I feel far more mentily exhausted (in a good way) than any day before agentic development.
>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?
If you have a lot more free time you're not taking full advantage of agents. The time saved coding allows working on 4-6 projects simultaneously, and the majority of work is the hard design/product decisions that the agents can't do well themselves. Working on the hard parts of half a dozen projects simultaneously is far more mentally taxing than just hand-coding a single project, and with that many agents there'll usually always be one with a question for you so you won't have much extra free time.
The majority of my time coding is not coding; it's thinking through the hard design/product decisions, as you said (or how business logic flows through the UI). The time coding is very, very explicitly putting those decisions into UI and backend logic in a way that would take me longer to explain perfectly to a bot than it does to code. LLMs have not saved me time on any serious project, aside from helping to scaffold things, because the results when I ask them to write a block are sub-par.
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.
Not only that but there is limited number of good prompts/design decisions per employee per day.
> 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?
To whit, 13,000 women can make a baby in one month. If you hire that many women, by the statistics, that's how many it takes for one of them to be 8 months pregnant.
Agents still have to communicate using tokens (for now). There are more advanced mechanisms being proposed, but for now, and until proven otherwise, the same scaling problems apply to agents communicating as humans, it just happens a bit faster, and with no HR issues because someone slept with the wrong person. Mesh networking, and thus agents too, are beholden to Gupta-Kumar scaling law.
It's a weird way to express that concept, in fact I don't think it ever appeared like this in the book (it has been a while).
It would be something like "nine women cannot deliver a baby in one month", which can be more easily transposed to "adding resources to a SW project does not make it faster".
The agrument is that adding people increase coordination and communication overhead, which gets bigger as the team grows. Moreover, some tasks cannot be parallelized that easily and create dependencies.
I have only worked with agents for personal projects, but I cannot say that explicity dividing the work between multiple agents and asking them to coordinate is inherently faster than having a single agent work on it (of course the single agent will spawn subagents in rencent harnesses.)
I always thought it meant 9 women would take 9 months to create 9 babies because a baby takes 9 months to grow with the bottleneck being biology. And yes what you said applies to people but I don't get the whole "throw 9 agents into it" when it is possible to just see it as 1 agent doing 9 things? With people, yes everyone has a distinct way of doing things etc but all agents can be homogenious fully and completely sync up without any overload theoritically no?
Are you aware of the original saying?
It's a metaphor for some tasks being inherently serial, so no amount of parallelism will make them complete faster.
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?
I think Brooks' ideas of conceptual integrity or the surgical team are more interesting in the context of AI than the man-month.
Certain projects will really benefit from one person being able to more fully impose their vision for longer.
I disagree with DHH on a lot, but he's definitely going an interesting place with Omarchy because he can do so much "himself".
I’ve always hated that book. It was a cope to blame management for every poor outcome. “We didn’t ship because leadership gave us too many resources”. Sorry that your steak is too juicy and your sheets are too soft.
There are a hundred other reasons that software is late. You have to be brain dead to think that putting more people on the job is even in the top 10 .
at my current job alone, i can count over 5 times in the last 5 years where mgmt threw people at a problem and didn't actually help if not hurt.
now, leadership will never admit they're wrong and they act like they're heroes. but i can confidently say that they made things worse.
if they are giving you resources and you can't deliver, that's on you
the problems were due to their decisions a year before. some problems can't be solved with a half dozen extra sets of hands.
mythical man month also applies here. people with no context cost something to get ramped up.
see what I mean?
lol okay i'm glad you're enjoying defending execs you don't even know.
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.
I think it takes MORE attention and thought. I feel like a rope being pulled tight and fraying in the middle. Working with these things is very addictive and interesting but it is cognitively exhausting long term, even if invigorating in the short term.
It does require that the human driver knows what they are doing. It captures the pre-AI developer mindset of developing a mental model along side writing the code. This has always been iterative, in discovering the model that results in high cohesion and low coupling.
That doesn't work if the driver cannot steer properly. It's the main issue with vibe-coded one-shotted solutions, that might look impressive until you peek underneath and it's all a mess.
I get a feeling that the best way we currently know how to use these tools is to not read their code at all. Models code and models review. Humans just ask questions and guide. Claude Code has no code editor on purpose.
Is this sustainable? I've got no idea.
As long as you are accountable, you need to understand the code. There’s just no way “But I told the LLM to make the code secure” is an acceptable explanation for a security breach.
You might be surprised to learn that yes, regularly pointing a tool at the codebase and seeing it found no issues is indeed enough to claim compliance with cybersecurity regulations.
While we may use deterministic tools like static code analysis, dependency scanners and similar today, people are already replacing/augmenting them with LLMs.
While every breach will trigger a root cause analysis process in a compliant environment, the solution is never going to be "all code in a deployment was manually reviewed by someone at the company" because this would extend to tooling (like compilers, scanners but also packaging and deployment tools) and all dependencies.
So I am pretty sure your example is already used in a number of places especially with "LLMs are better at security than humans" marketing being pushed around — this really makes it easy to sell that excuse to the gullible management who wants to believe this.