31–40 of 183 posts
> 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.
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…
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.
Earlier quoted context omitted.
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…
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…
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 Choose N over your prior. My recommendation is 1.
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 op…
> 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.
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…
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.
Earlier quoted context omitted.
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…
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…
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 op…
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.
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…
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…