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.
Andrew Ng argues that telling people not to learn programming because AI will automate it is terrible advice—as coding becomes easier, more people should code, not fewer.
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 programming1.
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.
The Pragmatic Programmer & Code Complete being the other two books I consider in this league. Many consider Refactoring also to be part of this elite club, but I haven’t read it myself. ↩
Douglas Adams wrote about technology adoption in 1999, and his observations hold up remarkably well when applied to how people react to AI today.
Keith Rabois' mental model for thinking about people in organizations: barrels can take an idea from conception to completion on their own, ammunition can't. The number of barrels limits how many things you can do at once.
The marshmallow experiment is famous: a little kid in a room staring at a marshmallow. If they wait 15 minutes, they get two marshmallows instead of just one. Some kids would poke the marshmallow, lick it, or just gobble it up. Others found clever ways to distract themselves – singing, closing their eyes, even falling asleep. The results – children who waited supposedly went on to achieve higher scores in school and better life outcomes. The message was clear: if you can delay gratification, you’re set for life. But later studies revealed some serious holes in that conclusion.
Emphasis mine. The rest of the post is about the myriad of ways that the original conclusion was wrong. Easy read.
James Somers:
The obvious benefit to working quickly is that you'll finish more stuff per unit time. But there's more to it than that. If you work quickly, the cost of doing something new will seem lower in your mind. So you'll be inclined to do more.
The converse is true, too. If every time you write a blog post it takes you six months, and you're sitting around your apartment on a Sunday afternoon thinking of stuff to do, you're probably not going to think of starting a blog post, because it'll feel too expensive.
What's worse, because you blog slowly, you're liable to continue blogging slowly—simply because the only way to learn to do something fast is by doing it lots of times.
This is true of any to-do list that gets worked off too slowly. A malaise creeps into it. You keep adding items that you never cross off. If that happens enough, you might one day stop putting stuff onto the list.
That hit hard. Read the whole post, it’s well worth the time.
Benchmarks are important tools for tracking the rapid advancements in large language model (LLM) capabilities. However, benchmarks are not keeping pace in difficulty: LLMs now achieve over 90% accuracy on popular benchmarks like MMLU, limiting informed measurement of state-of-the-art LLM capabilities. In response, we introduce Humanity's Last Exam, a multi-modal benchmark at the frontier of human knowledge, designed to be the final closed-ended academic benchmark of its kind with broad subject coverage. The dataset consists of 3,000challenging questions across over a hundred subjects. We publicly release these questions, while maintaining a private test set of held out questions to assess model overfitting.
The sample questions are fun to go through, as a way of understanding the level of expertise these models are going to end up at, eventually. Eventually is the keyword there — even the best frontier models do very poorly on this benchmark right now.