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.

Imo there's zero difference between 'thousands of microservices' and 'one monolith with thousands of functions/classes/etc' in terms of effort required to make it correct - both are still tiny interconnected pieces making up a whole, and you can separately unit test a function just as easily as you can separately e2e test a single microservice.

They still make up some whole product that presumably does something as a whole that you actually care about, and the complexity inherent to that doesn't go away with either approach.

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

My current theory I might test out is to treat generative AI as generative 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.

Why do you need to always modify the service? Once it is up and running and performs a function - don't touch it.

Agent spam is definitely an excercise in diminishing returns

How would the LLMs even appropriately build and manage context in such a setting?

Plan for your organizational wisdom to be passed down in the form of code, comments, and markdown documentation files... all for other agents with centaur orchestrators.

Yeah, I think engineering orgs mostly jumped the shark.

Metrics like pr count and commits have always been terrible gauges for success compared to business performance.

But they're easy to measure, and even easier to game now with AI.

So we're seeing an outrageous gain on these metrics, and they've become almost completely divorced from business results.

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.

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?

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.

Uh-huh. I have a little boy who just saw his first firetruck, and you can see the wheels turning in his head, because BIG RED TRUCK. He doesn't talk yet, but a seed has been planted.

Some people operate like little boys. They want the BIG RED TRUCK. They haven't considered that's it's really hard to park and gets 5MPG, or that their use cases don't involve fighting fires (for which they are not trained), but they want the big red truck so they can drive the big red truck.

Anyway, if you go the 5000 microservices route, you move all your problems from the application layer into networking and orchestration problems. Best of luck with that.

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.

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:

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

My ex boss who was very very pro AI would constantly say that we need to be more productive. Which triggered in me the question of "why". Aren't we producing enough as a society at this point? We have enough for everyone, and the fact that it's not being shared fairly has nothing to do with productivity. We don't need "more", we need " better". And I don't think most uses of AI will lead to that. If we lived in a more just society I think we would concentrate all the AI resources on a few key areas where it could genuinely help make things better, like medical research. We don't need more and more crud apps.

I’m a 1 person dev team that’s in the final stages of shipping a complete rewrite of a pretty big app (native frontend, server backend).

It’s going to be very successful, because I used all sorts of LLM assistance (and because it’s adding onto a successful app that’s been shipping for two years).

There’s absolutely no way that I could have managed this scale, on my own.

There will be examples of both success and failure, with LLMs.

That's pretty impressive. I always like bespoke web utilities tailored for specific dev purposes.

What approach are you taking? I'm about to start a mithril.js project, was always under the impression it was the most efficient approach. Are you doing something similar or different or are you referring to WASM?