61–70 of 183 posts
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.
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.
Earlier quoted context omitted.
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.
> but programming is never going back to normal. Are you telling it's shit now? I'm just curious.
Programming will never go back to what it was before 2026.
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.
Earlier quoted context omitted.
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.
currently unfettered ai spending is reducing qol for more individuals than it is increasing. why should the avg joe be happy about reduced qol?
I get that SWE get far higher benefit than maybe everyone else, but who is it actively reducing QoL for?
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 repl…
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. T…
Earlier quoted context omitted.
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.
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 sam…
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.
Microservices can trample on each other just as easily as monolith internals can. If anything, the friction of reconciling changes in a monolith is useful signal that conflicting changes happened, and it takes slow and flaky e2e tests to replicate in microservices. It's not like you're resolving the merge conflicts by hand.
I don't understand why microservices would have fewer merge conflicts than monoliths.
Earlier quoted context omitted.
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.
> 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.
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.