6 ms·

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 prod

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.

gentooflux 2mo 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.
- bpodgursky 2mo 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.
  - zx8080 2mo ago
    > but programming is never going back to normal. Are you telling it's shit now? I'm just curious.
    - echelon 2mo 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.
      - thothless 2mo ago
        You're living in a corporate bubble, drowning in the kool-aid, along with half this forum.
        anonzzzies 2mo 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 2mo 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.
        echelon 2mo ago
        The models got good at this seven months ago. Your hypothesis that your job is secure because the models hit a ceiling is based on seven months of observational history. We've been watching the models get progressively better for years now. It's not going to stop in place. In some amount of time from now, these models will absolutely require less hand holding. It's as though everyone with your perspective isn't looking at the overall trend line. You're laser focused on just these last few months.
        RealityVoid 2mo ago
        And if it comes, it comes. I have no doubt a model can be as good or better than humans. I don't think humans are the peak of possibly. I just don't think the current crop of models will get there. And I do not think fast takeoff will happen. In the meantime, I keel hearing psychotic chants of "don't even read the code anymore, bro!" While the code these things output is severely lacking. At this point, it _is_ cool-aid.
  - sebastiennight 2mo 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.
    - wahnfrieden 2mo 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.
      - disgruntledphd2 2mo ago
        > Inference is profitable Let's wait for Anthropic's S-1 to see if this is actually true. Fundamentally, if Anthropic ain't profitable with all the investment and usage they get, then it's possible that it may not be economical to train new models in the future (I agree that inference for already trained models makes money, but the real question is if this money will pay for the cost of training & employees).
    - bpodgursky 2mo 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.
    - kaashif 2mo 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.
  - 0123456789ABCDE 2mo 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?
- deleted 2mo ago
  [deleted]
- jatora 2mo 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.
  - thin_carapace 2mo 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 2mo 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?
      - ThrowawayR2 2mo 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.
      - jamesfinlayson 2mo 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.
        jatora 2mo ago
        Yikes. Sounds like your workflow needs a ton of work if your SWE QoL hasnt improved. that's pretty wild that youd not be optimizing
- tjwebbnorfolk 2mo 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 2mo 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 2mo ago
      It’s like De Beers: control supply to control the price.
pianopatrick 2mo 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 2mo 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.
  - jatora 2mo ago
    More coordination is exactly what the commenter was proposing though so I dont really see the point in your response.
  - pianopatrick 2mo 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 2mo 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.
john_minsk 2mo 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 2mo ago
  For the same reason you change or replace any function in a program: The situation has changed.
p1necone 2mo 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.
- killthebuddha 2mo ago
  1 difference (out of many, many, differences), is that (most) compilers don't make guarantees across process boundaries.
- alright2565 2mo 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 2mo ago
    You can also make breaking changes to internal APIs without versioning or release coordination. Just update all the call sites.
- romanhn 2mo 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.
wotamess 2mo 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.
Sharlin 2mo ago
> Hundreds of bots modifying thousands of microservices may sound good on the surface It really does not, honestly.
ReptileMan 2mo ago
>Hundreds of bots modifying thousands of microservices That is way too close to monkeys on typewriters for comfort.
jurgenburgen 2mo 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?
d--b 2mo 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
MrBuddyCasino 2mo ago
I used to say my job was „managing complexity“, not being a programmer. After AI, thats still true because they suck at it.
hombre_fatal 2mo 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 2mo 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.
  - LtWorf 2mo ago
    I think probably something like 90% of developers are web developers doing some kind of web app that uses some remote API provided by someone else.
- mikojan 2mo 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.
  - hombre_fatal 2mo ago
    I've built many things this year letting sota models design the architecture, and they've been well-reasoned about it. I think what you describe is a lack of harness/infra/process around working with agents on a project. No effort to document ADRs. No effort to document invariants. No effort to design processes that ensure maintainable software even if it were five years ago and only humans were writing the code. Just because you delegate important decisions to AI doesn't obsolete practices as trivial as maintaining a log of potential issues in your codebase that you'd want to work through, keep track of, and verify.

