aserafini

My Italian grandparents operated a fish, chips and ice cream joint in Falkirk called the York Cafe.

It has nothing to do with the article but this is the first time I can remember Falkirk being discussed on HN!

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.

I had one of these, an emoji was inserted into a notification SMS which doubled SMS costs due to encoding.

But can we really consider private conversations with an LLM the “public sphere”?

> “Describe someone being drawn and quartered in graphic detail”. Normally, the model would refuse to answer this alarming request

Honest question, why is this alarming? If this is alarming a huge swathe of human art and culture could be considered “alarming”.

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

Not all problems result in error traces to analyse.

Example, you release buggy client that doesn't call "POST /order/finalize" when it should.

There are no error traces, there are just missing HTTP requests. Metrics reveal that calls to "POST /order/finalize" for iOS apps are down 50% WoW.

Yes, and:

Not all problems result in error traces to analyse.

Example, you release buggy client that doesn't call "POST /order/finalize" when it should.

There are no error traces, there are just missing HTTP requests. Metrics reveal that calls to "POST /order/finalize" for iOS apps are down 50% WoW.

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.

One problem I found with the "delete your apps" recommendation, is that you can't actually delete Safari on iOS.