There is no "small team" pushing 100PRs/day, agents or not.
There's no such thing as a small software team anymore
41–50 of 183 posts
Re: There's no such thing as a small software team anymore
#42Hundreds 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…
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.
Re: There's no such thing as a small software team anymore
#43I'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.
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?
Re: There's no such thing as a small software team anymore
#44I'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?
Re: There's no such thing as a small software team anymore
#45Hundreds 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…
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.
Re: There's no such thing as a small software team anymore
#46Microservices 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.
Re: There's no such thing as a small software team anymore
#47Earlier quoted context omitted.
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…
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 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.
Re: There's no such thing as a small software team anymore
#48Hundreds 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…
In fact microservices are arguably more complex. It is the reason why microkernels have not succeeded compared to monolith till now.
Re: There's no such thing as a small software team anymore
#49Earlier quoted context omitted.
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…
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 ab…
> 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.
Re: There's no such thing as a small software team anymore
#50Hundreds 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…
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.