101011

There's a huge jump between OpenAI, Anthropic, Google, and every other major player distilling the internet into LLMs and deliberately breaking a mutually signed contract between them and another business.

As for ZDR and court-orders, what would you rather happen there? Violate the law or comply with holding the data? I would bet that any ZDR agreement has this court-ordered risk mutually understood and agreed upon.

how do you define system completeness? what if you ship one really big feature vs three really small ones?

I would posit that you need extra context to obtain meaning from those metrics, which inherently makes them less visible

> You can either seek understanding or seek blame, but not both at once.

This is the first I've heard this statement (not necessarily the idea), but I found it incredibly beautiful in it's simplicity - thanks for sharing!

Are there origins to this that you're aware of? With some searching I found some adjacent thread lines to stoicism and Buddhism, but nothing quite the same.

I think it's fair to call out a dark pattern for account deletion (which, for better or worse, is common practice) - but the data training and data retention thing can both be disabled...I was much more surprised that they DIDN'T train on data as long as they did, when every other LLM provider was sucking in as much data as they could (OpenAI, Google, Meta, and xAI - although Meta gets a pass for providing the open-weight models in my head).

Anthropic has made AI safety a central pillar of their ethos and have shared a lot of information about what they're doing to responsibly train models...personally I found a lot of corporate-speak on this topic from OpenAI, but very little information.

Hey, I was CAL-i too! At least...that's what we told people in IRC :P

If I could offer another suggestion from what's been discussed so far - try Claude Code - they are doing something different than the other offerings around how they manage context with the LLM and the results are quite different than everything else.

Also, the big difference with this tool is that you spend more time planning, don't expect it to 1 shot, you need to think about how you go from epic to task first, THEN you let it execute.

The trick shouldn't be to try and generate a litmus test for agentic development, it's to change your workflow to game-plan solutions and decompose problems (like you would a jira epic to stories), and THEN have it build something for you.

agreed on the revised SQL!

But I don't think I missed the point, the original text talks about measuring complexity as a function of operators, operands, and nested code. The true one to one mapping is more complex than the original comment I replied to

In fairness, if this was in a relational data store, the same code as above would probably look more like...

SELECT DISTINCT authors.some_field FROM books JOIN authors ON books.author_id = authors.author_id WHERE books.pageCount > 1000

And if you wanted to grab the entire authors record (like the code does) you'd probably need some more complexity in there:

SELECT * FROM authors WHERE author_id IN ( SELECT DISTINCT authors.author_id FROM books JOIN authors ON books.author_id = authors.author_id WHERE books.pageCount > 1000 )

You could treat it as an nullable Option<SomeType>.

In practice, as it relates to enums, I don't usually see 'no value provided' as a frequently used case - it's more likely that 'no value provided' maps to a more informative 'enum' value

This ended up being the preferred pattern we moved into.

If, like us, you were passing the object between two applications, the owning API would serialize the enum value as a String value, then we had a client helper method that would parse the string value into an Optional enum value.

If the original service started transferring a new String object between services, it wouldn't break any downstream clients, because the clients would just end up with Optional empty

Love this share, I just watched the 1955 vs 1957 Royal Quiet Deluxe video. Learned a couple of fascinating things:

1. 1955 model did not have the number "1" or the "!" - as I guessed, you can get the 1 with a lower-case L. But the exclamation point stumped me - turns out you had to use apostrophe, then backfeed a character, then use a period over the same space to recreate the "!". 2. Different typewriters had different typesets that could result in dramatically different script lengths for writers. It forced one of the screenplay writers of Star Trek to have to tighten up his script substantially after they realized it was too long.

Rule 4 is divide and conquer, which is the 'splitting code in half' you reference.

I'd argue that you can't effectively split something in half unless you first understand the system.

The book itself really is wonderful - the author is quite approachable and anything but dogmatic.

TIL about a Cuckoo Filter.

Also, never realized redis has native support for a Bloom Filter.