Essay argues AI coding agents will force modularity, spark debate on complexity
Software architect Jacob Gold warns that agentic coding will require radical code modularity to work at scale; developers contest whether this solves or multiplies problems.
What to know
- Essay argues AI coding agents running in parallel will generate 10x more commits than human teams, forcing radical code modularity and microservice architecture to manage merge conflicts.
- Developers heavily contest the premise: commenters argue microservices actually increase coordination complexity, agents lack full system context, and the architecture may create more problems than it solves.
- Skepticism centers on whether high PR volume is achievable without trivial changes, whether senior engineers can review at that scale, and whether Uber's microservices were intentional rather than a byproduct of internal incentives.
- Broader debate on whether agentic coding favors smaller distributed teams and companies or simply shifts complexity from code to operations and infrastructure.
The dispute Whether microservices reduce or multiply complexity when combined with AI agents: Gold argues agents need modularity to work; critics argue microservices shift rather than solve the problem and that agents lack system-wide context to maintain coherence. · positions read across 29 posts and comments
Microservices and agent-driven modularity will create operational and coordination nightmares, not solve them.
-
“Microservices are WAY harder to coordinate for deployments. You end up with feature service dependencies, and you are back to the same coordination, but now harder to discover down stream dependencies.”
layoric · Hacker News
The high PR volume claims are unrealistic and ignore code review and validation requirements at scale.
-
“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.”
_345 · Hacker News
Agentic coding increases coordination overhead and favors smaller, specialized teams and companies, not consolidation.
-
“Agentic coding puts a lot of pressure on team communication. Individuals produce more output. So there now is a lot more to discuss and synchronize on. This favors smaller teams that typically are responsible for more things.”
jillesvangurp · Hacker News
Uber's microservice architecture was not an intentional design choice but a byproduct of broken incentives.
-
“Pretty sure Uber ended up with thousands of microservices because they used to tie owning a service to perf and promo, and were trying to cut down the number for years. It's hilarious to see this interpreted as an intentional choice.”
throw123fgbkjgf · Hacker News
“Modularity got cheap. Splitting things up used to be very expensive, since every service meant more boilerplate, plumbing, and CI config. Agents write all of that now.”
Jacob Gold, Software architect · jacob.gold
Jacob Gold Software architect, essay author
The record 1 articles and posts · last 30 days
What people are saying 24 voices from 1 site · best of 29 · verbatim
- How can code review scale to validate 100+ PRs per day per person without losing quality?
- Will loss of senior engineers' institutional knowledge as they burn out lead to systemic failures across thousands of services?
- Does modularity actually reduce complexity or just move it from code to operations, testing, and deployment?
- Aug 22
-
The potential I see with LLMs is that a single team or even IC can now deliver whole feature end to end. Having just more services only means I get bogged down in PR review by other teams. Or I lose time waiting on them to do the change. In other words, any gain I got I lose tenfold because of inter-team coordination.I think if you want to see…
- Aug 21
-
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…
-
> if you have thousands of microservicesYou just replaced ns memory accesses by ms API calls. Just the moment people were starting to maybe start thinking about performances again this train-wreck of power wastefulness had to appear.
-
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…
-
On the other hand, AI is good at following invariants and adversarially policing the system to pay back debt. The latter is too expensive for humans as a project grows.
-
The reason micro services became fancy is because they could split up large groups of people. They could work on different parts more autonomously without all being dependent on each other.It has an overhead but as scaling the amount of people was worth it there was an advantage.Where did this work: where the interfaces between those groups of…
-
> A small team today, running 20-100 agents in parallel, might generate 500 commits/200 pushes/100 PRsWho the fuck is writing the requirements in that story?! Setting aside the problem of pushing AI-generated code that nobody has read straight to production, the reason why you're pushing code to production in the first place is to implement a…
-
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.
-
The point of dividing your software into independent services is to be able to give those services to different teams that can independently develop and release them.What’s the point if you’re treating the whole system as a slop bucket?
-
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
-
Agentic coding puts a lot of pressure on team communication. Individuals produce more output. So there now is a lot more to discuss and synchronize on. This favors smaller teams that typically are responsible for more things. That doesn't necessarily mean fewer people. But I do think it favors having more smaller companies over fewer larger ones…
- Aug 20
-
i agree with this.. but also think it could stress a couple things more:- satisfying the needs of parallel agentic development is wholly aligned with the optimal DevSecOps CI/CS/CD WhateverTerm models out there. And that's rad, bc a lot of orgs have a reference frame to map to.- microservices, monoliths, monorepos, mammoths, whatever.. The code…
-
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.
-
> If you have a large monolithic service where every change has to be coordinated carefully..Microservices are WAY harder to coordinate for deployments. You end up with feature service dependencies, and you are back to the same coordination, but now harder to discover down stream dependencies..
-
Thousands of microservices = thousands deployments that can fail, that needs to kept compatible, that needs to be able to find each other, that needs to be monitored. This is just pushing the pain downwards.
-
Microservices can trample on each other just as easily as monolith internals can. If anything, the friction of reconciling changes in a monolith is useful signal that conflicting changes happened, and it takes slow and flaky e2e tests to replicate in microservices. It's not like you're resolving the merge conflicts by hand.
-
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?
-
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…
-
I saw the `require('gulp')` and the memories def came back. That's def how we used to do code ~10 years ago. I still don't like the multi-threaded PER PROJECT too much, I prefer having 2 projects and switching context window, I find the current tools (at least the ones I know) are a bit underwhelming for multi-threading. But I'm also trying to…
-
Pretty sure Uber ended up with thousands of microservices because they used to tie owning a service to perf and promo, and were trying to cut down the number for years. It's hilarious to see this interpreted as an intentional choice.
-
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…
-
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…
-
> So Uber’s approach to modularity may have seemed extreme at the time, but it could become the new normal.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.
-
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…