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.

I will read anything danah boyd writes, but this piece is especially good. You should (as I say too often I guess) read the whole thing—it’s about how social media has changed from interacting with friends to a one-sided marketplace of choosing who to deem worthy of giving them our “like and subscribe” blessing.

But here I just want to say: can we please, somehow, bring back Path? Because it solved this problem a decade ago:

In 2026, many major social media platforms feel icky because we are in the full throes of the third stage of enshittification. Today’s social media platforms are no longer centered around sociable activities. Instead, most platforms offer us a broadcast medium and invite us to learn how to game the algorithms so that we too can create assets for the major corporations. Since scale is valorized in this platform economy, we are encouraged to curate ourselves in pursuit of fame and attention. We can still, in theory, create content for our 15 friends, but it’s not clear that they will see what we post. To actually be seen, we must work it.

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. ↩

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?

I say this sincerely because I am a big fan of Buttondown and how Justin runs the business—this couldn’t have happened to a nicer guy:

Our month-over-month growth rate in Q1 2026 was double our growth rate in Q4 2025. Buttondown has, roughly, grown a little less than 2x every year of its existence; this — its eighth year — is poised to shatter that, if trends hold.

Almost all of that incremental growth, meaning the growth in addition to our historical trend, I attribute to LLMs. We ask people when they sign up what brought them here, and an answer that went from surprising to banal to overwhelming over the course of Q1 was: an LLM. Users of all stripes cite an LLM as the reason that they ended up at Buttondown’s front door.

You should click through for the whole post because he explains why he thinks this happened:

People have asked why I think we have been the beneficiary of this genre of growth. There is one fairly interesting reason: we have accidentally built a very LLM-friendly business in this space.

I’ve always been a big believer in API-first design, and this feels like an almost accidental enormous additional benefit to that approach. Anyway, all that to say… my newsletter is on Buttondown, and yours should be too.

This post is a fascinating look at how botnets actually work. I don’t want to spoil the takeaways so I’ll just quote this (but you should read the whole thing):

Your server isn’t special. Nobody is “targeting” it. Every IP address on the internet is being continuously probed by automated systems. Within seconds of exposing port 22, you will receive login attempts. This isn’t a question of “if” but “when” — and the answer to “when” is “immediately.”

Oh, this is very good. On the classic take that the core characteristic of outstanding engineers is “laziness”:

The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone’s) future time, and will happily dump more and more onto a layercake of garbage. Left unchecked, LLMs will make systems larger, not better — appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters. As such, LLMs highlight how essential our human laziness is: our finite time forces us to develop crisp abstractions in part because we don’t want to waste our (human!) time on the consequences of clunky ones.

The best engineering is always borne of constraints, and the constraint of our time places limits on the cognitive load of the system that we’re willing to accept. This is what drives us to make the system simpler, despite its essential complexity.

This is exactly why I practice Fear-Driven Development, and why everything I do in code includes multiple versions of asking Claude Code “do we need this?” and “is this adding bloat?”