Rendered at 07:08:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ulrikrasmussen 11 minutes ago [-]
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.
kstenerud 6 hours ago [-]
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.
hombre_fatal 32 minutes ago [-]
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.
Right now you can open Claude Code in your project and prompt it "start a workflow that fans out subagents, each with a narrow scope, to look for {simplifications, correctness by construction opportunities, <insert your goal>} ranked by impact vs confidence, and then collate the findings into result.md". If you have the tokens, do more workflows that find more issues and/or vet and polish the findings already in the file.
I do that every time my weekly usage is about the reset to spend me last tokens.
Maintenance is becoming trivial, and anyone who thinks AI dooms you to an ever growing mudball apparently hasn't considered using AI for anything other than appending more code to the mudball.
maccard 29 minutes ago [-]
Are they? Because my experience is they’re really, really bad at following them and as context grows they get worse at following them.
mikojan 17 minutes ago [-]
This works great as long as you are not doing what the parent comment cautions you to not do: Let agents decide the architecture.
The moment you do that, why even bother producing a result.md? Just let the Bot execute on its findings, you realistically won't be able to judge them anyway.
gentooflux 5 hours ago [-]
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.
5 hours ago [-]
tjwebbnorfolk 4 hours ago [-]
There will, at some point, be a capex winter. Companies are splurging on a huge buildout and aren't going to buy GPUs at this rate forever.
That does not mean we're all going back to artisanally hand-crafting software. That's never going to happen.
lelanthran 1 hours ago [-]
Not sure what they are doing with the GPUs anyway, nvidia is on track to produce more GPUs than can be physically used, because the DCs don't exist, and won't for another 18 months, and the power plants needed likewise don't exist.
mitjam 49 minutes ago [-]
It’s like De Beers: control supply to control the price.
bpodgursky 5 hours ago [-]
I don't say this to be mean, but you need to plan for a world where it's always summer. Maybe the valuations will collapse with OSS models but programming is never going back to normal.
sebastiennight 4 hours ago [-]
> plan for a world where it's always summer
The difficulty in adopting this belief lies in the fact we have multiple points of reference in the past, of visionaries claiming that "this time is different" and we reached the end of history... and well, the rest is history.
novok 11 minutes ago [-]
In tech 'this time it's different' happens about every 10 years, so yes? Mainframes, minicomputers, the PC revolution, the internet in the 90s, commodity cloud computing: even more internet, the smartphone and now AI. It's not the end of history, it's the continuation.
kaashif 4 hours ago [-]
It's a pun on AI winter - if there's not going to be a winter, then it's always summer. But things won't be static.
It is in fact normal for new technologies to be adopted, and for there to be no cycle where the technology just disappears. There was no Internet winter or railroad winter, not in the same way there was an AI winter where AI just went away.
Those technologies had valuation bubbles but the technologies themselves stuck around and changed the world beyond recognition. If someone sees the rate of change and thinks it'll stop for...some reason, then they're the ones who believe things are different this time.
sebastiennight 4 hours ago [-]
My counterpoint is that "the internet" is quite recent, and has had many iterations - we've basically abandoned gopher, mostly irc, etc. Even "the web" as we know it is arguably entering a winter we can't yet foresee the duration of.
I 100% agree that "AI" is not going anywhere as long as humans are here (I wouldn't be building a company in the space otherwise).
I'm challenging this specific absolute certainty that "a swarm of agents building code like ants" will be living in eternal summer. This paradigm might be completely different just 6 months from now, from all we know!
hiAndrewQuinn 1 hours ago [-]
I don't see why we would weight those points of reference stronger than the ones where people claimed "this time is different", and it really was different.
In fact there's almost nothing similar between my day to day life and the day to day life even of my grandfather, to say nothing of the Irish peasantry I came from 500 years ago, say. The number of correct everything-is-differences per year seems to be going up, not down.
robotresearcher 3 hours ago [-]
Yes that’s very sanguine. On the other hand there have been many times when tech made a permanent difference.
It has stayed comms and compute summer since the end of the twentieth century. It has stayed infection summer since the beginning of the twentieth century. You get the idea.
wahnfrieden 4 hours ago [-]
But the models are useful now and Inference is profitable. At most we must worry that the latest is not actually useful, or that they won’t get better.
bpodgursky 4 hours ago [-]
I hear you, but this time is different and history doesn't tell us what happens next. They were wrong those times. They would be correct today.
I don't have any clever argument to justify this, you just have to look at the ways the world is changing today and decide for yourself whether there is a clean historical analog.
0123456789ABCDE 30 minutes ago [-]
okay, ignoring the oxymoron with which you end you comment, what do you think folks plan for when they put on a life jacket to enter a recreational boat?
zx8080 5 hours ago [-]
> but programming is never going back to normal.
Are you telling it's shit now? I'm just curious.
echelon 4 hours ago [-]
You're not going to get your old job back. You're a prompt engineer or you're fired.
Programming will never go back to what it was before 2026.
grey-area 6 minutes ago [-]
Many programmers still just write programs, using tools where it is useful.
Of course programming never stands still. I don’t think anyone thinks it will rewind. But your second sentence is very odd.
Your extraordinary claim may reflect life in certain companies in SV in the grip of AI Psychosis, but most companies are evaluating these tools objectively - they are certainly not ready to perform as agents or replace humans, and it is debateable whether they are providing much efficiency boost in the case where you try to replace humans writing code entirely - there are definitely significant downsides - loc inflation, lack of context, incorrect code which appears correct, wasted time, burnout of supervising humans having to read the output etc etc.
All the thought leaders like this article jumping to the shining future of independent agents cooperating under light human supervision are vastly premature - LLMs are nowhere near intelligent or independent enough for that.
eloisius 48 minutes ago [-]
If the job is now being a promoter, how can you not see that it’s a low skill, low pay job anyway? There are a billion capable promoters in LCOL countries that can prompt as good as someone in the Bay. Might not be worth stressing so hard to be a promptmaxxer. Could just become a bus driver or some other skilled profession if you want to keep earning a living.
thothless 2 hours ago [-]
You're living in a corporate bubble, drowning in the kool-aid, along with half this forum.
anonzzzies 1 hours ago [-]
You are saying programming IS going to go back to what it was? If yes, great! But how exactly? Why would anyone do that and why would companies want that?
RealityVoid 1 hours ago [-]
I think Op did not claime that "programming is going back to what it was" because even the point we should be going back to is not agreed where it should be. It's a profession always in flux.
On the other hand, "you're a prompt engineer or you're fired" just reeks of psychosis. Things will change, they will never be the same, perhaps the profession will contract. But there sure as hell will still be people thinking deeply about their code and crafting it.
brabel 58 minutes ago [-]
[dead]
jatora 5 hours ago [-]
Continual gains that have not stopped and there is clearly much gain to be had even if model intelligence stopped scaling. I find it borderline nasty how so many people are positively hoping for a bubble to pop or an AI winter to come so that they can feel like they can cope with the evolving world...despite all evidence to the contrary that any of these things will happen very soon at all.
lelanthran 1 hours ago [-]
Speak to young folk. My numerous nieces and nephews use ChatGPT all the time and yet they still hate it.
They are contemplating a lifetime of devalued skills, because they can see that prompting a model is an unskilled task.
thin_carapace 4 hours ago [-]
currently unfettered ai spending is reducing qol for more individuals than it is increasing. why should the avg joe be happy about reduced qol?
jatora 4 hours ago [-]
who is it reducing qol for?
I get that SWE get far higher benefit than maybe everyone else, but who is it actively reducing QoL for?
jamesfinlayson 3 hours ago [-]
As a software engineer I don't think my quality of life has been improved - I now get gigantic patches to review (and I know the people writing them haven't reviewed or tested their own patches so even worse) and my tester is now drowning in big garbage patches that are taking longer to test, so my work isn't progressing either.
ThrowawayR2 4 hours ago [-]
Massive price increases for any electronics that contains RAM, SSDs, etc. has hurt everyone. The GPU supply crunch has hurt a smaller swath but hardly zero.
thin_carapace 3 hours ago [-]
additional to the great examples already given, anyone in residential proximity to a compute centre is recieving noise + environment pollution. resultant destruction of sleep and air/water quality is massively detrimental to qol. the joes who net benefit from ai detriments seem to live far away from the consequences. I shall ask another way, how do the average joe's ai benefits outweigh his ai detriments?
pianopatrick 5 hours ago [-]
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.
kstenerud 5 hours ago [-]
This would presuppose only a single new version being "in-flight". But a microservice change often bleeds into another microservice having to change. Multiply this by all the agents working on the product, and you get a very complicated release process for those microservices.
The ripple effects are basically the same as what you'd get in a monolithic codebase. In fact you can still think of a set of microservices as a single codebase, just not centrally maintained anymore. The complexity is moved rather than eliminated. And you'll still have agents (and people) stepping on each other if there's too little coordination.
pianopatrick 5 hours ago [-]
Right but if you coordinate those changes in a new version you would still have the old version to fall back to if any of those changes lead to problems.
kstenerud 4 hours ago [-]
Yes, but then there's a trap lurking nearby: As different versions of the same function proliferate, it muddies the waters, because you now have multiple parts of your system calling a similar-but-not-quite-the-same function. Your refactors are never complete, and you find yourself less able to properly reason about the system as a whole anymore. The payment and subscription systems call different versions of the same function, which works most of the time but they don't always agree.
With a lot of discipline and process control, one could make such a system work, but it's most definitely not a free lunch. The complexity has to go somewhere.
pianopatrick 4 hours ago [-]
Yes, I agree half finished refactors are bad. But I think with AI the timing is a bit different now so the best plan changes. I.e. AI can finish various steps in generating the new version and transitioning to the new version much faster than people could in the past. So you are unlikely to end up with lots of half finished refactors because AI can finish them fast.
The bigger problem now is handling the AI mistakes and failures, not slogging through all the steps of a refactor. So having a full and complete ready to go fallback version with like Blue / Green deploys might be really helpful. But to do that you need discrete versions, not digging through diffs to find the problem and redeploy.
But this is all just a theory I haven't tested right now.
jatora 5 hours ago [-]
More coordination is exactly what the commenter was proposing though so I dont really see the point in your response.
honr 4 hours ago [-]
This has been one of the billion(s) dollar questions of 2026. There have been a few approaches emerging throughout the year (heuristics to hard-divide work, using better languages with dependable contracts, task management protocols, and organizational agent roles). None has won so far, though, but some appear (or claim) to be close.
p1necone 5 hours ago [-]
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.
romanhn 4 hours ago [-]
Have you had to deal with a microservices environment? Because there's significantly more operational and architectural complexity with a distributed system compared to a monolith. Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. I would generally not recommend adding all this overhead unless absolutely necessary. Or at least that was the recommendation pre-AI, but I don't think I've changed my mind on it yet.
win311fwg 4 hours ago [-]
> Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things.
Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.
ulrikrasmussen 4 hours ago [-]
Then it sounds like you can only have a true microservice architecture if your application doesn't really need transactional guarantees, consistency or fault tolerance.
win311fwg 3 hours ago [-]
Then you must have heard the wrong thing. Oh well. You can't communicate with everyone.
ulrikrasmussen 16 minutes ago [-]
Then please help me understand, it is entirely possible that I misunderstood you, but you are not clarifying your point.
alright2565 4 hours ago [-]
Sure there is. For thousands of classes/functions, I can test the boundaries between them in nanoseconds each. Integration tests are the important part, because with the quality of AI coding these days, unit testing is a waste of time.
With micro services, that same function call is now a minimum of 200us. And now I have LOC for serialization/deserialization, retries, error handling, etc, bloating my code and making it harder to understand, plus now to do the same integration test I need to understand N different build systems for each component.
0x696C6961 3 hours ago [-]
You can also make breaking changes to internal APIs without versioning or release coordination. Just update all the call sites.
onion2k 44 minutes ago [-]
The separation in micro services is hard to break though. You need to add an API on one side and a call on the other.
In a monolith it's significantly easier to do something that has an unexpected impact somewhere else. For example, changing a shared object a singleton to a clone will give you race conditions all over the place. You just don't have that footgun in micro services.
killthebuddha 5 hours ago [-]
1 difference (out of many, many, differences), is that (most) compilers don't make guarantees across process boundaries.
whateverboat 4 hours ago [-]
In fact microservices are arguably more complex. It is the reason why microkernels have not succeeded compared to monolith till now.
ReptileMan 3 hours ago [-]
>Hundreds of bots modifying thousands of microservices
That is way too close to monkeys on typewriters for comfort.
MrBuddyCasino 44 minutes ago [-]
I used to say my job was „managing complexity“, not being a programmer. After AI, thats still true because they suck at it.
jurgenburgen 1 hours ago [-]
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?
Sharlin 3 hours ago [-]
> Hundreds of bots modifying thousands of microservices may sound good on the surface
It really does not, honestly.
john_minsk 5 hours ago [-]
Why do you need to always modify the service? Once it is up and running and performs a function - don't touch it.
kstenerud 5 hours ago [-]
For the same reason you change or replace any function in a program: The situation has changed.
d--b 1 hours ago [-]
It doesnt sound good at all!
10 people generating 800 commits a day is completely stupid.
I mean at this stage people don’t even know what they’re building anymore. They’ll burn through their backlog faster than the backlog can be filled.
Or maybe they spend 700 commits fixing the issues generated by the first 100?
This doesn’t make any sense to me
wotamess 4 hours ago [-]
Eventually we'll compress out unnecessary state and keep desired data states only; AI then won't be editing k8s yml, source code, etc.
It will just be computing new geometric states and syncing them to the screen.
Incidentally not having devs save endless copies of their dev tools and languages will save a bunch of electricity; storing and copying that stuff around uses a lot of electricity.
Software engineers who want to be taken as experts in their craft need to understand the chip makers are experts in theirs all the same. They’re not leaving your concerns about correctness, efficiency, and stability unconsidered.
Almost offensive for non-experts in hardware dev to continue to insinuate no one but SaaS devs have any idea how computers work.
davepeck 6 hours ago [-]
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.
alansaber 5 hours ago [-]
Agent spam is definitely an excercise in diminishing returns
whatever1 4 hours ago [-]
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.
BLKNSLVR 2 hours ago [-]
The answer to all the questions, though, is more AI/LLM usage. Nobody got a freaking clue what the LLMs have done and why services are down? Diagnose it with LLM, and get the lights back on ASAP!
I have a similar concern, though. To do my job, I need to understand "the thing". I could outsource the understanding process to AI, but then if I'm asked a question by a developer or tester then I'm essentially stumped / useless because I didn't spend the time to understand the thing, I handballed it.
So I then ask the LLM the question I was asked, and pass the answer back (they could have done this themselves though, so where does that leave me? I'm either an AI wrangler, or replaced by someone else who wrangles AI replacing mutliple people in my role). Does my personally understanding the thing actually add value - do the seniors who know their systems add value - in the age of AI/LLM?
Does "LLMs all the way down" solve the problems?
With the existence of hallucinations I lean towards 'no', but again is that solved by adding layer(s) of LLMs to check for hallucinations?
misiek08 45 minutes ago [-]
So you are already sometimes being the „meat proxy”. It only shows one much worse thing - the people asking you are first to blame/for, because they didn’t ask LLM. Maybe it’s temporary and it will change.
One added value I see in senior knowing how things work is simple - in case of outage or business incidents (caused by incorrect logic produced by LLMs from even worse prompts or incomplete spec) senior can act faster and answer difficult questions live. Now we are going to have bunch of kids looking at „Hallucinating…” and „Crashing the prod…” status bar in CC CLI.
Maybe this is what’s gonna be acceptable and it’s just new world.
jaggederest 4 hours ago [-]
You can already see a practical example of this in microsoft's issues with Azure. Too many services, too little understanding, everyone left who knows what is going on. There was an interesting article here a little while ago by one of the architects something like "how azure set a trillion dollars on fire" or something like that.
tokioyoyo 1 hours ago [-]
This argument comes up during every big layoff season. A good chunk of people pronounced Twitter dead when it got bought out. But software nowadays is pretty stable, despite its perceived jankiness.
whatever1 39 minutes ago [-]
Twitter is dead. After the layoffs it required multiple bailouts and pivots to its business. Not even sure what X is about today.
Layoffs pushed over the cliff the company. Both due to engineering (content is now trash), and product (lost most of the ad revenue)
fra 4 hours ago [-]
I would take the other side of that bet. In five years, there won’t be more outages than today.
whatever1 3 hours ago [-]
Deal. See you here 2031. If the site is still up.
zkmon 53 minutes ago [-]
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.
elzbardico 9 seconds ago [-]
> While I’m not saying every LLM user is an imbecile, they’re built to convince the mediocre and incurious that they’re remarkable, and it turns out that a great many of them run venture capital firms and Fortune 500 companies.
> I also want to be clear that while there are sane and normal people who use these things, they’re mostly drowned out by a crowd of people that oscillate between bootlicking and regurgitating capitalist mythology in a way that makes it hard to trust anybody who spends significant amounts of time using an LLM.
> One thing you’ll notice about the most moistened AI boosters is that they lack much degree of pride in their work. Everything they say must, at some point, compliment the mindless, unprofitable, unreliable tool underneath it — how “incredibly powerful” it is, how it’s “only getting better,” how it’s “only the beginning” of something that’s eaten over a trillion dollars and absorbed the majority of venture capital.
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
arkh 10 minutes ago [-]
> if you have thousands of microservices
You 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.
_345 4 hours ago [-]
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?
squibonpig 3 hours ago [-]
I really don't think they can. I feel like if I rush a PR using AI, I can only just kinda hope the AI is good enough that my trust isn't misplaced. It becomes slightly less likely to be bad if you add a thorough AI review on top but it's just rolling the dice.
stymaar 44 minutes ago [-]
> A small team today, running 20-100 agents in parallel, might generate 500 commits/200 pushes/100 PRs
Who 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 product that is solving a problem for your users. And the problem I have with the hypothethical workflow described above is: How is any product owner supposed to come up with hundreds of feature or improvement requests a week?
whstl 14 minutes ago [-]
Just ask AI to write Jira tickets and call it a day.
The point isn’t to serve customers anymore, it’s to use AI for AI sake because investors want, because they have FOMO.
I’m only half joking. I have seen PMs attempting that and getting fired. The investor thing is 100% true.
franciscop 5 hours ago [-]
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 upgrade my knowledge.
A good way I've found, since I do a lot of OSS and have my own libraries, when I find a bug in one of those libraries I can work on the same project on the main window while fixing the library on another window. I normally need to tell the main one "let's skip this for now, I'm fixing the library" meanwhile or similarly.
openfront 3 hours ago [-]
> find the current tools (at least the ones I know) are a bit underwhelming for multi-threading
Have you tried t3 code? It creates a separate worktree per agent, which makes running multiple agents at once much easier.
layoric 4 hours ago [-]
> 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..
lucianbr 1 hours ago [-]
I think microservices are supposed to be easier to deploy independently, that's the whole point. And if they are not, it means you're just doing it wrong.
But in truth, all the projects with microservices I have seen in real life had deployment coordination problems, and looked to me like distributed monoliths. So maybe it's a 'no true scotsman' thing. Maybe they are always, or at least most of the time, harder.
Makes it harder to justify using them.
pqdbr 2 hours ago [-]
Totally agree. And having a Rails monolith that the LLM can see the entire context - even our marketing landing pages - is a blessing in AI era.
somesortofthing 4 hours ago [-]
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.
HWR_14 4 hours ago [-]
I don't understand why microservices would have fewer merge conflicts than monoliths.
abigdog 4 hours ago [-]
From experience it is more human nature to make spaghetti in monoliths but a well disciplined monolith would be as confict free as the equivalent microservices.
throw123fgbkjgf 5 hours ago [-]
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.
the_sleaze_ 4 hours ago [-]
used to work for a company and this is exactly what happened, each team lead pushed for their own little secret garden and fight over who had to add new things. Managing the kafka instance(s) to keep order turned into 2 people's full time jobs. They sold at absolute fire sale price not long ago
fhub 6 hours ago [-]
> 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.
ch4s3 5 hours ago [-]
How would the LLMs even appropriately build and manage context in such a setting?
lucfranken 35 minutes ago [-]
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 people were agreed upon.
A team could call: finance->billTrip(TripObject) via an API and the finance team became independent. The micro services had an API which was documented. They could move from Stripe to SAP to a custom solution internally without bothering the other teams.
Now we have AI.
Those interfaces are still needed. But is there still an advantage to hard separating those interfaces in real micro services, with separate databases for each team, over http or other protocols?
On some point it may. A service which needs to scale unlimited (like RenderThumbnails with hundreds of thousands of call per day) might have that. But if you send out 1000 invoices per day it might not be needed for that at all.
In Rails they have active job for it for example. Same codebase but a scalable worker for longer running jobs.
AI is capable of quickly keeping function calls consistent internally. So a hard coded API is way less useful now for those services which don’t need the scale. An interface could suffice just fine. No human would ever read the finance API anyway.
Keeping consistency in the monolith part is way easier. That is statically testable, quicker testable and there are plenty of tools. All disadvantages on micro services on those calls are just a waste.
One thing where I think hard boundaries are useful is on really blocking AI coding tools. With microservices you are able to physically prevent Claude or others to modify the other interfaces. That way it prevents hallucinations, quick fixes and other workarounds the tools like to do. Just because an AI wants to get sometime done it will sometimes skip corners.
I see that as a current state which will be fixed quite soon. The models and their harnesses will become increasingly better in preventing stupid corner cutting to get the fix out.
When that is done: why would you want more complexity with micro services instead of less?
Instead of we all implementing microservices and other structures we should get the harnesses right to respect interfaces and boundaries.
And in the micro services era we had meetings to sync the API’s between them. So maybe the AI’s should meet about the interfaces, with a good coffee.
igor_nast 30 minutes ago [-]
If you want a truly free to use agentic IDE
check shikigami.dev - free to use - not a vc baked, indie product
lofties 6 hours ago [-]
My biggest issue with these type of posts is that they never answer the "why". Hell, they don't even ask the "why".
> The more modular your code, the more agents you can run
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.
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?
Is the end-user reaping the rewards? Are they getting better software, cheaper?
The answer to all of those is going to be "no".
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.
Nothing is getting better, but at least we're all off worse!
horsawlarway 6 hours ago [-]
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.
skydhash 5 hours ago [-]
> 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.
Or forgotten to look at the map to see if we're getting closer to our destination.
I've never seen a consumer bugs that complains about how small our codebase is or how little PRs we have produced this month. It's always about some features not working properly.
Previously the core metrics were reducing consumer complaints and implementing features for the sales team to attract new clients. Then they suddenly got replaced by amount of PRs and token usages.
mushroom_lasagn 5 hours ago [-]
My organization has noticed that some people's output has gone way up since they started using AI, while some people's has not. I imagine output is measured by LOC and MRs, since we are bad at metrics. There's now an effort to figure out why the laggards aren't using their AI "well" enough. I've seen some of the increased output that was sprayed at my team without consent, it was work that superficially looked good but on closer investigation did not solve the problem it was intended to. All that work has to be redone. The rework is being done quietly, so as not to draw management ire for a lack of "productivity". It's all so tiresome.
antonvs 3 hours ago [-]
> The rework is being done quietly
This is a bad idea - you’re actively contributing to the problem by hiding the negative effects.
Don’t even think about starting that work until you’ve created bug tickets for as much of it as you can, and bright then to management’s attention. Management then needs to figure out priorities for doing that work and whether a change in approach is needed.
wseqyrku 6 hours ago [-]
> 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.
cyh555 5 hours ago [-]
it's against the social rules to call them out
linkregister 6 hours ago [-]
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.
coffeefirst 5 hours ago [-]
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.
jcelerier 4 hours ago [-]
> OK, but why would I want to run more agents? So I can be more productive? What does this productivity lead to?
software used outside of nerd niches? photoshop, canva, clickup, after effects and unreal engine over feh, imagemagick, impressive, emacs org mode, ffmpeg CLI and pico-8?
serious_angel 6 hours ago [-]
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...
i_love_retros 5 hours ago [-]
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.
shimman 5 hours ago [-]
You would absolutely love the book Dawn of Everything.
Humans are way more creative at social cohesion when you remove oligarchs and authoritarians.
naniel 3 hours ago [-]
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 and services can be structured however, so long as the release capabilities are modular and governable/manageable/auditable/flexible/transparent/etc. A killer workflow allows for tight independent releases, but not chaotic, with proper add'l structure/scaffolding to satisfy that list above. Microservices and smaller repos can help with the context window bit initially, but you can rig up and kind of local llm-focused setup to allow for selective context and holistic context (across N repos or N projs within monorepo)
- strategy: use the robots to fix the problems in your PDLC/CICD/ABC so that the robots can help you out more, and keep iterating on that
ulrikrasmussen 4 hours ago [-]
Is this satire? Changing your easy to maintain monolith architecture to a microservice architecture to enable parallel agent development, really? That's got to be some of the worst advice I'd heard in a long time.
You will have conflicts during parallel work if people are changing features that are related. You will also get these conflicts with a microservice architecture and hundreds of independent repos, but now it is not a merge conflict because you touched the same syntax, it is a semantic conflict.
And didn't Uber also have a famously slow and convoluted CI pipeline where it took an enormous amount of time and resources to build anything?
samlinnfer 4 hours ago [-]
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.
marius_ 4 hours ago [-]
There is no "small team" pushing 100PRs/day, agents or not.
mdavid626 2 hours ago [-]
Then you’ll have “GitHub” uptime, breaking prod every day.
abigdog 4 hours ago [-]
He misses the bit about Microservices where you need to integrate changes across services and avoid undocumented API spec from your changes blowing something up. Getting alignment and so on. There are probably agentic solutions but this article misses a lot of detail and doesn't even hand wave it.
talon8635 5 hours ago [-]
I am a team of one, and I don’t use agents
raincole 5 hours ago [-]
You can use this as a canary.
The out-of-control factor = the number of parallel working agents : the number of human programmers.
1. If the factor > N, you're losing control and there will be no organizational wisdom passed down.
2. If your team can't function with the factor <= N, your architecture is way too complex.
Choose N over your prior. My recommendation is 1.
jatora 5 hours ago [-]
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.
szp2005 46 minutes ago [-]
[flagged]
burnto 6 hours ago [-]
Why not just bake an agent into every service and chat with it? Sounds more fun at least.
janalsncm 4 hours ago [-]
Call me old school but I feel like the solution to humans clogging up the slop cannon will be for AI generated code to look more human.
That is, the code should be correct but also idiomatic.
jillesvangurp 3 hours ago [-]
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 that are each able to specialize more. It also means that companies that currently outsource all their development or buy SAAS products now should consider in housing some things again. A lot of people worry about work disappearing. I think the opposite is going to happen: more work popping up in a lot of new places. Because doing that work is now feasible and doable.
Staying on top of work done across many teams is going to be a huge challenge for larger companies and it's going to cause them to organize and hire very differently. Getting this wrong means teams diverge much quicker than they used to and everything gets misaligned much quicker. Some team might launch a product before some other team that was considering to do a similar thing is even aware that is happening. As most engineers might appreciate, the easiest way to tackle complexity is to just work on cohesiveness and coupling. Small teams with few dependencies working on a coherent thing will be much more effective than large orgs with a lot of inter team coupling and no coherent plan.
I'm in my fifties so, I've been around for a while. I currently work in a very small company (3 people) so I'm used to doing things by myself. I also used to work in traditional teams inside large multinationals. Very different game. You spend non trivial amounts of time communicating with people in big organizations. And you basically only get responsibility for a tiny amount of functionality. I had to learn a lot after I left the safety of a big organization. When everything is your problem, you need to skill up in a hurry to deal with all the challenges effectively.
In my current role, I do basically everything vaguely technical. And non technical as well. And it is more than ever since AI coding entered the mix last year. I stopped referring to myself as a backend person. Because I also do UI, devops, websites, IT infrastructure, etc. And a bit of sales, marketing, etc. I'd add management but we're such a small team that I suffer a little from impostor syndrome on that front. But I can do the job if I need to.
I had a whole hiring plan that I developed three years ago that we never executed on. It had all the traditional dev team roles spelled out. That plan is obsolete. These roles will probably never be filled. I need different people though. I need more people like me that can do everything I do when I'm not around and people with complementary skills that are strong where I'm weak. But I have much less need for specialists. I mainly need generalists with attention to detail that can deliver complete working products and systems. I might want a product focused person but not a dedicated product manager. If you can specify it in an issue tracker, you can learn to prompt an AI as well. But I still need a good product plan and roadmap. In the same way, I expect designers to shape UI work directly and not via a separate UI team. I expect them to own the front end experience and drive it. I still need people that are strong in these roles. But not exclusively. Good small teams have less people than all the traditional roles you find in larger traditional teams. That calls for people with overlapping skills that can put on different hats as needed that complement each other.
gulugawa 6 hours ago [-]
I'm a 1 person dev team who wrote frontend code that outperforms React.
Is was successful because I didn't use any sort of LLM assistance.
ChrisMarshallNY 5 hours ago [-]
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.
shimman 4 hours ago [-]
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?
mickael-kerjean 3 hours ago [-]
Same as op, I rewrote away from react my Dropbox alternative (https://github.com/mickael-kerjean/filestash) in vanilla js a couple years back around the idea that components are plain exported functions like this:
example: https://github.com/mickael-kerjean/filestash/blob/master/pub...
the only library in there is rxjs to manipulate events in a functional fashion with no imperative code and everything is composed from those simple component functions. The wasm is used mostly as an interface for plugins to both run apps to display various file types like RAW, PSD, TIFF, CDR, .... as those tend to have better support in C than other languages, and on the server side to have a safe environment to execute plugin code.
chrismorgan 2 hours ago [-]
Completely seriously, and I don’t think this is particularly controversial: outperforming React is not impressive. React was never particularly good at performance—VDOM is fundamentally overhead, and there are a variety of faster and lighter techniques employed by various competitors, and even among VDOM libraries it’s not as fast as it could be. React sold itself as fast initially, but what it was faster than (rebuilding the entire DOM on any update) was a strawman.
It’s not hard to be faster than React while exposing broadly similar functionality. If you’re making something for your own usage only, it’s even easier to beat it.
aussieguy1234 6 hours ago [-]
There's another way to get this kind of parallelism without the mess of microservices.
Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.
aryehof 3 hours ago [-]
> Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other
Isn’t the question how to keep likely dependent modules separated from each other in a monolith? You say “single purpose”, but how does that admonition work in the reality of a complex problem domain?
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.
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.
Right now you can open Claude Code in your project and prompt it "start a workflow that fans out subagents, each with a narrow scope, to look for {simplifications, correctness by construction opportunities, <insert your goal>} ranked by impact vs confidence, and then collate the findings into result.md". If you have the tokens, do more workflows that find more issues and/or vet and polish the findings already in the file.
I do that every time my weekly usage is about the reset to spend me last tokens.
Maintenance is becoming trivial, and anyone who thinks AI dooms you to an ever growing mudball apparently hasn't considered using AI for anything other than appending more code to the mudball.
The moment you do that, why even bother producing a result.md? Just let the Bot execute on its findings, you realistically won't be able to judge them anyway.
That does not mean we're all going back to artisanally hand-crafting software. That's never going to happen.
The difficulty in adopting this belief lies in the fact we have multiple points of reference in the past, of visionaries claiming that "this time is different" and we reached the end of history... and well, the rest is history.
It is in fact normal for new technologies to be adopted, and for there to be no cycle where the technology just disappears. There was no Internet winter or railroad winter, not in the same way there was an AI winter where AI just went away.
Those technologies had valuation bubbles but the technologies themselves stuck around and changed the world beyond recognition. If someone sees the rate of change and thinks it'll stop for...some reason, then they're the ones who believe things are different this time.
I 100% agree that "AI" is not going anywhere as long as humans are here (I wouldn't be building a company in the space otherwise).
I'm challenging this specific absolute certainty that "a swarm of agents building code like ants" will be living in eternal summer. This paradigm might be completely different just 6 months from now, from all we know!
In fact there's almost nothing similar between my day to day life and the day to day life even of my grandfather, to say nothing of the Irish peasantry I came from 500 years ago, say. The number of correct everything-is-differences per year seems to be going up, not down.
Smartphones, internet, PCs, computers, semiconductors, relativity, antibiotics, telegraph, printing, electricity, steam power, …
It has stayed comms and compute summer since the end of the twentieth century. It has stayed infection summer since the beginning of the twentieth century. You get the idea.
I don't have any clever argument to justify this, you just have to look at the ways the world is changing today and decide for yourself whether there is a clean historical analog.
Are you telling it's shit now? I'm just curious.
Programming will never go back to what it was before 2026.
Of course programming never stands still. I don’t think anyone thinks it will rewind. But your second sentence is very odd.
Your extraordinary claim may reflect life in certain companies in SV in the grip of AI Psychosis, but most companies are evaluating these tools objectively - they are certainly not ready to perform as agents or replace humans, and it is debateable whether they are providing much efficiency boost in the case where you try to replace humans writing code entirely - there are definitely significant downsides - loc inflation, lack of context, incorrect code which appears correct, wasted time, burnout of supervising humans having to read the output etc etc.
All the thought leaders like this article jumping to the shining future of independent agents cooperating under light human supervision are vastly premature - LLMs are nowhere near intelligent or independent enough for that.
On the other hand, "you're a prompt engineer or you're fired" just reeks of psychosis. Things will change, they will never be the same, perhaps the profession will contract. But there sure as hell will still be people thinking deeply about their code and crafting it.
They are contemplating a lifetime of devalued skills, because they can see that prompting a model is an unskilled task.
I get that SWE get far higher benefit than maybe everyone else, but who is it actively reducing QoL for?
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.
The ripple effects are basically the same as what you'd get in a monolithic codebase. In fact you can still think of a set of microservices as a single codebase, just not centrally maintained anymore. The complexity is moved rather than eliminated. And you'll still have agents (and people) stepping on each other if there's too little coordination.
With a lot of discipline and process control, one could make such a system work, but it's most definitely not a free lunch. The complexity has to go somewhere.
The bigger problem now is handling the AI mistakes and failures, not slogging through all the steps of a refactor. So having a full and complete ready to go fallback version with like Blue / Green deploys might be really helpful. But to do that you need discrete versions, not digging through diffs to find the problem and redeploy.
But this is all just a theory I haven't tested right now.
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.
Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.
With micro services, that same function call is now a minimum of 200us. And now I have LOC for serialization/deserialization, retries, error handling, etc, bloating my code and making it harder to understand, plus now to do the same integration test I need to understand N different build systems for each component.
In a monolith it's significantly easier to do something that has an unexpected impact somewhere else. For example, changing a shared object a singleton to a clone will give you race conditions all over the place. You just don't have that footgun in micro services.
That is way too close to monkeys on typewriters for comfort.
What’s the point if you’re treating the whole system as a slop bucket?
It really does not, honestly.
10 people generating 800 commits a day is completely stupid.
I mean at this stage people don’t even know what they’re building anymore. They’ll burn through their backlog faster than the backlog can be filled.
Or maybe they spend 700 commits fixing the issues generated by the first 100?
This doesn’t make any sense to me
It will just be computing new geometric states and syncing them to the screen.
Incidentally not having devs save endless copies of their dev tools and languages will save a bunch of electricity; storing and copying that stuff around uses a lot of electricity.
Software engineers who want to be taken as experts in their craft need to understand the chip makers are experts in theirs all the same. They’re not leaving your concerns about correctness, efficiency, and stability unconsidered.
Almost offensive for non-experts in hardware dev to continue to insinuate no one but SaaS devs have any idea how computers work.
> 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.
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.
I have a similar concern, though. To do my job, I need to understand "the thing". I could outsource the understanding process to AI, but then if I'm asked a question by a developer or tester then I'm essentially stumped / useless because I didn't spend the time to understand the thing, I handballed it.
So I then ask the LLM the question I was asked, and pass the answer back (they could have done this themselves though, so where does that leave me? I'm either an AI wrangler, or replaced by someone else who wrangles AI replacing mutliple people in my role). Does my personally understanding the thing actually add value - do the seniors who know their systems add value - in the age of AI/LLM?
Does "LLMs all the way down" solve the problems?
With the existence of hallucinations I lean towards 'no', but again is that solved by adding layer(s) of LLMs to check for hallucinations?
One added value I see in senior knowing how things work is simple - in case of outage or business incidents (caused by incorrect logic produced by LLMs from even worse prompts or incomplete spec) senior can act faster and answer difficult questions live. Now we are going to have bunch of kids looking at „Hallucinating…” and „Crashing the prod…” status bar in CC CLI.
Maybe this is what’s gonna be acceptable and it’s just new world.
Layoffs pushed over the cliff the company. Both due to engineering (content is now trash), and product (lost most of the ad revenue)
> I also want to be clear that while there are sane and normal people who use these things, they’re mostly drowned out by a crowd of people that oscillate between bootlicking and regurgitating capitalist mythology in a way that makes it hard to trust anybody who spends significant amounts of time using an LLM.
> One thing you’ll notice about the most moistened AI boosters is that they lack much degree of pride in their work. Everything they say must, at some point, compliment the mindless, unprofitable, unreliable tool underneath it — how “incredibly powerful” it is, how it’s “only getting better,” how it’s “only the beginning” of something that’s eaten over a trillion dollars and absorbed the majority of venture capital.
Ed Zitron. The Revenge of the business idiot.
https://www.wheresyoured.at/the-revenge-of-the-business-idio...
You 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.
Who 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 product that is solving a problem for your users. And the problem I have with the hypothethical workflow described above is: How is any product owner supposed to come up with hundreds of feature or improvement requests a week?
The point isn’t to serve customers anymore, it’s to use AI for AI sake because investors want, because they have FOMO.
I’m only half joking. I have seen PMs attempting that and getting fired. The investor thing is 100% true.
A good way I've found, since I do a lot of OSS and have my own libraries, when I find a bug in one of those libraries I can work on the same project on the main window while fixing the library on another window. I normally need to tell the main one "let's skip this for now, I'm fixing the library" meanwhile or similarly.
Have you tried t3 code? It creates a separate worktree per agent, which makes running multiple agents at once much easier.
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..
But in truth, all the projects with microservices I have seen in real life had deployment coordination problems, and looked to me like distributed monoliths. So maybe it's a 'no true scotsman' thing. Maybe they are always, or at least most of the time, harder.
Makes it harder to justify using them.
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.
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 people were agreed upon.
A team could call: finance->billTrip(TripObject) via an API and the finance team became independent. The micro services had an API which was documented. They could move from Stripe to SAP to a custom solution internally without bothering the other teams.
Now we have AI.
Those interfaces are still needed. But is there still an advantage to hard separating those interfaces in real micro services, with separate databases for each team, over http or other protocols?
On some point it may. A service which needs to scale unlimited (like RenderThumbnails with hundreds of thousands of call per day) might have that. But if you send out 1000 invoices per day it might not be needed for that at all.
In Rails they have active job for it for example. Same codebase but a scalable worker for longer running jobs.
AI is capable of quickly keeping function calls consistent internally. So a hard coded API is way less useful now for those services which don’t need the scale. An interface could suffice just fine. No human would ever read the finance API anyway.
Keeping consistency in the monolith part is way easier. That is statically testable, quicker testable and there are plenty of tools. All disadvantages on micro services on those calls are just a waste.
One thing where I think hard boundaries are useful is on really blocking AI coding tools. With microservices you are able to physically prevent Claude or others to modify the other interfaces. That way it prevents hallucinations, quick fixes and other workarounds the tools like to do. Just because an AI wants to get sometime done it will sometimes skip corners.
I see that as a current state which will be fixed quite soon. The models and their harnesses will become increasingly better in preventing stupid corner cutting to get the fix out.
When that is done: why would you want more complexity with micro services instead of less?
Instead of we all implementing microservices and other structures we should get the harnesses right to respect interfaces and boundaries.
And in the micro services era we had meetings to sync the API’s between them. So maybe the AI’s should meet about the interfaces, with a good coffee.
check shikigami.dev - free to use - not a vc baked, indie product
> The more modular your code, the more agents you can run
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.
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?
Is the end-user reaping the rewards? Are they getting better software, cheaper?
The answer to all of those is going to be "no".
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.
Nothing is getting better, but at least we're all off worse!
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.
Or forgotten to look at the map to see if we're getting closer to our destination.
I've never seen a consumer bugs that complains about how small our codebase is or how little PRs we have produced this month. It's always about some features not working properly.
Previously the core metrics were reducing consumer complaints and implementing features for the sales team to attract new clients. Then they suddenly got replaced by amount of PRs and token usages.
This is a bad idea - you’re actively contributing to the problem by hiding the negative effects.
Don’t even think about starting that work until you’ve created bug tickets for as much of it as you can, and bright then to management’s attention. Management then needs to figure out priorities for doing that work and whether a change in approach is needed.
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 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.
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.
software used outside of nerd niches? photoshop, canva, clickup, after effects and unreal engine over feh, imagemagick, impressive, emacs org mode, ffmpeg CLI and pico-8?
Humans are way more creative at social cohesion when you remove oligarchs and authoritarians.
- 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 and services can be structured however, so long as the release capabilities are modular and governable/manageable/auditable/flexible/transparent/etc. A killer workflow allows for tight independent releases, but not chaotic, with proper add'l structure/scaffolding to satisfy that list above. Microservices and smaller repos can help with the context window bit initially, but you can rig up and kind of local llm-focused setup to allow for selective context and holistic context (across N repos or N projs within monorepo)
- strategy: use the robots to fix the problems in your PDLC/CICD/ABC so that the robots can help you out more, and keep iterating on that
You will have conflicts during parallel work if people are changing features that are related. You will also get these conflicts with a microservice architecture and hundreds of independent repos, but now it is not a merge conflict because you touched the same syntax, it is a semantic conflict.
And didn't Uber also have a famously slow and convoluted CI pipeline where it took an enormous amount of time and resources to build anything?
The out-of-control factor = the number of parallel working agents : the number of human programmers.
1. If the factor > N, you're losing control and there will be no organizational wisdom passed down.
2. If your team can't function with the factor <= N, your architecture is way too complex.
Choose N over your prior. My recommendation is 1.
That is, the code should be correct but also idiomatic.
Staying on top of work done across many teams is going to be a huge challenge for larger companies and it's going to cause them to organize and hire very differently. Getting this wrong means teams diverge much quicker than they used to and everything gets misaligned much quicker. Some team might launch a product before some other team that was considering to do a similar thing is even aware that is happening. As most engineers might appreciate, the easiest way to tackle complexity is to just work on cohesiveness and coupling. Small teams with few dependencies working on a coherent thing will be much more effective than large orgs with a lot of inter team coupling and no coherent plan.
I'm in my fifties so, I've been around for a while. I currently work in a very small company (3 people) so I'm used to doing things by myself. I also used to work in traditional teams inside large multinationals. Very different game. You spend non trivial amounts of time communicating with people in big organizations. And you basically only get responsibility for a tiny amount of functionality. I had to learn a lot after I left the safety of a big organization. When everything is your problem, you need to skill up in a hurry to deal with all the challenges effectively.
In my current role, I do basically everything vaguely technical. And non technical as well. And it is more than ever since AI coding entered the mix last year. I stopped referring to myself as a backend person. Because I also do UI, devops, websites, IT infrastructure, etc. And a bit of sales, marketing, etc. I'd add management but we're such a small team that I suffer a little from impostor syndrome on that front. But I can do the job if I need to.
I had a whole hiring plan that I developed three years ago that we never executed on. It had all the traditional dev team roles spelled out. That plan is obsolete. These roles will probably never be filled. I need different people though. I need more people like me that can do everything I do when I'm not around and people with complementary skills that are strong where I'm weak. But I have much less need for specialists. I mainly need generalists with attention to detail that can deliver complete working products and systems. I might want a product focused person but not a dedicated product manager. If you can specify it in an issue tracker, you can learn to prompt an AI as well. But I still need a good product plan and roadmap. In the same way, I expect designers to shape UI work directly and not via a separate UI team. I expect them to own the front end experience and drive it. I still need people that are strong in these roles. But not exclusively. Good small teams have less people than all the traditional roles you find in larger traditional teams. That calls for people with overlapping skills that can put on different hats as needed that complement each other.
Is was successful because I didn't use any sort of LLM assistance.
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.
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?
It’s not hard to be faster than React while exposing broadly similar functionality. If you’re making something for your own usage only, it’s even easier to beat it.
Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.
Isn’t the question how to keep likely dependent modules separated from each other in a monolith? You say “single purpose”, but how does that admonition work in the reality of a complex problem domain?