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 2 hours ago | parent | next [-]

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.

▲

an hour ago | parent | next [-]

[deleted]

▲

bpodgursky an hour ago | parent | prev | next [-]

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 an hour ago \| parent [-]
		> but programming is never going back to normal. Are you telling it's shit now? I'm just curious.

▲

jatora an hour ago | parent | prev [-]

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 3 minutes ago \| parent [-]
		currently unfettered ai spending is reducing qol for more individuals than it is increasing. why should the avg joe be happy about reduced qol?

▲

pianopatrick an hour ago | parent | prev | next [-]

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 an hour ago | parent [-]

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 40 minutes ago | parent | next [-]

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 22 minutes ago \| parent [-]
		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.

▲

jatora an hour ago | parent | prev [-]

More coordination is exactly what the commenter was proposing though so I dont really see the point in your response.

▲

p1necone 43 minutes ago | parent | prev | next [-]

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 26 minutes ago | parent | next [-]

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 11 minutes ago \| parent [-]
		> 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.

▲

alright2565 29 minutes ago | parent | prev | next [-]

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.

▲

killthebuddha 34 minutes ago | parent | prev | next [-]

1 difference (out of many, many, differences), is that (most) compilers don't make guarantees across process boundaries.

▲

whateverboat 18 minutes ago | parent | prev [-]

In fact microservices are arguably more complex. It is the reason why microkernels have not succeeded compared to monolith till now.

▲

john_minsk an hour ago | parent | prev | next [-]

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

	▲	kstenerud an hour ago \| parent [-]
		For the same reason you change or replace any function in a program: The situation has changed.

▲

wotamess 6 minutes ago | parent | prev [-]

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 to continue to insinuate no one but SaaS devs have any idea how computers work.