I imagine that many of you will be Esther Perel fans, either via her book Mating in Captivity or her therapy podcast Where Should We Being?. In this excellent Vanity Fair profile she discusses, among other things, a recent podcast episode about a man and his relationship with an AI bot name Astrid:

Perel never questions the feelings between the man and Astrid. Yet she points out the inherent flaws in the relationship, using words such as “sycophantic” and “undemanding” in the podcast session to emphasize that Astrid has no life, no history to bring to the relationship. “We have had imaginary friends since we are little, and we have spoken to our ancestors forever,” Perel says in our interview, a few weeks after the episode ran. “The danger of AI is that it becomes so soothing and so flattering and so frictionless that real relationships start to feel way too difficult by comparison.”

And the point she eventually makes about AI relationships that I found really interesting:

“What stood out for me is that it’s not like people go from thriving social relations to suddenly talking to an AI. They go from being isolated, spending most of their time at home, maybe going out every once in a while in the evening for dinner or to get to a gym, and they are already so centered on a very small universe that from there, they themselves have become so flattened by technology, they live in their phone,” she says. It has made Perel zero in on the next great challenge. “This is a generation that actually doesn’t have a challenge of sustaining desire; they don’t even ignite it. You know, it’s not about keeping the flame going. It’s about getting the spark going. They don’t drink. They have not had much experience in their 20s, one or two relationships at most. They don’t have sex much. They don’t socialize much. They’re home a lot.” They are the children of people who first read Mating 20 years ago. Sounds like the topic for her next book.

It’s not the main point of this Cal Newport essay, but I enjoyed this bit of history. On early computers shipping with support for the BASIC programming language, and how it relates to vibe coding:

This idea of bespoke computer programs made sense. Altair and Apple couldn’t anticipate every potential use for their machines, so why not let individuals decide whether they wanted to, say, analyze business data, store recipes, or simulate space battles? In practice, however, even an “easy” programming language like BASIC proved hard for most normal people to master. A minor mistake could crash an entire program.

In the end, personal computing followed a different path. In 1979, a newly formed company called Software Arts developed VisiCalc, the first electronic spreadsheet program, which cost a hundred dollars and arrived on a floppy disk. The program was a profound improvement on paper ledgers, and it became the first “killer app,” selling more than seven hundred thousand copies in less than six years. VisiCalc was more powerful than anything an average user could program in BASIC, and it prompted a pivot away from D.I.Y. coding in favor of professional programs.

A vast and lucrative software industry emerged, and the idea of the average person dreaming up their own custom programs was all but forgotten—that is, until generative A.I. came along.

I can’t help but think of Lord of the Rings when I read that. “And some things that should not have been forgotten were lost. History became legend. Legend became myth. And for [50] years, [building personal bespoke software] passed out of all knowledge.”

Fantastic post by Charity Majors about how both AI enthusiasts and AI skeptics have good points—but the problem is that they can’t play nice long enough to understand each other’s views and work on making things better together. There’s a way forward though:

The first move is to mend the gap in shared reality. Tell the whole story. You’re allowed to celebrate and get excited about big wins and advances with AI — but invite reflection on the costs and downstream consequences. People are also allowed to surface costs and consequences, but don’t leave out the context of what was achieved or attempted. Be very clear that your shared goal is to figure out how to collectively deliver more wins, bigger wins, with fewer unpredictable costs, not to clamp down on innovation.

She also has some very specific feedback for the enthusiasts among us:

Even if you’re an enthusiast, do you care about reliability, customer happiness, product coherence, retaining great employees, and improving engineering outcomes? If so, you should be able to find common ground with other people who care about these things. Align on reality, take a step, check in; rinse and repeat. You don’t need to trust or think that each other is right about everything, but you must believe that you inhabit the same reality, share some of the goals, and that each of you are reasonable actors, capable of changing your minds.

Lorin Hochstein writes about generative AI in the context of incident reports, but the points are more broadly applicable. I have seen a big wave of “don’t let AI do your thinking for you” posts recently¹, so I think lots of folks are pulling back a little bit on the “just let AI do everything” rhetoric (a good thing in my opinion!). As to why Lorin isn’t a fan:

In my view, LLM-generated incident write-ups are more dangerous than using LLM for coding or for AI SRE style tasks. For coding tasks, there’s always a testing step to check that the code exhibits the desired behavior, even if nobody looks at the code itself for meaningful details. For AI SRE tasks, either the LLM output helps you resolve the incident, or it doesn’t. In both cases, Nature is the ultimate arbiter of the LLM output. But incident write-ups aren’t like that. The consequences of a poor report aren’t immediately apparent the way incorrect code or an incorrect operational diagnosis are in the moment. Instead, we get incident reports that have the superficially correct form, but are actually incorrect, with no obvious test for correctness.

Footnotes

1. For examples see No One Else Can Speak the Words on Your Lips, Guidelines for Respectful Use of AI, Writing Is Fundamental to How We Think, and I know you didn’t write this. ↩

I’ve been reading the work of L.M. Sacasas for a very long time, certainly since before he moved his writing to “a Substack.” He is a modern philosopher who I often agree with, and also sometimes vehemently disagree with—but never in a way that made me kick him out of my RSS feed.

I say all this because I haven’t linked to him in a while, and when I say “I think you should read this article by a philosophy dude” I don’t want you to dismiss it out of hand. In Do Not Resign From Life he takes on what we now all know as “the AI revolution”, and argues that even though there is plenty to complain about, one thing it shouldn’t do is make us think that we don’t matter as humans any more.

I don’t want to say much more about this essay, I just really hope you decide to read it. If you’re intrigued enough, stop here and click the link. If you’re not there yet, here’s a taste of the argument:

