The Mythical Man-Month in the Age of AI

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.

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.

"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.

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.

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.

(so you can plan instead)

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.

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?

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.

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.

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

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.

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.

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.

At some point token efficiency will bite, but even that is overrated; the metric you really should care about is:

impact / (salary + token spend)

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.

Then they aren't sequential.

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.

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.

Isn't it a common practice to use cheaper models to do the grunt work?

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.

I get great results and save tokens

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.

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)

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.

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.

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.

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

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.

I think the Mythical Man Month specifically refers to piling on workers of the same skill set (i.e. engineers)

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.

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 :-)

By the way writing a short note on your "personal" blog using AI is beyond pathetic.

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.

Who got more time thanks to AI ? I think a lot of us are working more instead

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 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.

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?

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.)

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.

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.

Is this sustainable? I've got no idea.