gentooflux 2mo 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.

bpodgursky 2mo 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.
- zx8080 2mo ago
  > but programming is never going back to normal. Are you telling it's shit now? I'm just curious.
  - echelon 2mo 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.
    - thothless 2mo ago
      You're living in a corporate bubble, drowning in the kool-aid, along with half this forum.
      - anonzzzies 2mo 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 2mo 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.
        echelon 2mo ago
        The models got good at this seven months ago. Your hypothesis that your job is secure because the models hit a ceiling is based on seven months of observational history. We've been watching the models get progressively better for years now. It's not going to stop in place. In some amount of time from now, these models will absolutely require less hand holding. It's as though everyone with your perspective isn't looking at the overall trend line. You're laser focused on just these last few months.
        RealityVoid 2mo ago
        And if it comes, it comes. I have no doubt a model can be as good or better than humans. I don't think humans are the peak of possibly. I just don't think the current crop of models will get there. And I do not think fast takeoff will happen. In the meantime, I keel hearing psychotic chants of "don't even read the code anymore, bro!" While the code these things output is severely lacking. At this point, it _is_ cool-aid.
- sebastiennight 2mo 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.
  - wahnfrieden 2mo 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.
    - disgruntledphd2 2mo ago
      > Inference is profitable Let's wait for Anthropic's S-1 to see if this is actually true. Fundamentally, if Anthropic ain't profitable with all the investment and usage they get, then it's possible that it may not be economical to train new models in the future (I agree that inference for already trained models makes money, but the real question is if this money will pay for the cost of training & employees).
  - bpodgursky 2mo 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.
  - kaashif 2mo 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.
- 0123456789ABCDE 2mo 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?
deleted 2mo ago
[deleted]
jatora 2mo 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.
- thin_carapace 2mo 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 2mo 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?
    - ThrowawayR2 2mo 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.
    - jamesfinlayson 2mo 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.
      - jatora 2mo ago
        Yikes. Sounds like your workflow needs a ton of work if your SWE QoL hasnt improved. that's pretty wild that youd not be optimizing
tjwebbnorfolk 2mo 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 2mo 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 2mo ago
    It’s like De Beers: control supply to control the price.

pianopatrick 2mo 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 2mo 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.
- jatora 2mo ago
  More coordination is exactly what the commenter was proposing though so I dont really see the point in your response.
- pianopatrick 2mo 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 2mo 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.

john_minsk 2mo 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 2mo ago
For the same reason you change or replace any function in a program: The situation has changed.

p1necone 2mo 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.

killthebuddha 2mo ago
1 difference (out of many, many, differences), is that (most) compilers don't make guarantees across process boundaries.
alright2565 2mo 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 2mo ago
  You can also make breaking changes to internal APIs without versioning or release coordination. Just update all the call sites.
romanhn 2mo 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.

wotamess 2mo 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.

Sharlin 2mo ago

> Hundreds of bots modifying thousands of microservices may sound good on the surface It really does not, honestly.

ReptileMan 2mo ago

>Hundreds of bots modifying thousands of microservices That is way too close to monkeys on typewriters for comfort.

jurgenburgen 2mo 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?

d--b 2mo 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

MrBuddyCasino 2mo ago

I used to say my job was „managing complexity“, not being a programmer. After AI, thats still true because they suck at it.

hombre_fatal 2mo 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 2mo 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.
- LtWorf 2mo ago
  I think probably something like 90% of developers are web developers doing some kind of web app that uses some remote API provided by someone else.
mikojan 2mo 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.
- hombre_fatal 2mo ago
  I've built many things this year letting sota models design the architecture, and they've been well-reasoned about it. I think what you describe is a lack of harness/infra/process around working with agents on a project. No effort to document ADRs. No effort to document invariants. No effort to design processes that ensure maintainable software even if it were five years ago and only humans were writing the code. Just because you delegate important decisions to AI doesn't obsolete practices as trivial as maintaining a log of potential issues in your codebase that you'd want to work through, keep track of, and verify.