Posts

Browsers handle unrecognized tags by treating them as a generic element, with no effect beyond what’s specified in the CSS. This isn’t just a weird quirk, but is standardized behavior. If you include hyphens in the name, you can guarantee that your tag won’t appear in any future versions of HTML.

This is so cool, and I had never heard of this before. I wonder why this is not more popular — really semantic HTML!

A thought-provoking article that, on the surface, explores which modality of AI agent deployment is more likely to succeed in a large organisation — agents carefully designed around organisational processes, or general-purpose agents trained to seek successful outcomes (RL, for example).

But dig a little deeper, and it raises a more fundamental question: what shape will successful AI-powered products take?

Ethan Mollick:

For many people, this may not be a surprise. One thing you learn studying (or working in) organizations is that they are all actually a bit of a mess. In fact, one classic organizational theory is actually called the Garbage Can Model. This views organizations as chaotic “garbage cans” where problems, solutions, and decision-makers are dumped in together, and decisions often happen when these elements collide randomly, rather than through a fully rational process.

Computer scientist Richard Sutton introduced the concept of the Bitter Lesson in an influential 2019 essay where he pointed out a pattern in AI research. Time and again, AI researchers trying to solve a difficult problem, like beating humans in chess, turned to elegant solutions, studying opening moves, positional evaluations, tactical patterns, and endgame databases. Programmers encoded centuries of chess wisdom in hand-crafted software: control the center, develop pieces early, king safety matters, passed pawns are valuable, and so on. Deep Blue, the first chess computer to beat the world’s best human, used some chess knowledge, but combined that with the brute force of being able to search 200 million positions a second. In 2017, Google released AlphaZero, which could beat humans not just in chess but also in shogi and go, and it did it with no prior knowledge of these games at all. Instead, the AI model trained against itself, playing the games until it learned them. All of the elegant knowledge of chess was irrelevant, pure brute force computing combined with generalized approaches to machine learning, was enough to beat them. And that is the Bitter Lesson — encoding human understanding into an AI tends to be worse than just letting the AI figure out how to solve the problem, and adding enough computing power until it can do it better than any human.

Kerrick Long:

Many people will tell you to ship a minimum viable product. Others say to ship a prototype to get feedback. Not me. I think you should ship a blank page to your production servers on day one.

Notice how much is involved in shipping software that does nothing. This work will come around eventually. The later you do it, the riskier it is.

Not satire. Good food for thought.

Nan Yu:

These tools are casually dismissed as “GPT wrappers” by some industry commentators — after all, ChatGPT (or Sonnet or Gemini or Llama or Deepseek) is doing all the “real work”, right?

People who take this perspective seem to be throwing away all the lessons we’ve learned about software distribution. It’s like they saw Instagram and waived it off as an “ImageMagick wrapper”… or Dropbox as an “rsync wrapper”.

Those products won because they made powerful, highly technical tools accessible through thoughtful design. The biggest barrier to mass AI adoption is not capability or intelligence; we have those in spades. It’s UX.

Amen.

Nice and clever use of uv’s run inline dependency management and Claude Project Custom Instructions to create Python scripts that are easy to run without any setup, even while depending on Python’s rich set of libraries.

I’ve used this workflow for a few scripts in the last couple of weeks, and it works remarkably well.

You can then go a step further — add uv into the shebang line for a Python script to make it a self-contained executable.

It is not the end of programming. It is the end of programming as we know it today. That is not new. The first programmers connected physical circuits to perform each calculation. They were succeeded by programmers writing machine instructions as binary code to be input one bit at a time by flipping switches on the front of a computer. Assembly language programming then put an end to that. It lets a programmer use a human-like language to tell the computer to move data to locations in memory and perform calculations on it. Then, development of even higher-level compiled languages like Fortran, COBOL, and their successors C, C++, and Java meant that most programmers no longer wrote assembly code. Instead, they could express their wishes to the computer using higher level abstractions.

Eventually, interpreted languages, which are much easier to debug, became the norm.

BASIC, one of the first of these to hit the big time, was at first seen as a toy, but soon proved to be the wave of the future. Programming became accessible to kids and garage entrepreneurs, not just the back office priesthood at large companies and government agencies.

The above is the central thesis of the article, and I strongly agree with it. The article also explores many more angles on the impact of AI coding, mostly through quoting and referencing others; I agree with some of these perspectives, whilst not so much with others. Nevertheless, it’s quite thought-provoking.

A Stratechery interview with the CEO of Tailscale dropped a few weeks ago. Tailscale is one of my favourite kinds of companies — focused on a single product that’s deeply technical and yet simple and delightful to use. I’m a longtime user and love the product. The interview is fun to listen to.

It reminded me of this old article that Tailscale published: How NAT traversal works. It’s an in-depth treatise on a topic that most of us never think about, but a critical problem to solve for those designing peer-to-peer networking software.

It’s a very long read, but a captivating one nevertheless. There are all kinds of interesting technical details, and some aha moments like how the ideas of The Birthday Paradox are used to devise an algorithm for NAT-busting (in a section delightfully titled “NAT notes for nerds”).

This document is the result of a series of discussions, some online and some in person, held between Robert "Uncle Bob" Martin and John Ousterhout between September 2024 and February 2025.

John is the author of the book A Philosophy of Software Design (APOSD), a book that was first published in 2018. This book has been on my “to read” list for a while now—I’ve heard very good reviews for it from a lot of people.

“Uncle Bob” Martin and his 2008 book Clean Code of course need no introduction. Clean Code is one of the OG books on modern programming¹.

This is an open debate between the two authors on the ideas they disagree on. And—wow, wow, wow—what a fantastic debate this is! The quality and depth of discussion is great, they both pull all the punches without holding back, and yet they are very civil throughout. I have never seen anything like this.

I mostly side with John in this debate. While I found many ideas in Clean Code to be very good—especially when I read it many many years ago as a young engineer, I’ve over time felt that it’s too dogmatic and not all that pragmatic.

This is a long read, but it’s well worth your time if you tend to geek out on the nuances of programming and low-level design.