I also did some distributed systems work recently creating a flexible sharded data aggregation pipeline but my AI (Claude Code) was able to do it. The prompts were very technical and I kept having to check that it didn't miss anything but it did a great job. It would have taken me way longer to implement by hand.

That said, it's true that all the default decisions it initially took were not good. I had to keep insisting that the solution should scale linearly with number of workers. With every additional feature or adjustment, it kept adding shared processing bottlenecks, even though it required less than 20% extra code to keep it embarrassingly parallel. And that's with my entire codebase designed to be embarrassingly parallel from the ground up.

I think there's definitely a weakness there. That said, I think this industry tends to shun embarrassingly parallel solutions; equating it to overengineering. Personally, I find embarrassingly parallel solutions more elegant and robust especially in terms of state management. Doesn't require that much additional work. Everyone seems to be on board with Functional Programming which also helps to manage state more reliably (and often helps make code embarrassingly parallel) but my impression is that just aiming for parallelism gives you the same key benefits as FP. Allowing modules to hold state isn't the problem. The problem is that state has to be handled carefully. FP is kind of throwing out the baby with the bathwater, IMO.