Hundreds of bots modifying thousands of microservices may sound good on the surface, but all those thousands of microservices make up an architecture and a product.<p>Agents aren't very good at carrying the entire model in their context, so when they reason about a small piece of code, they often come up with something that hurts other parts of the code (especially as the KLOCs pile up). The complexity hasn't been replaced, only moved. And guess what's going to happen when all of these microservices become even more of a moving target than they already are?<p>AI is capable of improving productivity, but this approach sounds more like a nightmare in the making.
The agents are like ants, and ants build like crazy until the resources run out in winter. AI winter is going to be interesting, to say the least.
Seems to me the real question is "what scheme can we use to organize our code base such that an agent working on one part really can make changes and not break the other parts on accident".<p>My current theory I might test out is to treat generative AI as <i>generative</i> AI. This means instead of editing things like a microservice in place you version freeze them to bug fixes only and create new versions for new features. This way you can go and update all the places that use the old version to the new version one at a time. As you do you can check that the new version does not break anything while still having an old version to fall back to.
A wise troll once said:<p>> best weapon against complexity spirit demon is magic word: "no"<p>In counterpoint, I believe small teams can remain small. Small teams can ship simple monoliths with high velocity, commit count, and quality. Service orientation didn’t suddenly become low-cost because of agents; the boundaries between multiple services that version and deploy independently are still tricky beasts to wrangle. And it’s not clear why “running more agents” is inherently desirable or impactful; my small team’s (admittedly anecdotal) experience is that the value quickly saturates.
My biggest issue with these type of posts is that they never answer the "why". Hell, they don't even ask the "why".<p>> The more modular your code, the more agents you can run<p>OK, but why would I want to run more agents? So I can be more productive? What does this productivity lead to? And are we actually being more productive? Take a look at Bun's repo on GitHub which seems to be fully automated. Well over 5000 PRs open.<p>What's the use? How can we justify these 5000 PRs? Over the past years, software has become considerably more shit. Are these 5000 PRs improving the quality of software?<p>Is the end-user reaping the rewards? Are they getting better software, cheaper?<p>The answer to all of those is going to be "no".<p>And let's take Uber for example. They have many teams, and many more times the services. Has ride hailing become cheaper? No. Has it become more efficient? No.<p>Nothing is getting better, but at least we're all off worse!
Yeah, I think engineering orgs mostly jumped the shark.<p>Metrics like pr count and commits have always been terrible gauges for success compared to business performance.<p>But they're easy to measure, and even easier to game now with AI.<p>So we're seeing an outrageous gain on these metrics, and they've become almost completely divorced from business results.<p>No one cares how fast you ship prs. They care that you offer a compelling product, that works when they need it work, for a price they're able and willing to pay.<p>It's like we've decided to measure how far we've traveled in gallons of gas burned, but completely forgotten about measuring miles per gallon.
> but why would I want to run more agents?<p>Notice how difficult it is to turn off photo bursts in iPhone? Because that free cloud space needs to be filled fast. So ask your question again and you will find the answer very rapidly. They even gave it a cool name, "tokenmaxxing" what even the fuck.
I find that ride hailing is both cheaper and more plentiful compared to taxis in 2010. Even in non-inflation-adjusted amounts. Ride hailing and food delivery companies provide dispatching and coordination at a very large scale effectively.<p>I agree that these companies' products were fully mature prior to usable coding agents in late 2025, so I don't understand why they would require a large volume of code changes beyond minor promotions and localization enhancements. I would expect their challenges to be in the ML, data, storage, capacity, and compute infrastructure areas.
Thank you. I do not believe the author has any idea what he is talking about, too. It's worth to also mention some basics:<p><pre><code> 1. Dependency on some outsourced LLM vendors (no Internet? No API response? Welp, you do you.);
2. Undefined amount of payments/paid subscriptions at vendors;
3. Undefined amount of tokens burnt on each prompt/iteration within undisclosed algorithms;
4. Absolutely no responsibility/copyright for the LLM output;
5. Privacy concerns on inside/company project source code uploaded;
6. Incremental eventual atrophy of developer's own skills;
7. Inhuman attitude for art, development, effort, purpose in general, since the models are built on stolen effort of other, now unknown, people...</code></pre>
Why not just bake an agent into every service and chat with it? Sounds more fun at least.
> So Uber’s approach to modularity may have seemed extreme at the time, but it could become the new normal.<p>I doubt it. This seems to conflate code modularity with service modularity. Moving complexity from the codebase into operations is counterintuitive to at least the way I use LLMs.
I'm a 1 person dev team who wrote frontend code that outperforms React.<p>Is was successful because I didn't use any sort of LLM assistance.
There's another way to get this kind of parallelism without the mess of microservices.<p>Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.
[flagged]