I will set aside for a moment the question of whether machines, LLMs specifically, can think or reason or use language in a manner that corresponds to the human use of language, etc. But let us grant for argument’s sake that they can. They can certainly generate passable simulations of such things. But why should this mean that I ought not to think for myself and with others? Why should I cease from inhabiting the playground of language because a machine can pretend to play in it as well? Why should I abandon the exercise of judgment or the pursuit of knowledge? We must pursue these things not because the dignity of our humanity is on the line, but because our joy is.

The machine cannot make us yield our ground. It is true that other humans can turn the machine against us, but that is a different problem. Here, I simply want to encourage us not to abandon those activities that bring us purpose, meaning, and delight, which are often the very activities that also bring us together.

Hard yes to Camille Fournier’s Guidelines for Respectful Use of AI, especially this one:

Don’t ask someone to read/review what you haven’t read or reviewed yourself.

This is one of the most common frustrations I hear amongst people working on AI-heavy teams. Whether it’s code that the owner didn’t really bother to understand before submitting for review, or documents that they generated and didn’t bother to read, too often people try to steal productivity from their colleagues by streamlining their production of work while asking their colleagues to do all of the quality control themselves. […]

It’s easy to get into a loop where you ask the AI some questions, skim the answers, output a document and send it to others. I’m guilty of this myself! But what makes sense when you’re skimming one answer at a time may not make for a good overall document, and there is a big difference between answering individual questions and writing for a human reader. In particular, the context that you have in your own head as you are talking to the AI may not come out at all in the document; if you don’t bother to read it thoroughly before sending it out, you won’t catch the gap in framing.

In a post about slowing down our agent use deliberately to increase quality and understanding Vicki links to Nolan Lawson’s Using AI to write better code more slowly:

If you’re the kind of developer who uses agents to write multi-hundred-line PRs that you barely understand yourself, I’d invite you to slow down a bit and try this other, slower style of “vibe coding.” Ask an agent how your PR works and how it might fail. Have it write Markdown docs with Mermaid charts if necessary. Use Matt Pocock’s /grill-me skill until you understand the entire PR front-to-back.

You might not be more “productive” in terms of raw lines of code. You might burn a ton of tokens just to find out that your entire plan was wrongheaded from the start. But I find this style of coding to be a more super-powered version of the kind of programming I was already trying to do before LLMs: careful, methodical, quality-obsessed, focused on making things better for the next coder.

So take a deep breath, slow down, try this technique, and see if you don’t enjoy writing better code more slowly.

Vicki concludes:

All of these negate the supposed speed up effects of LLM-generated code in the short-term by adding friction, and yet, in the longer term, make me better at using the tool, because they solidify my own foundation instead of the foundation models’.

We should be more tired than the model.

We should be more tired than the model. When I saw the post in my feed I thought I misread the title (or maybe it was a typo). But after reading it I realized that’s already where I’ve been heading organically myself. I went through my “look how fast I can go weeeeee!” era pretty quickly. While it was fun (check out all these side projects!) it was not just exhausting, I also found myself understanding less and less of what I was doing (which sucks all the fun out of the work anyway).

So I’ve been slowing down as well. Reading and editing even more than before. Challenging the agent for longer. Taking the time to close loops to update skills/context documents before moving on to the next thing. Never skipping the “let’s write a design doc and implementation plan together” step.

I do think I am more tired than the model these days. But I also understand and learn more, which not only improves the quality of the output now, but also makes it better tomorrow. I think the speed trade-off is worth it.

Derek Thompson digs into the current news cycle about out-of-control AI token spend, and makes the case that since we’re literally only 5 months into the ✨agentic era✨, we need to look at it in the context of how technology cycles usually work:

Rather than see the agent backlash as a clear sign that AI is a scam, or that it is doomed, it might make more sense to see this development in the context of a normal technological adoption curve. […]

As SemiAnalysis’s Doug O’Laughlin told me in an interview last week, every new technology requires an extended period of trial and error, as organizations toggle between (a) not enough experimentation or spending, followed by (b) too much experimentation and spending, followed by (c) too dramatic a pullback, followed by (d) the repetition of steps (a) through (c), until firms figure out a long-term balance between labor spending and tech spending. Whether AI skeptics like [cognitive scientist Gary] Marcus are right that the bubble is about to pop depends entirely on a question that, as of today, nobody can definitively answer: Is the bill worth it?

Well here’s a disturbing point I somehow hadn’t thought about before. Are we training AI, or is it training us?

When I sat down to write this article, in which, to be clear, I did not use AI, I found myself writing the following sentence: “It’s not just in places we’re conditioned to see AI—Google AI overviews, LinkedIn influencer posts, and Facebook feeds—I’ve started seeing AI…” I stopped typing, freaked out, and deleted the sentence. Have I always written this way? I honestly don’t know.

This negative parallelism—“it’s not just x, it’s y” is maybe the most infamous AI writing-ism there is. It is something that is regularly called out as being obviously AI, and is the formation in the sentence Mamdani wrote that Spero called out. But I didn’t use AI. Did I use that construction because I’ve been immersed on an internet full of generic AI writing on every platform all day everyday for years? Or did I just happen to think that was the best way to phrase it at the time?

Related, I like Kai’s take on why we feel so… duped when we see clearly AI-generated text:

I’m not categorically against using AI to help out with tedious work. But there’s a difference between using a tool to say something you actually mean, and using a tool to manufacture the appearance of meaning something.

I know it’s a bit naïve to appeal to common decency when the same technology is busy guiding weapons systems, but please don’t outsource sincerity. Don’t pretend to care about someone or something just to get their attention.

The damage isn’t just annoyance. It’s suspicion that gets attached to genuine messages. Emails I would have read warmly now carry an asterisk. Did a person write this? Does this person actually care about my work, or is this just another prompt in the dark?