My recollection (admittedly worked for Amazon >19 years ago) is that there was never any computational overhead to commingling. In fact, the opposite was true: there was a computational overhead to tracking which vendor a specific piece of inventory of a given product came from instead of assuming that all inventory of that product was fungible.
This affected returns as well. For multi-sourced products, we could never guarantee that overstock or damaged items were returned to the original supplier—only that the product matched. Suppliers complained about this a lot.
I experimented with Claude Code but returned to the familiar Aider which existed before all of these tools AFAIK.
You’ll notice people in Aider GitHub issues being concerned about its rather conservative pace of change, lack of plug-in ecosystem. But I actually started to appreciate these constraints as a way to really familiarise myself with the core “edit files in a loop with an end goal” that is the essence of all agent coding.
Anytime I feel a snazzy feature is lacking from Aider I think about it and realise I can already solve it in Aider by changing the problem to editing a file in a loop.
With only sampled traces though it’s very hard to understand the impact of the problem. There are some bad traces but is it affecting 5%, 10% or 90% of your customers. Metrics shine there.
C++ with output rendered with Graphviz