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.

This is the closest I've found that's akin to Claude Code: https://aider.chat/

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.

Laws can help, but I'm most concerned with states leveraging this to influence foreign campaigns.

There will be a time when the Trump "grab them by the you know what" style scandal will just be met with sceptism.

Where do you go when even video evidence can't be seen as the truth?

Completely random tidbit of information, in Houston (and only Houston) we call them 'feeder roads.'

thank you for sharing this! I'd seen formats similar to this but I'd never seen what the format itself is called. very helpful to see it clearly described - I think I'll try to give this a go with our teams

In fairness, they aren't making that assertion, they are asking for OP to consider and pressure test that assertion

I’m not saying one way or the other, but “minuscule” varies on the scale and just because there’s a closed loop cycle doesn’t mean there’s not a local impact to removing water from the area.

Nothing of particularly high value, really?

Not a dumb question, but because they are so expensive to build, fabs have a high upfront cost before they can start to turn a profit. Oddly, the older a fab is, typically the more money it will make you.

It's also a big part of the reason as to why so many fab companies have died out. Building a new fab with the latest tech is extremely expensive. If you have a couple of big swings and misses, you can easily burn a tremendous amount of your capital.

I really enjoyed this article, I wish I would have read this the week before I first started interviewing people. I have 100% made some of these mistakes before.

Thankfully, when I first started, I was interviewing alongside a team of engineers more experienced than me, and I had a terrific manager that slowly brought me along (or left me out when I was out of my league) to strengthen my interviewing skillset - otherwise I would have sunk a deserving candidate at least a couple of times.

I still don't consider myself an exceptionally strong technical developer, but at least I know enough about my limits to know how to set the table effectively during an interview.

Aside from what was listed in the article, a couple of additional pieces of advice I've picked up along the way were:

1. Don't leave an interview with any suppositions that could have been clarified directly with the candidate. If you're unsure of something on their resume, ask them to clarify, even if it makes you feel a little uncomfortable (except don't ask legally protected questions, of course) 2. Seek curious people. You can teach a programming language, but you can't teach interest in the craft.

I heard about this book from hackernews a year or two ago. I'm not a big non-fiction fan, but I absolutely devoured that book. Strong plus one about Gertner's great work here.

Surprisingly, that didn't matter for a lot of years until pretty recently.

TY for sharing. I found this to be very enlightening, especially when reading more about the board members that were part of the oust.

One of the board of directors that fired him co-signed these AI principles (https://futureoflife.org/open-letter/ai-principles/) that are very much in line with safeguarding general intelligence

Another of them wrote this article (https://www.foreignaffairs.com/china/illusion-chinas-ai-prow...) in June of this year that opens by quoting Sam Altman saying US regulation will "slow down American industry in such a way that China or somebody else makes faster progress” and basically debunks that stance...and quite well, I might add.

If I may ask, how did you 'vandalize' it? It sounds like the definition of this word has some additional connotation within Wikipedia.

This makes me think about a story that Richard Feynman told about experiments and how often people miss the most important part about cargo cult science. Here was him talking about how we got better and better resolution around the charge of an electron:

> Why didn’t they discover that the new number was higher right away? It’s a thing that scientists are ashamed of—this history—because it’s apparent that people did things like this: When they got a number that was too high above Millikan’s, they thought something must be wrong—and they would look for and find a reason why something might be wrong. When they got a number closer to Millikan’s value they didn’t look so hard. And so they eliminated the numbers that were too far off, and did other things like that. We’ve learned those tricks nowadays, and now we don’t have that kind of a disease.

https://calteches.library.caltech.edu/51/2/CargoCult.htm

As a paid license Sublime user, years back, my biggest annoyance with VSCode was that regex pattern matching hit a limit to the matches it could find. At the time I believe it was around 1k, from some quick Google searching it looks like they may have increased the limit to 10k, which would have been right on the cusp of my use case at the time.

I could see giving VSCode another go in the future, but it's the 'if it aint broke' adage at this point.

This was interesting to me, so I dug a bit further. This gives a bit more context behind why: https://community.openai.com/t/observing-discrepancy-in-comp...

Quote below:

Even with a greedy decoding strategy, small discrepancies regarding floating point operations lead to divergent generations. In simpler terms: when the top-two tokens have very similar log-probs, there’s a non-zero probability of choosing the least probable one due to the finite number of digits that you’re using for multiplying probs and storing them.

It should also be noted that, as the decoding occurs in an autoregressive way, once you have picked a different token the whole generated sequence will diverge, as this choice affects to the probability of generating every subsequent token.