Small software teams now generate as much code as Uber did with microservices
There's no such thing as a small software team anymore
A small team running 20-100 coding agents in parallel can generate 500 commits, 200 pushes, and 100 PRs in a day, rivaling the output of large organizations. This shift makes modular code architectures, once reserved for giants like Uber, essential for small teams to avoid merge conflicts and enable parallel agent work. As agents handle boilerplate, modularity's cost drops, making it a key design principle for modern software development.
The modularity of your codebase determines how many coding agents you can run in parallel effectively, so now it’s worth designing for it from the beginning.
- kstenerud
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.
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?
AI is capable of improving productivity, but this approach sounds more like a nightmare in the making.
- davepeck
A wise troll once said:
> best weapon against complexity spirit demon is magic word: "no"
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.
- ulrikrasmussen
I have already commented about this is probably the worst advice I have heard in a long time, and I would definitely not let this guy anywhere near a codebase I had to maintain.
But this is also essentially blogspam. The author intentionally includes two screenshots which add absolutely nothing to their point and which are too small to read. When you click the second one, you are not taken to a larger version, you are taken to the frontpage of his company website which features the same screenshot.
- whatever1
Wait two years until we have sufficient churn of senior talent in the teams. Then all of the services will have outages daily.
Only the seniors who know their systems are keeping the lights on today by keeping bs commits out.
Once they burnout and quit, nobody will have a freaking clue what the LLMs have done and why services are down.
- zkmon
I hope people don't call automations as "teams". If you are calling it a team just because it "does" work, then CPU cores and threads are also a team, though not so probabilistic (intelligent). They do get the work done.
- pranavmalvawala
Funny take. Monoliths are actually better then microservices because of the context they carry. At the end developers are supposed to run a product, not to keep mindlessly running agents just because they can
- _345
I'm really skeptical you can ship ~10 PRs a day per person unless these PRs are tiny pieces of one feature or all of them are tiny bugs that are each a 3 line fix that you could review instantly. Otherwise how can you confirm that the AI even did the right fix or feature correctly? That you even wanted that feature done that way?
- keeda
One of my predictions for software in the AI age is that we will end up with nano-services. The thinking is this:
1. LLMs perform best with tight, focused context.
2. Encapsulating specific well-defined functionality into a single service, tool or API inherently limits the amount of code it requires, and hence the context an LLM requires to reason about it. The smaller the codebase, the better an LLM will do with it.
3. Code is already increasingly written by swarms of agents that tend to step on each others' toes, and hence a way of isolating them would be great.
4. Combining the 3 points and taking them to the logical conclusion, we end up with nano-services.
It's basically the Unix philosophy, just scaled up to distributed systems. For all its other issues, the core philosophy worked pretty well for Unix tools, so it should work well for nano-services too.
Currently the "pipes" between these services are network calls, but they need not be. One could imagine an architecture where these components are composed either as direct function calls or remote network calls depending on access patterns and resource requirements for a given instance. Never worked with Elixir but I think that might fit the bill?
Maybe every sufficiently complicated distributed system will end up re-inventing an ad hoc, informally-specified, bug-ridden, slow implementation of half of Elixir.