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.
Very interesting! I wonder if, sadly, the rise of AI-assisted coding will chip away also at this potential revenue stream? As developers simply ask a local or cloud LLM how to use a piece a software instead of reading the documentation.
I wonder what Paul's definition of "young" is in the sentence and why he qualifies this as only applicable to "young" people. Is he proposing that "old" people will have misaligned thinking about what needs to be built?
I am 41 with two kids.
> if you're young and good at technology, your unconscious instincts about what would be interesting to work on are very well aligned with what needs to be built
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.
It’s not a subjective opinion: I’m saying that I’ve actually migrated a Python application to Golang (real time chat application with a lot of business logic) and it was 2x the line count.
I expect the Golang line count ‘overhead’ gets bigger for typical LoB software that has to address any sort of enterprise mess.
There are tons of startups that were built on Python that became enormously valuable companies: Instagram, Dropbox, Reddit, Spotify, YouTube, Pinterest, Quora, SurveyMonkey, Twitch, Zenefits.
My experience translating a codebase from Python to Golang (chat application), is that 20k of Python really does translate to around 40k of Golang to get the same functionality.
And it’s not just due to language but also expressiveness of the library ecosystem.
Do you mean greedy, as in the sense of a greedy algorithm? Because I don’t have a formal mathematical description for this, but it feels more ‘optimal’ than a purely greedy algorithm.
Local agent behaviour may be greedy, but this could still result in something approaching a global optimum - the economy could work like Ant Colony Optimisation in aggregate.
C++ with output rendered with Graphviz