https://thetechenabler.substack.com/p/the-mythical-ai-agent-month The Tech Enabler The Tech Enabler SubscribeSign in The mythical AI-agent month Noah Hall's avatar Noah Hall Jan 31, 2026 1 Share "The Mythical Man Month" used to be required reading at many universities for computer scientists. The book states adding more humans to a project did not reduce the time to complete, but rather increased it. Yet with the advent of AI coding agents, it seems to me like some people have thrown it out the window. Brooke's law: Adding manpower to a late software project makes it later. As the manpower for a project increases, the amount of coordination increases. A team of 8 people will often find themselves needing to fix merge conflicts, talk with each other about features or bugs, and decide who works on what and when. A single person project might produce less overall code, but the entire context lives inside that person's mind. Adding one extra person completely changes the dynamic. "2-pizza teams" are approximately 8 people, usually with some split expertise. The overhead is substantial, but many find it a good balance between overhead and production. Open source projects scale to many more contributors, but the number of core contributors remains relatively low. There just aren't that many people who know the codebase in-and-out to the extent that mass collaboration is possible, therefore pushing collaboration to the conceptual level, or one-off-issues. The bus number for a single person project is 1. Far too low for anything intended for large scale production. If that person is gone, the project is dead. Even for huge open source projects like the Linux kernel, the bus factor is very low. It is difficult for contributors to have the complete overview. The evidence from corporate and open source coding reveals a learning: a well maintained project cannot have hundreds of key people, but it also can't have one key person only. Over time, teams or open source communities identify better ways to work together. If they don't, then they stop existing. Routines, habits, and interactions become codified as a way of working. So what does all this mean in the context of AI agents? First, let me try to define my personal definition for the sensible production use of generative AI for code. What does generative AI do? It takes some input, usually text, and produces an output, usually text. This is not anything new. Parsers and compilers have existed as long as high-level programming languages have. Is the logic linear? Is the logic repeatable? Nope. It is more similar to search than a parser - ephemeral results from a known input. It is not deterministic. IDEs have had auto-complete for decades. Generative AI is a fancy auto-complete that seems intelligent. But it's not intelligent. "Reasoning models" don't reason. "Thinking models" don't think. They take text, run it through a model trained on code, and produce similar output to what they have been trained on. Therefore, I would define sensible production use of generative AI for code as "the use of AI to produce code in a controlled manner such as an auto-complete suggestion, or search, with a human software engineer in the loop". If AI for coding is used sensibly, a software engineering human will review and own the code before it is pushed to production. The AI produced code becomes just another way for a software engineer to transfer their ideas into code. AI auto-completion falls into this category. The software engineer takes responsibility for any bugs or security issues introduced through their code. There is no additional manpower added to the project, but the manpower may get more efficient. Brooke's law does not apply in this case. But the flow with AI agents is substantially different. Rather than an auto-complete, AI agents go away, figure out some code they deliver, and the human's input is minimal except for describing the feature and finally reviewing the code. The output of the AI agents adds "AI power" to the project, which triggers Brooke's law. A human may merge the code, and therefore take responsibility, but here's the thing: software engineers are bad at reviewing code they didn't write. A sensible project will require strict reviews, QA, testing of any AI produced code. Humans are just not good enough at reviewing code. Maybe one day we will be, but the tools we have available to us today are built with producing code in mind, not reviewing code. I've used and tested AI agents. I've read the docs, I've listened to people who claim they're able to produce high value code through them. I suspect I have a higher threshold for code merges than most people, particularly on solo projects. AI agents are being hyped as a way to code without needing to write it yourself. Spin up an AI agent, send it off, done. I have not found that to be true. Every single change and commit needs manual verification. Every single change and commit has the potential to introduce code so harmful to the codebase, either due to poor readability or poor implementation, that I have reflected multiple times why does anyone do this? Why am I doing this? I could've saved myself time by writing it myself. [https] I acknowledge that my own threshold to merge might not be the same as others. However, there's some things I value both in my own work, and the work of others. * Minimalism. Code that only exists because it has to. Low-noise, high-signal. * Architecture driven by good types and data structures. * Changes that are easy to understand or rollback. * Security as a guiding principle, not an after-thought. * Human verified. Natural ways to interact with the product (e.g CLI, TUI, GUI, APIs). * Code I can read, understand, and change. The AI agents I've tried have all failed in these regards. Even with instructions, they have produced incredibly noisy code. Inventing new functions when a function already exists that will serve the purpose. Comments that mean nothing. Inlining code where it adds nothing. Types which have been ignored. Repeated bad habits that I would expect a junior to learn from. Changes which are just too big to understand. Pull requests that end up with hundreds of comments before it's worth merging. Security issues while asserting "this code has been generated with security in mind". Agents that tell you confidently "I've fixed the problem", while the problem is still clearly there. I would be ashamed to push that code to production. But most concerning, AI-produced code that would slow down the humans working on the project. Either as the reviewer, or as the poor soul who would then have to work with such a codebase. Suddenly the overhead increases from beyond merge conflicts, or schedule management. It becomes a factor of something unintelligent made this code. Something, not someone. Something that doesn't actually understand what it did, or why. Something ephemeral, where learnings are brief unless it is retrained or has added context. Something that can't take responsibility. Therefore, the overhead with AI agents is larger than that of a human. And no, getting AI agents to review code made by other AI agents is not a fix for the problem. It just means you're shipping code you don't understand, but you are responsible for. Just like the mythical man month, the mythical "AI agent" month remains just that: mythical. Not everyone will realize the myth right now. But in 2 years time, when they can't find anyone to work on their nightmare codebases, they will. [ ] Subscribe Share 1 Share Previous Discussion about this post CommentsRestacks User's avatar [ ] [ ] [ ] [ ] TopLatestDiscussions No posts Ready for more? [ ] Subscribe (c) 2026 Noah Hall * Privacy [?] Terms [?] Collection notice Start your SubstackGet the app Substack is the home for great culture This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts