Bryan Cantrill:

this week, ex-Anthropic employee Jacob Coxon claimed  […] that the probability that AI will "kill all humans" is ">10% in the next decade" (!!) […]

how would that happen? […] Jacob Coxon cites "hacking critical infrastructure" and "extinction-level bioweapons" without further elaboration. But Coxon is not an expert on critical infrastructure, nor on bioweapons — nor, for that matter, on extinction.

Silicon Valley’s mantra should be: You Can Just Do Say Things.

It is incumbent upon us to be circumspect in our claims

Remember when people were held accountable for the things they claimed? Good times.

Celine Nguyen:

models have “read” at least 482,460 books. But even Claude Opus 4.8 hasn’t written a short story that I enjoy more than those by Lydia Davis or Jessi Jezewska Stevens — both of whom, despite being prodigiously well-read, have almost certainly read fewer books.

Idk who needs to hear this, but humans are not computers. The brain is not a CPU. Do what makes you human, not what makes you computer-y.

very distinctively human — to train yourself in ways that seem like a waste of time.

Marcin Wichary:

When Chrome started in the late 2000s, it felt like a browser that had user’s interest in mind, and protected people from ill-behaving websites. Today, it’s the operating system that needs to protect us from Chrome.

Jason Gorman frames himself as an “AI realist” in this podcast and has some interesting observations. For example, here’s what he says about how riding the LLM cuts against our cognitive abilities:

By all means, read code and copy it. But it’s gotta go in the eyes, through the brain, and out the fingers to engage those parts of your brain that makes it sink in. It’s like everyone’s on speed dial and nobody can remember anyone’s number. And the moment you take that phone away, they can’t remember anyone’s number.

If you don’t listen, his post sums up a lot of the talking points in the podcast:

software development isn’t a production process […] AI coding is an amplifier of, not a fix for, development strengths and weaknesses.

Truly autonomous and reliable long-horizon agentic software development is so highly improbable using LLMs that it’s essentially science fiction.

Marcin Wichary:

There is also something great in seeing an interface that grows with you, or one where you can say “I wonder if…” based on your prior interactions and expectations, and the interface actually rewarding you for that thought.

I grew up interfacing with computer software this way and it’s an incredibly rewarding experience. There’s definitely a connection to the creators that forms in these moments, like “I wonder if you could…hey, you can! It’s not just me, somebody else had the same thought!”

Lea Verou:

Once you’ve spent a lot of time and effort on something, you overestimate how much it matters to everyone else

Too true!

Bryan Cantrill:

If [you’re] fine with an LLM crafting prose from your prompt, spare us all the wasted cycles and just give us your prompt. Or, better yet, consider doing what generations of writers have done before you, and treating that prompt as a skeleton that you use to write your piece yourself!

Pete Millspaugh:

It’s kind of hard to believe that important parts of internet infrastructure run like this: a plain text file maintained by a group of volunteers online.

I learned about the Public Suffix List when I was trying to extract domains from URLs and realized there’s more nuance here than I thought.

Michelle Barker:

Maybe [coding this thing] would be easier with an LLM. But it would be less satisfying, like a sugary snack devoured in haste to stave off hunger.

Well damn, why she gotta do me like that? That analogy hits home. I feel seen.

Robin Spielmann takes a stab at defining “design engineer”:

The role [of a design engineer] is: there is a specific set of tasks that has to be done in every digital product, and on most teams nobody is responsible for them.

A design engineer understands there’s a ton beneath the surface of a static mock:

A [static screen] shows a product at its best. One screen width, plausible data that someone made up, and the path where everything goes right. Shipping that same screen means answering a much longer list of questions. What happens with a name that’s sixty characters long? Does the layout jump around when the data finally loads? What if there is no data at all, and is that an empty state or does it look like something broke? What about a slow connection, a narrow phone, someone who never touches a mouse?

Making decisions around those questions is the job of a design engineer:

[a great product is] the sum of a few hundred small decisions, none of which would survive being written down as a requirement.

There’s the reality right there! There’s just too much to write down and convey as requirements (plus trade-offs have to be made). You need someone who 1) understands these concerns exists, and 2) takes them on with care.

I kinda like this working definition of a “design engineer”:

A design engineer is the person who owns whether a product still agrees with itself.