Raw capture â raw/the-mythical-agent-month.md
url: https://wesmckinney.com/blog/mythical-agent-month/ date_fetched: 2026-07-05 backfilled: true
Like a lot of people, Iâve found that AI is terrible for my sleep schedule. In the past Iâd wake up briefly at 4 or 4:30 in the morning to have a sip of water or use the bathroom; now I have trouble going back to sleep. I could be doing things. Before I would get a solid 7-8 hours a night; now Iâm lucky when I get 6. Iâve largely stopped fighting it: now when Iâm rolling around restlessly in bed at 5:07am with ideas to feed my AI coding agents, I just get up and start my day.
Among my inner circle of engineering and data science friends, there is a lot of discussion about how long our competitive edge as humans will last. Will having good ideas (and lots of them) still matter as the agents begin having better ideas themselves? The human-expert-in-the-loop feels essential now to get good results from the agents, but how long will that last until our wildest ideas can be turned into working, tasteful software while we sleep? Will it be a gentle obsolescence where we happily hand off the reins or something else?
For now, I feel needed. I donât describe the way I work now as âvibe codingâ as this sounds like a pejorative âprompt and chillâ way of building AI slop software projects. Iâve been building tools like roborev to bring rigor and continuous supervision to my parallel agent sessions, and to heavily scrutinize the work that my agents are doing. With this radical new way of working it is hard not to be contemplative about the future of software engineering.
Probably the book Iâve referenced the most in my career is The Mythical Man-Month by Fred Brooks, whose now-famous Brooksâs Law argues that âadding manpower to a late software project makes it laterâ. Lately I find myself asking whether the lessons from this book are applicable in this new era of agentic development. Will a talented developer orchestrating a swarm of AI agents be able to build complex software faster and better, and will the short term productivity gains lead to long term project success? Or will we run into the same bottlenecks â scope creep, architectural drift, and coordination overhead â that have plagued software teams for decades?
One of Brooksâs central arguments is that small teams of elite people outperform large teams of average ones, with one âchief surgeonâ supported by specialists. This leads to a high degree of conceptual integrity about the system design, as if âone mind designed it, even if many people built itâ.
Agentic engineering appears to amplify these problems, since the quality of the software being built is now only as good as the humans in the loop curating and refining specs, saying yes or no to features, and taming unnecessary code and architectural complexity. One of the metaphors in TMMM is the âtar pitâ: âeveryone can see the beasts struggling in it, and it looks like any one of them could easily free itself, but the tar holds them all together.â Now, we have a new âagentic tar pitâ where our parallel Claude Code sessions and git worktrees are engaged in combat with the code bloat and incidental complexity generated by their virtual colleagues. You can systematically refactor, but invariably an agentic codebase will end up larger and more overwrought than anything built by human hand. This is technical debt on an unprecedented scale, accrued at machine speed.
In TMMM, Brooks observed that a working program is maybe 1/9th the way to a programming product, one that has the necessary testing, documentation, hardening against edge cases, and is maintainable by someone other than its author. Agents are now making the âworking programâ (or âappears-to-workâ program, more accurately) a great deal more accessible, though many newly-minted AI vibe coders clearly underestimate the work involved with going from prototype to production.
These problems compound when considering the closely-related Conwayâs Law, which asserts that the architecture of software systems tends to resemble the organizationsâ team or communication structure. What does that look like when applied to a virtual âteamâ of agents with no persistent memory and no shared understanding of the system they are building?
Another âbig ideaâ from TMMM that has stuck with people is the n(n-1)/2 coordination problem as teams scale. With agentic engineering, there are fewer humans involved, so the coordination problem doesnât disappear but rather changes shape. Different agent sessions may produce contradictory plans that humans have to reconcile. Iâll leave this agent orchestration question for another post.
âThere is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicityâ â âNo Silver Bulletâ (1986)
Brooks wrote a follow-up essay to TMMM to look at software design through the lens of essential complexity and accidental complexity. Essential complexity is fundamental to achieving your goal: if you made the system any simpler, it would fall short of its problem statement. Accidental complexity is everything else imposed by our tools and processes: programming languages, tools, and the layer of design and documentation to make the system understandable by engineers.
Coding agents are probably the most powerful tool ever created to tackle accidental complexity. To think: I basically do not write code anymore, and now write tons of code in a language (Go) I have never written by hand. There is a lot of discussion about whether IDEs are still going to be relevant in a year or two, when maybe all we need is a text editor to review diffs. The productivity gains are enormous, and I say this as someone burning north of 10 billion tokens a month across Claude, Codex, and Gemini.
But Brooksâs âNo Silver Bulletâ argument predicts exactly the problem Iâm experiencing in my agentic engineering: the accidental complexity is no problem at all anymore, but whatâs left is the essential complexity which was always the hard part. Agents canât reliably tell the difference. LLMs are extraordinary pattern matchers trained on the entirety of humanityâs open source software, so while they are brilliant at dealing with accidental complexity (refactor this code, write these tests, clean up this mess) they struggle with the more subtle essential design problems, which often have no precedent to pattern match against. They also often tend to introduce unnecessary complexity, generating large amounts of defensive boilerplate that is rarely needed in real-world use.
Put another way, agents are so good at attacking accidental complexity, that they generate new accidental complexity that can get in the way of the essential structure that you are trying to build. With a couple of my new projects, roborev and msgvault, I am already dealing with this problem as I begin to reach the 100 KLOC mark and watch the agents begin to chase their own tails and contextually choke on the bloated codebases they have generated. At some point beyond that (the next 100 KLOC, or 200 KLOC) things start to fall apart: every new change has to hack through the code jungle created by prior agents. Call it a âbrownfield barrierâ. At Posit we have seen agents struggle much more in 1 million-plus line codebases such as Positron, a VSCode fork. This seems to support Brooksâs complexity scaling argument.
I would hesitate to place a bet on whether the present is a ceiling or a plateau. The models are clearly getting better fast, and the problems Iâm describing here may look charmingly quaint in two years. But Brooksâs essential/accidental distinction gives me some confidence that this isnât just about the current limitations of the technology. Figuring out what to build was the hard part long before we had LLMs, and I donât see how a flawless coding agent changes that.
When generating code is free, knowing when to say ânoâ is your last defense.
With the cost of generating code now converging to zero, there is practically nothing stopping agents and their human taskmasters from pursuing all avenues that would have previously been cost- or time-prohibitive. The temptation to spend your day prompting âand now can you justâŚ?â is overwhelming. But any new generated feature or subsystem, while cheap to create, is not costless to maintain, test, debug, and reason about in the future. What seems free now carries a future contextual burden for future agent sessions, and each new bell or whistle becomes a new vector of brittleness or bugs that can harm users.
From this perspective, building great software projects maybe never was about how fast you can type the code. We can âtypeâ 10x, maybe 100x faster with agents than we could before. But we still have to make good design decisions, say no to most product ideas, maintain conceptual integrity, and know when something is âdoneâ. Agents are accelerating the âeasy partâ while paradoxically making the âhard partâ potentially even more difficult.
Agentic scope creep also seems to be actively destroying the open source software world. Now that the bar is lower than ever for contributors to jump in and offer help, projects are drowning in torrents of 3000-line âhelpfulâ PRs that add new features. As developers become increasingly hands-off and disengaged from the design and planning process, the agentsâ runaway scope creep can get out of control quickly. When the person submitting a pull request didnât write or fully read the code in it, thereâs likely no one involved whoâs truly accountable for the design decisions.
I have seen in my own work on roborev and msgvault that agents will propose overwrought solutions to problems when a simple solution would do just fine. It takes judgment to know when to intervene and how to keep the agent in check.
Brooksâs argument is that design talent and good taste are the most scarce resources, and now with agents doing all of the coding labor, I argue that these skills matter more now than ever. The bottleneck was never hands on keyboards. Now with the new âMythical Agent-Monthâ, we can reasonably conclude that design, product scoping, and taste remain the practical constraints on delivering high quality software.
The developers who thrive in this new agentic era wonât be the ones who run the most parallel sessions or burn the most tokens. Theyâll be the ones who are able to hold their projectsâ conceptual models in their mind, who are shrewd about what to build and what to leave out, and exercise taste over the enormous volume of output.
The Mythical Man-Month was published in 1975, more than fifty years ago. In that time, a lot has happened: tremendous progress in hardware performance, programming languages, development environments, cloud computing, and now large language models. The tools have changed, but the constraints are still the same.
Maybe Iâm trying to justify my own continued relevance, but the reality is more complex than that. Not all software is created equal: CRUD business productivity apps arenât the same as databases and other critical systems software. I think the median software consulting shop is completely toast. But my thesis is more about development work in the 1% tail of the distribution: problems inaccessible to most engineers. This will continue to require expert humans in the loop, even if they arenât doing much or any manual coding. As one recent adjacent example, my friend Alex Lupsasca at OpenAI and his world-class physicist collaborators were able to create a formulation of a hard physics problem and arrive at a solution with AIâs help. Without such experts in the loop, itâs much more dubious whether LLMs would be able to both pose the questions and come up with the solutions.
For now, Iâll probably still be getting out of bed at 5am to feed and tame my agents for the foreseeable future. The coding is easier now, and honestly more fun, and I can spend my time thinking about what to build rather than wrestling with the tools and systems around the engineering process.
Thanks to Martin Blais, Josh Bloom, Phillip Cloud, Jacques Nadeau and Dan Shapiro for giving feedback on drafts of this post.